[WF-Protocols] Wallaba's initial proposal

[Eason Choo]

>
>
>Shall we go on with the
>discussion on requirements for meshes / submeshes so we can see more or
>less which data structures are we going to serialize?
>
>
>  
>
As an initial proposal: (very rough) how 'bout:

StandardModel
  - Name
  - # of Meshes
  StandardMesh
    - Name
    - # of sub meshes
      Submesh
      - Texture/Material (per texture-unit)
      - Vertex data
      - Face data
      - Texcoord data (per texture-unit)
      - spring systems (optional)
  (optional)Hull
    - Vertex data
    - (optional)face data
 
SkeletalModel
  - Name
  - # of Meshes
  - Name of skeleton
  SkeletalMesh
    - Name
    - # of sub meshes
      SkeletalSubmesh
      - Texture/Material (per texture-unit)
      - Vertex/Face/texcoords/bone weights/
      - spring systems(optional)

Skeleton
  - Name
  - Bones

Animation Sequence
  - Name of skeleton
  - Animation type (cycle, action, pose)
  - Animation data (num keys, keys for each bone)

Texture/Material
  - Name
  - Type (2d, 3d, 4d, shader)
  - Colour
  - Resource name (name of a file or engine-specific internal resource name)

I know the above may have been presumptuous but let me explain a bit.
The above assumes model/mesh/submesh format like cal3d, since we were 
going for the smallest-common-denominator style, it woudl seem that its 
necessary to have it like that. For systems that do not use a 
model/mesh/submesh, but more like a mesh/submesh, then this will still 
work, either ignore the groupings of meshes into models and use each 
mesh as standalone meshes, or assume one mesh per model.

I suggested we split up a standard model from skeletal model becuase i 
think they way the "type" of model is described to the reader of the 
file, is to be in the main chunk (the type of object described by the 
type of chunk) not a flag within the chunk. The same could be done with 
the texture/material i proposed, however, unless we plan to embed the 
texture/fragment program data in this model file, the data really 
doesn't change given the "type" field but rather how the reader 
interprets it. Is the data going to be embedded?

i've also suggested putting in spring system data (to make cal3d and 
others happy) and convex hull data for the model.

i realise my proposal is missing some things like how to blend texture 
units together

As for mesh/submesh structure for assigning more than one material to a 
mesh, I can't think of any other way to do this other than  (if i 
remember correctly), the .3ds format assigns materials to faces instead 
of faces to materials. I think faces to materials is better imho, (no i 
can't really back that up atm ;)
^^^ Wallaba's initial 0.02$

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