Im adding my thoughts to this:
First of all the model editor will act as central tool to combine and manage asset components (mesh, textur, shader, animation file, scripts) into a native, internal cafu format.
Regardless of which format it would be, it should transport relevant information from a 3d package into the Cafu Model Editor where it will be further processed and de-cluttered of unneeded data.
- Ideally it should allow for import of as much information as possible:
- Mesh, uv channel and textures for static components
- Skinweight, skeleton structure and animation sequences for animated models.
Additionally, physical attributes, LOD Sets, and collision meshes should also be supported.
Export is much less important, textures would be already accessible, shaders have no need for export. Animation may be complex and you better ask for the original file, which would be more accurate, same goes for weighting of skin clusters. Would be nice to have it later but i have no real need for it.
But i would like to see an export ability for bsp elements, including multiple UV channels (color, lightmap channel) so one could export a bsp group and use external renderer software to generate lightmaps, then import it back into cafu.
Regarding the format:
Collada is open scource, made by sony, so its pretty big and accepted as modern standart for fully featured assets (mesh,skin,joint structure, animation data...). I found that most Autodesk packages are having more and more serious trouble of updating good plugins for collada's .dae export. Reason for this could be that Autodesk would like to promote its own fbx format.
However there is a converter (on autodesk site) for "fbx to dae" which is said to be much better than exporting dae out of-the-box.
I have no experience yet using it, but heard that it seems to be quite good so far, and can also contain physic informations.
FBX is property of Autodesk, therefore almost any of their packages support it natively (Maya, 3dsMax, XSI, CAD ..) and can contain a lot of information, like collada. Sometimes its a bit naggy about scaling between packages but it retains all data as it should.
Some packages like blender use a (python) script for working with fbx.
Autodesk provides a nice SDK
http://usa.autodesk.com/adsk/servlet/pc ... eID=123112
Personally i had not much problems using fbx, but never came to the point of using collada. Both formats act as interchange format, so they carry all of the relevant information. But both should be processed for perfomance issues either before exporting or after importing into the model editor.
Overall i read through many forum threads and found out that there is still a split between both formats
In this (rather new, November 2010) game developers blog, the author explains why they drop collada and prefer fbx, as it seems to be more accurate:
http://www.mobilebits.de/Blog/post/2010 ... r-FBX.aspx
However scoll down and find a comment of some Okino coder (Okino polytrans is THE software for converting almost any format into any another), who claims that collada is a
much better format than FBX (few people really know the difference at the core technical level)
. This conversations extends further down so might be a good source to read.
It's hard to say which one is better until different exporter for different packages are tested for how they maintain the relevant information.
I heard the same, ogre's mesh and skeleton files are said to be pretty good and already have mature exporter for almost any valuable package. Maybe worth a try..
Cafu News feed
