[WF-Protocols] Re: Protocols Digest, Vol 2, Issue 3

[steve at stevestreeting.com]

Hi folks,

Quick intro, I'm the project lead from OGRE (http://ogre.sf.net) and I'm 
interested in helping this process along from our side.

>I agree with you generally, but dont really see the value of seperate
>StandardModel/SkeletalModel types.  If a mesh is not boned, then simply
>don't include the bone id/bone weight chunks in the file.  So your submesh
>block becomes:

I totally agree with Alan here. There is no difference between a skeletally 
animated and on-animated mesh apart from this optional information.


>      Submesh
>      - Texture/Material (per texture-unit)

I disagree with this. Your mesh should not care about how many texture units 
there are, or how many layers there are in the material you choose to use with 
it. The link should be just to a single material, and the material defines the 
number of texture layers and the source of the texture coord data (from one or 
more of the texture coord sets, from auto generated texture coords, from 
vertex shaders etc. Meshes should IMHO know nothing about shading parameters, 
they should just provide texture coord data which the material can choose to 
use however it sees fit.
		
>      - Vertex data

This is optional; SubMeshes should have the ability to share vertex data if 
they choose (this can be useful when using hardware vertex buffers).

>      - Face data

Just a quick point - a submesh could use geometry that is indexed or 
unindexed. If unindexed, then the vertex data IS the face list. I think this 
should be renamed to 'index data' and is optional.

>      - Texcoord data (per texture-unit)

Again just a clarification - it's not per texture unit, this is just input 
data which a material may choose to use. Nothing ties the material to use it, 
nor does it follow that texture coord set #0 is used for texture layer #0, you 
can mix and match.

>      - Bone ID's (optional)
>      - Bone Weights (optional)

Bone weights are pairs of <boneID, weight>, they're tied together therefore 
should be one entry.

>-Precomputed mesh lod's.  I prefer my lod done offline by an artist, rather
>than in realtime for both speed and apperance.

In OGRE we support 2 types of LOD - manually assigned and automatically 
calculated, because both are useful. In my experience when you're making a 
manual LOD, you want control over everything so you might change the vertex 
data, the material (to eliminate expensive multitexture blends, shaders etc), 
switch to a lower detail skeleton too etc. This actually means that you're 
switching the whole _mesh_ out when using artist-defined LOD.

When using pregenerated LOD however, there is a linkage between the top-level 
LOD and the lower detail lods, because they are procedurally generated. This 
means you can reuse some data between levels. In OGRE we use the same source 
vertex dta but change the indexes; this is more memory-efficient and the use 
of the same vertex buffer with more sparse indexes has little or no 
performance penalty when using hardware vertex buffers, which is our target.

So we have 2 sets of information about LOD in the Mesh, a list of LOD metadata 
which states the type of LOD to use at each level (calculated or manual); 
the 'manual' type just causes this mesh to act as a proxy for another mesh 
object at different LODs (so the file format just names the alternative mesh, 
and at runtime it binds this to an actual Mesh instance) whilst a 'calculated' 
entry indicatesthat each SubMesh actually includes alternative triangle index 
data. At the moment we only support calculated LOD on indexed data.

>-Swapable body parts.  This is a feature of Cal3d that really appeals to me,
>I have not really looked into the cal3d file formats so dont know how this
>is implemented.  Are all the body parts stored in a single file?  Or are
>all, say, legs in one file, all bodies in another and stiched at load time?

I like this idea, but the problem with storing this in the Mesh is that 
editing it requires that you tie all your possible body parts together in the 
one file, and it's difficult to edit the information in a standard modeller 
without custom extensions. I'm not sure if there's a way to solve this.

>-Quaternions or axis/angle pairs?

_Definitely_ quaternions, or if not then a single angle/axis rotation (ie an 
aribtrary axis rather than cartesian). Cartesian axis rotation has many (well 
documented) flaws, and most engines worth their salt use quaternions 
internally anyway.

>-Left handed or right handed?

I vote for right-handed - it's what's used in all the standard math texts. 
Even though I wrote the D3D back-end for OGRE first, I used right-handed 
because it's just more standard IMO. BTW this also implies counter-clockwise 
face winding.

>-Should it be possible/legal to store several completly seperate models in a
>single file?

I think this is a bad idea; we should use archive formats for combining files 
into a single-file package, it shouldn't require custom editors to combine / 
break apart / reorganise resources.

Other things we should consider:
- bounding volumes (we use AABB & sphere, other people may use OBB or convex 
hull)
- edge lists 

On the format note, I agree with Jorrit that XML should be our first choice. 
We're building an interchange format, and that's exactly what XML was designed 
for. As for efficiency, I personally expect each engine to maintain local 
autonomy over it's runtime binary format, since each engine may choose to add 
optimisations - I _want_ an explicit conversion stage in which I can 
precalculate information that will be useful to me at runtime, and I don't 
believe there is a lot of merit in standardising that. 

The other reason is that I've seen a huge increase in the number of people 
producing tools since we adopted an XML interchange format in OGRE, simply 
because people can easily write scripts to read / write XML in any language, 
great or small. We still have a conversion stage between this an the binary 
runtime format, and this is used not only to compress and optimise the common 
data, but also as an entry point to calculating data too (we use this for LOD 
calculation for example, and plann to use it for more things).

I think tools should read / write the XML format, where utility, ease of 
integrtion are far more important than loading / saving efficiency. Once the 
data is in memory, it doesn't matter where it came from (I assume you won't be 
referring directly to the XML structure during tool execution). Each engine 
should be free to convert that XML into it's own binary runtime format, over 
which it has complete control; I think this local autonomy is important 
because engines need the flexibility to reorganise their internal data formats 
to suit local assumptions and changing needs - this is the primary reason I 
have been steadfast in my principle to support only a single runtime format, 
and tackle other format support through exporters / converters; and our 
serialisers exist precisely to stop people from caring what our binary format 
is, because we reserve the right to change it. IMHO establishing a binary 
standard is inappropriate, because if people have to use custom chunks to 
represent their custom data, or wish to rearrange the vertex data (for 
example, to pack vertex into alternatively structure buffers to make it more 
efficient), it devalues the whole point of a standard in the first place, 
becoming a standard in name only. IMHO trying to establish a format that 
fulfils both openness and runtime optimisation is a recipe for disaster, 
because they are conflicting requirements. 

Well, that's my oar in, I hope I didn't splash people too much :)

Steve