[WF-Protocols] Wallaba's initial proposal

[Matze Braun]

On Tue, 1 Jul 2003, Eason Choo wrote:

> >
> >
> >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.
Wasn't this planed as a general format? Why smallest-common-denominator?

> 
> 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?
That's a very bad idea IMO. You can't simply introduce a new type instead 
of adding flags (your typecount doubles with each flag...). You can do 
alot simpler here: If the model has bones, then it must be a SkeletalMesh. 
Anyway both will be saved as "Mesh".

> 
> 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
Maybe we should dicuss these details in other mailthreads to get this 
discussion a bit more ordered...

> 
> 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 ;)
Materials should be separate from faces. Faces should only link to 
material, because materials can become very complex and are often shared 
between multiple faces.

Back to the meshes. Lemme propose it a bit different: (I'm also avoiding 
all the details of meshes, lights, materials. I want to show a nice 
general system which is extensible for different object types)

(* means multiple entries allowed. The entries can either be links to 
 already defined things or a comeplete new entry of the type can be 
 given)

TOP:
  *Materials(MATERIAL)
  *Objects(OBJECT)
  *Animations(ANIMATION)
  *Maps(MAP)

OBJECT: An object is used for all entities that have a position in the 3d 
	world.
	- ID
	- Type of object (predefined types:
		Camera, Mesh, Light, GameEntity)
	- Transform (position, rotation, scale)
	- Objecttype specific data (details not discussed here)
	  (for cameras)
	    -lookat, fov, ...
	  (for meshs)
	    -vertices, faces, material, bones, lod, ...
	  (for lights)
	    -radius, intensity, color, ...
	  (...)
	*subobjects(OBJECT)
		  This can be used to create hirarchies of meshes. The 
		  transform of the parent object should be applied to all 
		  subobjects.

MAP:
	-Name
	*materials(MATERIAL)
	*animations(ANIMATION)
	*objects(OBJECT) - the objects in the map
	[for portal based engines:
	*sectors(SECTOR)]

SECTOR:
	-Name
	*materials(MATERIAL)
	*animations(ANIMATION)
	*objects(OBJECT)
	
MATERIAL:
	-details not discussed here

ANIMATION:
	-details not discussed here

Some more comments:
-It should be possible to put additional data in each section. This is 
 needed to keep the format flexible for later additions and game/engine 
 specific enhancements (a namespace feature could be very handy here).
-We should have a way to reference sections accross files. So that you can 
 put models from other files in your mapfile for example.

Greetings,
	Matze