[WF-Protocols] Summary of ideas from wallaba's first proposal - meshes only

[Eason Choo]

Peter Amstutz wrote:

>>- I think we shoudl split the file up like the cal3d format. I.e. have a
>>mesh file, a material file, a skeleton file and a skeleton animation
>>file. however, in the mesh file, it'll contain the skeleton it binds to,
>>and then vertex->bone linkage/weight data, but all the skeleton data in
>>a chunk sepearte from the mesh data but in the main mesh chunk, this
>>will allow people to skip everything to do with the skeleton easily,
>>just by ignoring th eone chunk.
>>    
>>
>
>I think splitting it up across multiple files is a bad idea.  It then
>becomes very easy to break things by accident by mixing incompatible files
>(say a skeleton with the wrong mesh data) or deleting one of the files by
>accident.  If the file is organized properly it will be trivial anyway to
>ignore parts the application doesn't understand.
>
The main ponit of splitting skeleton from model data is that more then 
one model may use the same skeleton. It doesn't seem right to include it 
all into the same file.

>
>Actually, I'd lean towards a highly integrated format, going so far as
>embedding png and jpg textures into the file itself :-)  Although you
>wouldn't want to do that with a text format.
>
>Perhaps a better way to go is to specify that the components of the model
>must all be stored in a directory, each component of the model is a file
>with a specific name (mesh.dat, material.dat, skeleton.dat etc).  Then
>they can be distributed by storing them in a zip or tar.gz file.
>
I'm not sure I like the idea of zipping it.

If we are to allow skeleton and material data to be put into a single 
model file, then I'd suggest we make this more like a database, and make 
the main format more of an "opendatabase", meaning any number of 
skeletons, materials or models can be in a opendatabase file. Any number 
including 0. meaning, you can separate your data into separate skeleton, 
material and model files, or you can keep it in one selfcontained file.

>
>  
>
>>so the model format will become:
>>
>>* Mesh (1)
>>  - Name
>>
    - Shader Name <--- forgot this

>>  * Mesh-Layer/Sub-Mesh (1 or more)
>>    - Vertex Data
>>    - Face list
>>    
>>
>
>Triangles only, triangles and quads, or arbitrary polygons?  As far as I
>know, most modelers don't export anything more complex than quads.
>  
>
I'm thinking just triangles. support for more then one type of face 
would complicate things. and its easier to combine triangles then it is 
to triangulate polygons. But that would be left up to teh engine loading 
the omf file. They can then chose to keep polygons convex or not.

>  
>
>>    * Vertex Normals (1, optional)
>>      - Normal data
>>    * UVs (1 or more) <-- each chunk represents a layer
>>    
>>
>
>We also need to describe which material to apply to each face.  This can
>be as simple as an index into a list of materials...
>
No each  mesh-layer/sub-mesh will have a differnet material outlined by 
the shader-chunk the model uses.

>
>  
>
>>  * Skeleton Binding (1 or more)
>>    - Name of Skeleton
>>    * Bone Binding (1 for each bone)
>>      - Vertex-weight pair
>>  * Convex Hull (1)
>>    - Vertex Data
>>    - Face List
>>    
>>
>
>What is the Convex Hull used for?
>
Collision detection and some other things. Sometimes convex hull data is 
hand-made, thats why i think it should be there.

>
>  
>
>>First of all there was talk about unindexed data. I think that when its
>>unindexed, thats a form of optimization, and should be kept out.
>>secondly, its not possible to describe an entire model with a single
>>tristrip or trifan or whatnot, so there woudl have to be more then one
>>"renderop" chunk or whatever it'd be called. I believe the indexed form
>>is simplest. Of course i don't have much experience in converting a mesh
>>into unindexed form, if its something hard to do or needs manual work
>>for it, maybe we shoudl consider allowing unindexed data, but if its an
>>easy enough job to convert into unindexed data proceduraly, then i say
>>it should be kept out.
>>    
>>
>
>I would say to just use indexed data.  I don't see what advantages
>unindexed data has, and in fact you need your verticies to be indexed for
>UV mapping and skeletons anyway!
>
>  
>
>>If we do decide to provide support for manual LOD, I think it should
>>handled as multiple meshes in the same model chunk.
>>
>>We still need to decied whether to allow more than one model/mesh in the
>>same model file.
>>
>>I actually don't like the idea of multiple meshes per model anymore. I
>>dont' know why I even proposed it. Unless of course its for different
>>LOD levels.
>>    
>>
>
>Does anyone know if any modeling programs actually support exporting
>models at multiple levels of detail?  I think it would be convenient for
>all of that information to be together in one file, but if nobody is going
>to use such a capability then it is rather pointless.
>
Thats why I think manual LOD shoudln't be directly supported, instead 
the user of OMF would just export several different models, and link 
them together as LOD levels in their importer/model editor. Its in that 
last step that they will assign which model for whcih distances or 
however they do it.

   Wallaba