[WF-Protocols] Discussion on Open Model Format

[Miguel Guzmán]

Killemov wrote:

> A binary (IFF-style?) format should be the primary one. An XML-version 
> should be used for debugging and tweaking purposes. Most tools only 
> need to implement the binary format and there should be a converter to 
> and from XML. (Binary <-> XML.) 

    So, this IFF format is one of those chunk-based, separated by 
headers, binary files that everyone on IRC was talking about :) I didn't 
know anything about it until today, but here it is quite well explained:

http://netghost.narod.ru/gff/graphics/summary/iff.htm

    Seems really interesting and quite useful for the efficient binary 
format, though I agree with Jorrit in starting with an XML format.

> The standard can only be published in a document. But it should be 
> supported with a reference implementation. 

    Agreed. I myself can make converters to and from Cal3D and Ogre, and 
wouldn't mind tryng to make converter / loaders for other engines.

> An IFF-style format allows for different levels of self-containment. 
> The simplest file could exist of bare geometry (3 X,Y,Z sets for each 
> triangle) with no color, texturemapping, material, skeleton and 
> animation data. And the most complex file could exist of different 
> types of geometry (Triangle, NURBS, ...),

    The issue of about different geometry is whether they are used 
outside 3D editors, for what I have seen most 3D engines use always 
triangles (vertex+normals). Should we take into account different 
geometry definitions?

    Ogre has, for each SubMesh, a GeometryData element, which I wonder 
could be different depending on the type of geometry, or it's just for 
the sake of not including the geometry data on each submesh if shared 
vertices for the mesh are used.
SubMesh: http://ogre.sourceforge.net/nightly/docs/classOgre_1_1SubMesh.html
GeometryData: 
http://ogre.sourceforge.net/nightly/docs/structOgre_1_1GeometryData.html

> sub-objects, several layers of texturemapping, animated materials 
> (even including vertex/pixel shaders), animation, morphing, ... with 
> all resources included in the file. (Take a look at Newtek's Lightwave 
> 'lwo format as a starting reference.) 

    The several layers of texturemapping and the shaders could perhaps 
go in the material definition (each submesh being assigned a material). 
In a general sense, IMHO the more stuff we include in the file(s) the 
better (needs not to be only one, we can always have one file for a 
mesh, another for a material, etc.) Do we all agree on this?

    BTW, couldn't find the lwo format specification on a quick google 
search. Anyone has an URL handy? I'll be adding all those URLs to the 
Open Model Format page.

> I found the current definition of a 'SubMesh' to be somewhat unclear. 
> The first impression is that a sub-object is implied (grouped by 
> geometry). But actually it is the collection of geometry that share 
> the same material. (grouped by material) 

    It should be material based. However, if we want to do a 
geometry-based division (for instance to swap parts of a model), perhaps 
we could use the "1 model -> N meshes" approach.

    Aglanor