Igors.. from the manual:

Geometry cache XML description file
When you create a geometry cache, your cache is saved to disk as a .mc (Maya cache) file and an .xml description file is generated for your cache. The XML (eXtensible Markup Language) description file contains a list of important cache attributes that Maya uses to locate the data files for your geometry cached objects and other useful information like its cache’s time range. You can use the XML description file to keep track of your geometry cache files and their associated objects and scenes.

The geometry cache information contained in the XML description file is structured or organized by XML element and attribute. Each regular element (such as cacheType and Channel) or nested element (such as channel#) contains single or multiple attributes (such as Type, ChannelName, or SamplingRate) that list specific geometry cache properties.

Autodesk_Cache_File Properties:

cacheType

Specifies the format of the geometry cache on disk.

Type

-OneFile

Specifies that the geometry cache is contained in a single Maya cache file.

-OneFilePerFrame

Specifies that the geometry cache is divided into multiple Maya cache files, one file per cached frame.

time

-Range

Specifies the frame or time range of the geometry cache. For example, if a geometry cache contains an object’s deformations from frames 1-25, then the Range attribute would be 250-6250.

The time range is measured in time steps. Time steps are sub-frame units. Each geometry cache frame contains multiple time steps. The number of time steps contained in a frame is determined by your current Working Units (Time) user preference setting.

Number of time steps per frame = 6000/frame rate. For example, if your Working Units (Time) preference is set to Film (24 fps), then each of your geometry cache’s frames contains 250 time steps.

cacheTimePerFrame

-TimePerFrame

Specifies the number of time steps in each frame for the geometry cache.

cacheVersion

-Version

Specifies the version number of the Maya geometry caching functionality that created the current XML description file and its geometry cache files.

-extra

Specifies the following for the geometry cache:

The name of the geometry cache’s Maya scene file and its location on disk.
The version of Maya in which the geometry cache was created.
The name of the account that created the geometry cache.

Channels

Contains all object or channel-specific geometry cache information.

- channel#

Each geometry cached object is assigned its own channel# nested element. For example, if you select 5 objects, set File Distribution to One File or One File Per Frame, and cache their deformations, then one XML description file would be generated and it would contain the following nested elements: channel0, channel1, channel2, channel3, and channel4. However, if you set File Distribution to One File Per Geometry, then one XML description file would be generated for each of the selected objects and only one channel# nested element would appear in each .xml file.

-ChannelName

Specifies the name of the object to which the geometry cache belongs. This value is unique to each geometry cached object.

-ChannelType

Specifies the data type of the array in which the channel’s geometry cache data is stored. Currently, only DoubleVectorArray is supported.

-Channel Interpretation

Specifies which type of object data is driven by the channel’s geometry cache. Currently, only the Positions attribute value is supported.

-SamplingType

Specifies whether or not the channel’s deformation samples are saved to disk at equally spaced intervals. Regular indicates that the samples were saved at equally spaced intervals and Irregular indicates that the samples were saved at unequally spaced intervals.

These values are used by Maya to help it search for the channel’s geometry cache files on disk more efficiently.

Typically, the sampling type for a geometry cache is always Regular after creation. However, if you edit your cache in a way that changes its sampling interval, its sampling type will change to Irregular. For example, if your geometry cache evaluates every frame, and you append a cache to it that evaluates every 2 frames, then your cache’s sampling type would change to Irregular.

-SamplingRate

Specifies the spacing of the channel’s geometry cache files on disk when they were first created.

SamplingRate = Evaluate every frame(s) x Save every eval(s). For example, if you set Evaluate every frame(s) to 0.5 and Save every evaluation(s) to 1, and your user Working Units are set to 24 fps, then one sample would be taken and saved to your geometry cache every 125 time steps or half-frame.

-StartTime

Specifies the time in time steps for the channel’s first cache file on disk.

-EndTime

Specifies the time in time steps for the channel’s last cache file on disk.

Hi, Felix

FelixCat - 28 March 2007 03:44 PM

Mac Reiter, from TAFA put this… i don´t know if is of some use, regarding all this news from the Maya front. BTW, here we go:

Let us explain some tech. details (sorry if they aren’t interested). Yes, mdd file is pretty simple . There are NO any probs with read it.  But there IS a big prob how to apply it. In LW all is same simple: apply “mdd vertices” to vertices from lwo file. However, in EI it does not work. A simple experiment: in LW create a simplest cube. In LW it has 8 vertices. Import it into EI. Here are 24 vertices (see Group Window, Info Tab). So, what to do with only 8 mdd vertices? Any importer can create extra vertices for EI in any order that importer wants. That’s why we could not use mdd for our tasks.  Maybe it’s possible to restore a corresponding “what belongs to what” but to check this we need a representative set of mdd files together with FACTs.

I don’t know how people are using mdd or how do I gain access to it? I would like to use it if it works. Then I could possibly help advocate more solutions. I thought it was not available? or is it gnome that isn’t available?

Hi, Brian

Paralumino - 28 March 2007 04:39 PM

-ChannelType

Specifies the data type of the array in which the channel’s geometry cache data is stored. Currently, only DoubleVectorArray is supported.

-Channel Interpretation

Specifies which type of object data is driven by the channel’s geometry cache. Currently, only the Positions attribute value is supported.

So, here are all probs as with mdd (see our previous post to Felix here). Cause there is also no subject (model) that vertices positions should be applied to.

Paralumino - 28 March 2007 04:39 PM

Igors.. from the manual:

Geometry cache XML description file
Specifies the time in time steps for the channel’s last cache file on disk.

So this is a more universal format of .MA?  Everybody can use it. And it has vertex animation output.

EIAS only need to read it, and long as it can convert basic data type like a cube will remain only the amount of verts that is specified and not so some special EI thing and make the cude 24 verts

Has there been any advances, or breakthoughs in the topic of this thread?  Status? nucleus? Maya2Eias. Ngnome. mmd

Not yet… but I’m sure it will continue after 3rd party companies finish off their UB porting.

Just as a little aside: Luxology have decided to embrace mdd-import for Modo 301, since it wont have full animation capabilities. The results look pretty impressive. Looks like there is people out there who believe in mdd.

I’m still puzzled about the problems the Igors describe for importing vertex-level animations. How do other apps do it? What is the bottleneck? Is it the way EIAS reads models from other programs? Is this an argument for putting a big effort into improving file-import capabilities?

Hi, Manu

Manu - 16 May 2007 11:31 AM

I’m still puzzled about the problems the Igors describe for importing vertex-level animations.

Read our post #32 in this thread, don’t hesitate to ask if something isn’t clear.

Manu - 16 May 2007 11:31 AM

How do other apps do it?

We can’t answer about all apps, but the apps we know (more or less) simply have not this prob. Their inside model formats are “mdd-compatible”, for example 3ds max cube also has 8 vertices. 

Manu - 16 May 2007 11:31 AM

What is the bottleneck? Is it the way EIAS reads models from other programs? Is this an argument for putting a big effort into improving file-import capabilities?

An importer receives a whole model info, not vertices only. But there is no corresponding between mdd vertices and a group in EI prj that vertices should be applied to.

As we wrote, maybe the prob could be resolved, but it requires a series of mdd(s) + FACT(s) to experiment. After all, if you’ve not them, so for what you need a reader? Up to now this request looks as “academic interest” rather than a real need.

I see. So internally, EIAS always uses 24 vertices to represent a cube. Only using 8 vertices simply isn’t an option. That’s interesting, you’d think that’s terribly inefficient. But since EIAS can handle large polycounts, it can’t be that inefficient.

I wasn’t posting my comment as a demand for mdd support, just pointing out what’s happening in the rest of the industry. Luxology could have embraced that Autodesk XML format, but instead they chose the more cautious mdd. I just thought that was an interesting point. Mind you, Luxology still have got their umbilical cord stuck to Lightwave, so a lot of their technical decisions should be viewed in that respect too. Still, the list of mdd ready apps is not bad: Lightwave, Maya, XSI, C4D, MAX, Messiah, Blender. That’s a lot of communication-lines you open there.

People who have used mdd to transport animations from Maya to Lightwave have already been pointing out the system has many limitations and inflexibilities, it’s not the all singing all dancing solution to all your problems. This little party-trick wont turn Modo into a fully-fledged animation app, nor would it turn EIAS into the perfect external renderer for Maya.

You’re right, my comment was mainly academic. But with a lot of these sort of features, it’s a chicken and egg game. You put it in, and suddenly people find uses for it. I never thought FBX would be useful to me, now I couldn’t do without.

Hi
For me, the communication between some animation only app to EiAS it´s not academic. i´m trying to work more in CA, and the limitations in the EiAS side are very depressing. I´m very used to the EiAS workflow, and love the materials and render quality. I´m not very happy with the switching idea… if there is no other way, i will move to Maya, is a very powerful app (but i´m not feel at home like with Ei).
FelixCat

Hi

FelixCat - 17 May 2007 10:52 AM

For me, the communication between some animation only app to EiAS it´s not academic. i´m trying to work more in CA, and the limitations in the EiAS side are very depressing. I´m very used to the EiAS workflow, and love the materials and render quality. I´m not very happy with the switching idea… if there is no other way, i will move to Maya, is a very powerful app (but i´m not feel at home like with Ei).

If, as you say, it’s not academic, and you try to work more in CA, so.. why you’ve no mdd files? What limitations are so depressive if there is nothing to limit yet?

About your “moving to maya..” what to say? GO. It’s really helpful/productive to know 2 and more 3d apps, to survive a period of first amazing, then (maybe) thinking, analyzing, comparing and many others.

There is also another thing/aspect with a moving to another app. It’s a bit private/delicate. One part of who moved don’t know/worry about it - they are just happy from realizing they use most powerful 3d app. Another one part understands this aspect very well, but prefer to be in silent about it. Want to know the secret?

Igors asking for mdd files and the coresponding fact files to try if it works… so why anyone haven’t sent those files till now? Is it so hard?

FelixCat - 17 May 2007 10:52 AM

Hi
For me, the communication between some animation only app to EiAS it´s not academic. i´m trying to work more in CA, and the limitations in the EiAS side are very depressing. I´m very used to the EiAS workflow, and love the materials and render quality. I´m not very happy with the switching idea… if there is no other way, i will move to Maya, is a very powerful app (but i´m not feel at home like with Ei).
FelixCat

Moving from one app that you know throughly and even enjoy to one which is unfamiliar and has a variety of unknowns is a very difficult decision.

It’s not so easy as to say “Go” like for Igors.  it was a very difficult choice which I deliberated for a very long time.

One thing that helped me when was to just incorporate the areas which I needed more support (UVs, modeling, and rigging), and not just switch. With FBX, I could use Maya to strength and temper some of EI’s weaknesses.

Just a thought.

AVT

Paralumino - 28 March 2007 07:55 AM

Hello Igors,

After an animation constructed in EIAS with the Morph Editor or IK, the resulting deformation could be recorded into an XML cache and then the IK stripped from the scene to simplify playback and eliminate IK enveloping calculations at render time.

b) I know you’ll want more information on XML and whats stored in them. I want to know. However I asked Marcel De Jong, instructor at Gnomon and Autodesk demo rep, that very question. His answer was, “The animation cache technology was specifically written to be open and is intended for the simplication of transferring deformation animation between software packages...particularly within the Autodesk family. However any program that wishes to read the XML file should be able to tap into the data.”

Its my intentions to get you XML samples. Alonzo may be able to assist in this endevour as well.

Brian, the only way I can impact more empathisis on what you have stated about the workflow, simplified pipeline, speed benefits, capability with dominant technologies, software and production house (e.i. larger budget projects)

is to use a MALLET!!!

besides that I can provide any data needed...be nice if I can get my hands on a Tazer… usually gets the point across and would probably speed up development.  just joking.