|
Dear Autodesk,
in your Maya documentation you state that the geometry cache is an open format.
Now, I would like to understand what do you mean with the adjective “open” since I see no spec whatsoever in your docs.
Currently you provide in your sdk a couple of python scripts that show contents of a cache file (one dumps on the console, the other converts a cache in ascii format for inspection). So I can surely understand the contents: point positions and unknown - undocumented -channels.
So I think there is a misleading abuse of the term open :)
Also I would like to know what is your perspective for your cache format.
Say I want to read Maya geometry caches -and note: without using the FBX SDK- in another application. Currently the geometry cache ALONE is totally useless in another application since it contains only point positions. No UVs, no normals, no color per vertex, no custom prim attributes. I would like to know if I could dump in it also other data at my please. It is basically useful only in Maya to speed up by loading from disk point positions assuming you have an existing model with all the prim vars I mentioned. Since from what I see there are additional channels it could be useful to dump extra data in it in the optic of reading it in another app without passing through the FBX pain.
Finally I would like to know what is the plan with all your cache formats.
Here’s a pan-o-rama of the current mess in Maya:
Animation --> Geometry Cache .xml (description file) “Open” nCache XML
Dynamics --> Fluids .mc (data file) not documented nCache
nDynamics --> nParticles .mc (data file) not documented nCache
nDynamics --> nCloth .mc (data file) not documented nCache
Dynamics --> Hair .mchp close format (similar similar to mc file) unknown
Animation --> Jiggle Disk Cache .mcj close format (similar to mc file) unknown
Dynamics --> Particles .pdc close format (simple description, not in detail) Particle Disk Cache (pdc)
It looks like mc will be the standard, so it would be nice to move on and get rid of the other caches.
What I don’t like is the abuse of term open, if open means running a python script through your caches and looking at the contents trying to figure out which data I could dump in channels… well I suggest at least some docs editing ;)
Here’s a good definition of open:
http://en.wikipedia.org/wiki/Open_format
Of on the other hand you want to make the format open, publish some specs and allow TDs to put some useful custom data in such files.
Regards,
Paolo
|