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

[Peter Amstutz]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Sat, 5 Jul 2003, Eason Choo wrote:

> - I'm thinking screen-centric, i think thats more common..

I agree, I think that's what most 3D programmers are used to.

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

I think splitting it up across multiple files is a bad idea.  It then
becomes very easy to break things by accident by mixing incompatible files
(say a skeleton with the wrong mesh data) or deleting one of the files by
accident.  If the file is organized properly it will be trivial anyway to
ignore parts the application doesn't understand.

Actually, I'd lean towards a highly integrated format, going so far as
embedding png and jpg textures into the file itself :-)  Although you
wouldn't want to do that with a text format.

Perhaps a better way to go is to specify that the components of the model
must all be stored in a directory, each component of the model is a file
with a specific name (mesh.dat, material.dat, skeleton.dat etc).  Then
they can be distributed by storing them in a zip or tar.gz file.

> so the model format will become:
>
> * Mesh (1)
>   - Name
>   * Mesh-Layer/Sub-Mesh (1 or more)
>     - Vertex Data
>     - Face list

Triangles only, triangles and quads, or arbitrary polygons?  As far as I
know, most modelers don't export anything more complex than quads.

>     * Vertex Normals (1, optional)
>       - Normal data
>     * UVs (1 or more) <-- each chunk represents a layer

We also need to describe which material to apply to each face.  This can
be as simple as an index into a list of materials...

>   * Skeleton Binding (1 or more)
>     - Name of Skeleton
>     * Bone Binding (1 for each bone)
>       - Vertex-weight pair
>   * Convex Hull (1)
>     - Vertex Data
>     - Face List

What is the Convex Hull used for?

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

I would say to just use indexed data.  I don't see what advantages
unindexed data has, and in fact you need your verticies to be indexed for
UV mapping and skeletons anyway!

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

Does anyone know if any modeling programs actually support exporting
models at multiple levels of detail?  I think it would be convenient for
all of that information to be together in one file, but if nobody is going
to use such a capability then it is rather pointless.

As I think someone mentioned earlier, there are really several issues
here that need to be considered separately:

1) Representing the model's structural data (vertices, faces, curves(?),
subdivision surfaces(!) etc)

2) Representing the model's visual properties (materials)

3) Representing animations (this actually leans heavily on (1) but has
many of its own issues as well).

[   Peter Amstutz   ][ amstutz at cs.umass.edu ][ tetron at interreality.org  ]
[Lead Programmer][Interreality Project][Virtual Reality for the Internet]
[ VOS: Next Generation Internet Communication][ http://interreality.org ]
[ http://interreality.org/~tetron ][ pgpkey:  pgpkeys.mit.edu  18C21DF7 ]
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)

iD8DBQE/B+HoaeHUyhjCHfcRAuDsAJ4s/VNfBypzaQWVGH9jegaGwh5onACeK5O6
mPbKYitGq2tgcTyxMmlzL6w=
=xwZb
-----END PGP SIGNATURE-----