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

[Eason Choo]

Aglanor wrote:

>Hello all,
>
>	Perhaps it is time to separate a bit the threads regarding meshes,
>materials, other objects, maps, etc. We could do a first approximation
>on meshes, and see how it turns out. 
>
>	Here are some ideas I consider are an agreement between all
>participants. If I'm wrong please correct me:
>
>	* Materials are to be defined separate from meshes. Meshes will be
>subdivided by materials used (1 submesh <-> 1 material), and will point
>to the material they use.
>
>	* For rotations, we'll use quaternions.
>
>	* The coordinate system will be right-handed.
>
>	* Manual LOD will be included.
>
>
>**********
>
>	Now, the things that are left to decide:
>
>	* the coordinate system will be screen-centric or world centric?
>
>	On a screen-centric system, you picture x and y axis defining your
>screen: x points to the right, y points up, and, being rigth-handed, z
>points to you.   
>
>	On a world-centric map, picture x and y defining a cartographic map: x
>points east, y points north and z points up.
>
>	The switch from one another is a simple rotation (which the sample
>implementation should provide, IMHO) but we should use one or the other,
>in order to not find some models turned 90º with respect to others.
>
>	* where will be the bones definition stored?
>
>	* will non-manual LOD (vertex & face collapsing) be included? perhaps
>as optionals, for the systems who use it?
>
>	* will be use the "model" concept, on a layer above a "mesh" (1 model
>-> N meshes)?
>
>	* shall we be able to reference sections on other files?
>
>	* [your opinion on other issues goes here... :)]
>  
>
- I'm thinking screen-centric, i think thats more common..

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

so the model format will become:

* Mesh (1)
  - Name
  * Mesh-Layer/Sub-Mesh (1 or more)
    - Vertex Data
    - Face list
    * Vertex Normals (1, optional)
      - Normal data
    * UVs (1 or more) <-- each chunk represents a layer
  * Skeleton Binding (1 or more)
    - Name of Skeleton
    * Bone Binding (1 for each bone)
      - Vertex-weight pair
  * Convex Hull (1)
    - Vertex Data
    - Face List

Now there were a few things discussed in the last week that will go 
against what i'm suggesting here, so let me explain my thinking.

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.

Secondly, the skeleton binding is done in a single chunk. I explained 
this above. However, i suggest we do assigning vertix-weight pairs to 
bones rather than bones to vertex weights. I think this is the most 
efficeint wayt of supporting multiple influences per vertex (rather then 
having a new bone binding chunk per vertex, its per bone).

I also think we should leave LOD out, unless of course the automaticlly 
generated LOD models are going to be supported. If its manual LOD where 
a new mesh is assigned, i think that should have nothing to do with this 
format, not even linkages in the model to another model representing a 
lower/higher LOD state. I think it would be easy enough when you have 
your omf->foo converter where foo is a format that incorporates the LOD 
level, that it can be executed something like:

omf2foo -l1 mymodel_l1.xml -l2 mymodel_l2.xml -l3 mymodel_l3.xml etc

Also, I think that the way manual LOD like this is handled by each 
engine is different, as in how many levels, when to swap the levels, etc.

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.

    Wallaba

http://wallaba.sytes.net/~wallaba/

"Gross stupidity, falsehood, and muddled 
thinking are not dream; and form no escape 
from life to a mind trained above their 
own level." 
    -H. P. Lovecraft