[WF-Protocols] RE: Protocols

[Eason Choo]

>
>
>>Then how about putting the skeleton binding in the submesh (where the
>>bone weights are) instead of in the main model/mesh.
>>    
>>
>
>This doesn't seem right to me, because it implies that you could have 2
>SubMeshes in the same mesh linked to different skeletons. Since SubMeshes
>are mainly about separating out parts of the mesh which use different
>materials or vertex formats, but are otherwise part of the same whole, I
>can't see this being useful. Have you ever seen an animator using 2
>skeletons to animate a single mesh?
>
The purpose of doing it like that was to keep skeleton infomration 
together in one chunk, not to allow 2 skeletons to morph a single mesh.

>
>  
>
>>This would allow a
>>mesh to be assignable to more than one skeleton type, but mainly it
>>keeps the optional skeleton section together so its one section or none,
>>not two sections or none.
>>    
>>
This really isn't a necessary feature, i don't think anyone demands it, 
its just a side affect of trying to consolidate the skeleton infomration 
at hte submesh level.

>For the latter, I suggest separating out the skeleton binding and bone
>assignments and putting them together in their own section of the mesh
>format, meaning that the whole subtree is optional rather than one optional
>section in the mesh header and a linked optional section per submesh. There
>is still a dependency; after all you need a set of bone weights for each
>submesh within this section and they must match with the submesh sections
>defined elsewhere in the model. It's a swings and roundabouts thing, either
>way works but I don't believe you can eliminate the dependency because it's
>part of the underlying structure of the data.
>  
>
If all the skeleton infomration can be put into an optional skeleton 
chunk in the root/main model chunk, that would be ideal.

>BTW, I _strongly_ advise keeping material definitions out of the model
>format; include abstract links instead like a material name and define the
>materials elsewhere. This allows reuse of materials between models, and you
>can keep the material definitions human readable (because they're not large
>so the difference between text and binary at runtime is negligible) which
>means you can tweak them without reexporting the model or indeed without
>recompiling your app. This is an extrememly powerful technique in my
>experience.
>
I suggest structuring the file like a databsae, where you can haveing 
any number of 'model' objects, and any number of 'material/shader' 
objects which are exclusive. So you'll probably want to keep the 
materials separate from models, but still allow more than one object in 
a file, much like the material scripts in ogre.

>
>  
>
>>I'm no Cal3d guru, but from what i can understand, cal3d's LOD system
>>works by collapsing vertices into other verticies. Each vertex is
>>assigned two numbers: an ID of the vertex the vertex collapses to, and
>>the number of faces that are removed during the collapsing. Vertices are
>>pre-sorted in order of collapsing, the first to collapse at the end of
>>the vertex array. Then given a floating point LOD value, the mesh can be
>>collapsed. Is this a common technique? or is it something only Cal3d
>>does  (ie. should we include support for this type of LOD data or not?)
>>    
>>
>
>OGRE uses the edge-collapse approach too to calculate the LODs, although we
>do not collapse on the fly because to do so requires in-flight geometry
>modification using the CPU (of at least the indexes) which we generally try
>to avoid because we're trying to assume that all the geometry buffers will
>be on the GPU, not in CPU memory. The LOD popping is sometimes noticeable,
>so it might be nice to eliminate it, but there are other alternatives such
>as cross-fading 2 LODs using blending (a technique described in game
>developer recently) which I'm still open to. The sorted buffer sounds
>useful, although one possible problem with sorting vertex data by collapse
>order is that you can reduce your cache coherency (since GPUs work best when
>the vertices being indexed are near to each other).
>  
>
It was suggested in IRC that all procedurally generated LOD be left out 
of hte format, so the automatically generated LOD from ogre and the 
sorted vertex collapsing LOD used by Cal3D be left out of the format and 
the OMF->whatever converter be responsible for generating the LOD, since 
its much like optimizing the data for the engine. The only LOD that 
should be in the format is hand-made LOD, like proxy meshes.

    Wallaba