[I apologize if this message gets posted twice. I thought I posted the first one but can't find it on the forum, so maybe I didn't post correctly.]
My game will just use small, static textured models consisting of independent triangles.
I would like to find the simplest possible file format that ideally just lists the verticies and texture coordinates for each triangle. Ideally, it would not output unused vertex data such as color or normal data, or output any unecessary meta-data such as object names, meshes, or face lists that would require additional parsing and collating work on my part.
Does anyone have any recommendations for common file formats that would fit the bill, and what modeling software supports those formats?
Replies
other than that, go for obj.
but I kind of think that I know what it is about, in max it really is easy to write any values very quickly to any ASCI format using format and other methods.
Some reasons to go for a custom format:
- reduce filesize (go perhaps binary)
- store unique special data
- optimize for performance on the engine side (maybe its faster if it reads data in a special way
some reasons to go with existing formats such as OBJ or FBX
- can be read and edited in other tools as well,- like many open source useful tools (meshlab, ivy gen, ....)
- there are already existing scripts for it to either use or study
regarding OBJ, you can setup up in the exporter what you want,- for example in your case you might want to say that you only want to export triangles and that you don't want the material definition + you want UV and so on.
Once you defined that once manually (if you go file > export selected > ...) it will use those settings each time you export it with a single maxscript command.
Ask here some stuff if you want to know some maxscript lines to stuff you need.
I don't have Max -- is it pretty straight forward to configure it to use a script when exporting?
"How To ... Output Geometry Data To Text File"
longshot, we cant give you "generic" scriptlines, the different 3d apps have different script apis and languages.
however I think that given you want a custom format, also likely means you do the import in your game yourself? should be fairly easy to just use .obj then and simply ignore all keywords in .obj files that you are not interested in when parsing. Because as renderhjs put the pros and cons, the benefit of a standard base format saves work.
Its more easy to separate informations like animation and skin in 2 different files ^_^
Actually Autodesk own FBX... after losting more that 430 employer this year .... :D:
Here are the collada informations : http://en.wikipedia.org/wiki/COLLADA
Sony take care of it ^_^
REEDIT : woops sorry, I just checker the documention of the last version 2010 of the FBX exporter and it seems to be abble to export animation's data in a separate file right now... O_O....
he asked for a simple ascii format for a good reason.
For Flash engines I always avoided it because its to bloated (with all the tags around stuff) and exports often way to many things one does not really need. Its nice and readable for the eyes, but if you have a model with +100 tris. its not readable anymore and that reason then is not valid anymore.
Booth FBX (Autodesk) and the Collada format (PS3 & co.) are designed from a different perspective beeing:
- interchangeable (any platform, OS, engine, parser,...)
- extend able with newer and xtra features (thats why the tags and the props in the XML). Like for example Collada supports face friction properties and other physics stuff hardly anyone with a simple engine would ever need.
- open for others to adopt
but if you dont care about those points its a lot easier to create something that is:
- smaller
- stripped down to the core (topology + UV)
- quicker to develop / adopt
I never though about this kind of contraint before, before when I had the choice between Collada and FBX, I asked Collada because of Melscript.
But Actually, the FBX 2010 version follow Collada for the melscript commands list, etc...
I just prefer to delelete all the informations I don't need in the exported file with some Mel scripting.
For this test, here a the constraints :
- This test is full mel script done. I didn't use the pop-up UI when we export manually.
- Collada and FBX file was exported as ASCII file.
- Only the mesh + Uvs + material + edge smoothing and hard informations was exported.
- test was done on a simple object of 132 poly with material (with texture file)
Result :
This test will show us the file size. The only thing can say is there are probably more informations to import and to parse in the big file than the other one...
Collada use XML synthax and the other one I don't know... (what kind??)
But I never created a parsing tools for this kind of data for creating back the 3D model in an engine.
Actually I work on a little project for Facebook using flash technology on the Away 3D engine, and collada seems to be fine.
Here are the kind of model with use in the game : http://samavan.com/3D/ThomasVaroux_PortFolio/samavan_pc_Girl_A_A001.jpg
But I will probably reduce per 1/3 the polycount, because flash engine has really lot of constraint like a nintendoDs one (DS is better haha!!)!
But just try it on your side, I maybe did a miss!
Finally the right question we can give to longshot could be : What engine are you working with?
http://board.flashkit.com/board/showthread.php?t=759766
basicly a teapd with 512 faces (1024 tris) including Vert table, face tableand UV vert + face table:
the reason why I wanted to have such tiny files was because back then I was researching and developing a 3d engine that would load lots of different meshes in a environment and loading times had to be fast in order to create a real different experience in flash.
I ended up snapping verts to integer values and mapping UV coordinates to a fixed texture size (so no floats but low integers for UV coordinates). In the end I got a super small file size that did not really needed to be parsed in AS3 as I could read it right away in a loop and thus loading and initializing times in the engine were superb.
I always wrote my own engines never really dug into Papervision, Away, Sandy,... because I wanted specific stuff + understand what went on under the hood.
My last engine is still NDA and I am not yet allowed to show screens or specs public but its basicly a engine that smoothly scrolls large worlds build with instances and prefabs (like the unreal 2+ engines). A world sometimes can have up to 800.000 faces but you can only see a fraction a time (maybe like 800-1400 tris + sprites) and it scrolls super smooth.
I hope to finish that project soon so that I can show stuff I did for it. If you are interested into specifics we can PM and I might be able to show you a fraction.
if you are into scripting or actionscript, here is some research stuff from me:
Affine Texture mapping:
http://www.renderhjs.net/bbs/flashkit/3d_engine_kit/affine_texture_mapping_flash_tutorial.gif
autodesk ASE format:
http://board.flashkit.com/board/showpost.php?p=3830805&postcount=6
easy AS3 3d engine with texture maps (80 lines of code)
http://board.flashkit.com/board/showthread.php?t=778852
skewing mapped triangles (dated, I rediscovered this later as affine texture mapping)
http://board.flashkit.com/board/showthread.php?t=722290
well and lots of other stuff,- if you have question of that kind drop me a message
Very interesting!!!!
Do you have some good link for learning more about it... I really want to try too...
Actually I only script with melscript and Javascript, and will use engine like Quest 3D or Virtools for creating application...
Then I really would like to try another way...
The links you gave are really insteresting too!