[WF-Protocols] RE: Protocols

[Steve Streeting]

> 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?

> 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.

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.

> Agreed, so we'll also need a way to describe the indexing type if theres
> no 'face list' chunk trilist/tristrip/trifan etc.

Yep, each SubMesh could have:
- a primitive operation type (trilist, tristrip, trifan)
- an option stating whether the data is indexed or not

If you wanted to mix 'n' match a trilist and a tristrip in the same model,
that's 2 SubMeshes which maps well down to the 3D API layer because they
would have to be issued as separate rendering operations (the same as when
you change vertex formats or materials).

> Thats pretty much what i mean, texture-layer would've been a better word
> to use then texture-unit, the main requirement i was specifiyin ghere is
> more then one set of texcoords, since in my initial proposal the linking
> to the material/texture was done before the texcoord data.

Texture coordinate set, buffer, stream if you like, but both layer and unit
imply a material / shader binding, which is what I'm trying to avoid. It
should be clear that the material should pick from the source data, not the
source data driving the material.

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'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).

Regards
Steve