Brian, Igors
This conversation it´s growing more and more interesting (and promising) everyday, please, don´t stop it.

FelixCat

Hi, Felix, Brain

FelixCat - 22 March 2007 05:45 PM

Brian, Igors
This conversation it´s growing more and more interesting (and promising) everyday, please, don´t stop it.


FelixCat

Just today (accidentally) we noticed your recent posts, the forum’s server did not send us any mail notifications (don’t know why). So, sorry for delay.

Ok, about mdd. Maybe it’s a good idea to experiment. How about: you prepare and send us a some “mdd database”. Say, 5 mdd files WITH their corresponded FACT files (necessary, just mdd file makes no sense). If 4 of 5 files will work (we can check this), so, nothing to do, we’ll write a free MDD plug-in for EI . But if not - so, mdd is not a way to go.

Hmm… often an asking for help/participation is very effective to cold enthusiasm LOL

Sounds like a plan… does anyone out there have TAFA or POINT OVEN for LW where there could export out some .mdd data that could potentially be translated into the gNome format or for the Igors’ potential new plugin?

Igors.. what kind of standardized model would you like to work with? Secondly...would a .mdd plugin or a gNome translator work better?

Hi, Brian

Paralumino - 26 March 2007 12:01 PM

Sounds like a plan… does anyone out there have TAFA or POINT OVEN for LW where there could export out some .mdd data that could potentially be translated into the gNome format or for the Igors’ potential new plugin?

Igors.. what kind of standardized model would you like to work with? Secondly...would a .mdd plugin or a gNome translator work better?

As we wrote, need to have 2 components: a) mdd vertices b) polygon model. If both “a” and “b” are here and data are match, so mdd should work Ok.  At this point it can be converted into gNome, but for what if mdd already works? However, the prob is “this point” can never happen: import/export does not guarantee that model’s vertices follow in same order as they are saved in mdd file. So, there is idea to check this.

What kind of models? Well, not a sphere/cube, but also not a car with 2 millions of vertices Real models+mdd for real work. We guess if there is a request for mdd usage, so there are also mdd animation sequences you want to have in EI. Or no?

Hi, Igors
I´m trying to get something in the TAFA forums. Mac Reiter is very supportive, maybe he can help…
FelixCat

Hi, Igors
Mac Reiter from TAFA posted this to my questions
Hope can be useful:

...I started to mention that you could pull down the trial version, because it includes “Mr. Cool” from Timothy’s books as well as a sample MDD file from TAFA (because the trial won’t save files, but the tutorials show you how to use them in LW, so I supply a sample MDD).  Then it occurred to me that even though the trial is in a ZIP, the only file in there is the Setup EXE (which isn’t especially useful to you...)

So, I’ve taken the Content directory from the TAFA install (which includes all the resources necessary) and ZIPped just that up.  You can get Content.zip here: http://www.macreitercreations.com/Content.zip.

The MDD file you’ll want is Content/Tutorial/Puppeteer.mdd, and it works with the model Content/Objects/MrCool_Head.lwo (which uses a texture from Content/FacialAnimation/Images, but just for the eye—not critical for testing geometric displacements from MDD files).  If all works well, the result should be Mr. Cool performing “Welcome to Facial Animation!” (as heard in Content/Audio/WelcomeToFacialAnimation.wav)

If they’re interested in Morph Mixer files (may not be, since that’s a LW only file format), there are examples of v7 and v8 files in Content/Tutorial/Puppeteer_LW7.txt and Puppeteer_LW8.txt.  They’re pretty easy to read, although the changes from v7 to v8 seem to be pretty arbitrary and unnecessary—but I guess there was a reason that I’m just not privy to.

I’ve got documentation (sparse though it is) for the MDD file format around here somewhere.  I’ll try to remember to post it up tonight.  It’s fairly straightforward in the basics, but there are some details that are a little tricky.  I’ll also try to remember to extract some tips from my MDD generation code and forward those.

I don’t have an OBJ of Mr. Cool sitting around.  If LWO files won’t work, we may need somebody to do a conversion to OBJ.  We’ll also need to make sure that the vertices keep their ordering through that translation, or else the MDD file won’t work.  If you get an OBJ that is having that problem, I can regenerate the MDD using the OBJ so that the vertex ordering is correct.

Mac

PS - I spent last night working with Wine for porting.  Oddly enough, none of the Win32 stuff was giving me trouble.  What was killing me was that I have made heavy use of the STL part of the standard C++ libraries, and that breaks out of the “sandbox” of libraries and header files that Wine sets up—and that caused a compilation incompatibility.  That’s been resolved, and at least part of the code has compiled now, so hopefully within the week I’ll have some useful progress on a Linux port, which should be a large step towards a Mac OS X port.

PPS - By using this approach, I will require that the Mac be running the X11 server, because the Wine libraries output to X11 windows and use X Windows OpenGL utilities.  The Apple X11 server is present on the install discs (although it is sort of “hidden” because you have to scroll the window down to find it, even though there is plenty of space for it in the original window).  Would this be a problem?  As near as I can tell, you would not need to actually run the X11 server separately—Darwine seems to do that automatically—but you will need to have it installed.  I’ll also have to sort out some FreeType library issues so that the text doesn’t look unreadable

Hi, Felix

FelixCat - 27 March 2007 11:37 AM

Mac Reiter from TAFA posted this to my questions
Hope can be useful:

Sorry, Felix, but only one mdd file (as we see see from your post) is not enough to test and make any conclusion. Please collect as minimum 5 examples. Also we need FACT files (not lwo files), or better yet several FACTs for one mdd (created by differenr importers - maybe at least one of them will be Ok).

Ok… I just came from a Maya 8.5 product launch demostration and I’m now ready to say “Let’s FORGET MDD”.

Newly implemented into Maya 8.5 is Nucleus; a new dynamics engine that works on poly geometry. Within Nucleus are a number of cloth tools and various rigid and soft body tools that are truly quite incredible. But in addition to that, Maya 8.5 is now implementing a new feature...simply called animation caching.

In order to better integrate deformation animation compatibility between Max, Maya and Motion Builder, Autodesk is now using an XML animation cache to record vertex positions on any piece of geometry. Here’s how it worked in the demo:

A poly mesh was rigged with a IK skeleton. The skeleton was animated and due to the complexity of the rig and the density of the mesh, playback speeds were approximately 20 fps. Not too bad. But, by implementing the animation cache, Maya recorded the vertex positions of all the vertices in the model into an XML file and then the skeleton was deleted. Once complete, the cache file is then accessed for that model and playback speeds increased from 20fps to 40fps. Now here’s the really interesting thing. Maya now offers a vertex/cache blender...much akin to the Blendshapes capability originally found within Maya. Therefore, two or more animation caches can be blended together and keyframed from one to the next to next. Additional weighting tools can be used to reclaim portions of one cache over another. These tools are implentations I saw at ILM during the earlier Maya days.

Now.. lets go back to Nucleus. Here dynamic soft body solutions can be recorded and cached into an XML file and shared between any program in the Autodesk family. Options exist for vertex data being stored in a single large XML file or multiple XMLs for each frame of animation.

With the advent of this technology, I can only state that EIAS should be made to either read these XML cache files directly or to provide a XML to gNome converter. From what I also understand, XML is far more extensive than MDD and more information should be able to be stored.

For the Igors, XML should be a better choice than MDD because its going to be native to Max as well. This will expand EIAS’ compatibilty dramatically.

Paralumino - 27 March 2007 11:12 PM

For the Igors, XML should be a better choice than MDD because its going to be native to Max as well. This will expand EIAS’ compatibilty dramatically.

For the Brian:

a) it’s not clear how it’s “actual” for EI users. Are all use maya? 8.5? With nuclear? In other words, is there a serious, solid “subject/database to convert”, or it can be only a “toy” for 2-3 enthusiasts?

b) it’s not clear is a content of XML files documented and opened. Otherwise we’ve nothing to do. Also it’s not clear what’s saved in these XML files. If vertices only, so there are all same probs as for mdd file.

Summary: the idea is interested, and, maybe, we could help with technical implementation. But with documentation (if XML) and in any case with minimal database of animations and models to test.

Hello Igors,

Your response was anticipated. Let me see how I can answer your questions.

a) Why is XML relevant to EIAS users? Simple. Right now we’re attempting to build new bridges to EIAS to allow better forms of character based animation and compatibility between programs so non-EIAS users can consider EIAS as a means to render their animations in. One of the reasons EIAS is not being considered in production any more is the apparent lack of character based animation tools within EI. EITG has two choices here. Either implent better CA tools within EIAS (which we should still do) or find better ways to access outside animation packages to construct CA in and allow rendering to occur within EIAS (its strong point). EITG has taken the first step by implimenting FBX import. This technology allows all manners of data transfer between packages but it is designed, mainly, to transfer joint position and rotation data so the need for IK technology is minimized. I fully support FBX in EI and would like to see continued enhancements and FBX export out of EI. Weight map transfers should also be improved. However, even with FBX, we’ve seen data exchange experience problems and it would be nice to possess an even more simplified methodology of transferring animation between software packages. Enter vertex level animation.

Everyone knows Autodesk is the industry giant in 3D. Either we learn to play with them or we get crushed. With that in mind...XML compatibility provides all EIAS users a method to exchange deformation animation between software packages supporting this animation cache technology. Which packages will those be? Maya, Max & Motionbuilder. Unquestionably the biggest CA influences currently on the market. If EIAS had this technology we could share data with over 80-90% of most production houses. But in addition to sharing data between EIAS and other software pacakges, vertex level animation is a boon just for EIAS users themselves. 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.

Hi, Brian

Paralumino - 28 March 2007 07:55 AM

Your response was anticipated. Let me see how I can answer your questions.

Your answer is good but it’s absolute NOT concrete (btw: it was also anticipated ).

We hope we understand an importance of vertex-level import/export at least cause 2 our works required it during last year. However, let’s not confuse “real work” with “abstract considerations” no matter how right they are. It can be good/cool overview but far away from real prjs EI user is busy with. Same about “XML is opened” - if so, where is a doc/SDK?
If we (Igors) would take care about all aspects: searching for XML doc, collecting animation examples, numerous testing etc. so.. hey, it’s not a work for 2-3 days, it’s just a commercial prj. And that is not in our plans cause we are really busy and IMO such prj is too risky.
Other (freeware) ways? Why no? But in this case we hope for your help/participation with what we wrote: doc, examples and testing.  And if we see common words only - sorry, but no vertex level import from us

Agreed and understood. I’ll do my best to get you what you need. I’ll begin with excerpts from the Maya manual and I’ll talk with Marcel about the format. I have a copy of Maya 8.5 at my office, so getting you samples shouldn’t be a problem.

Hi, Igors
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:

the following is pseudo code meant to illustrate generally what TAFA does when writing out an MDD file.  As such, I hope it will be useful to the developers for reading files.

// First, a couple of utility routines:
// Note that WriteFourBytes just writes out the bytes it is handed.
// The caller is responsible for getting the byte ordering correct.
// MDDs use Big Endian (network canonical) ordering, so you
// can use ntohl and htonl to be platform independent (as shown
// in the pseudo code below)
inline void WriteFourBytes(FILE * File, unsigned long Input)
{
fwrite(&Input;, 1, 4, File)
}
// FlipFloat _does_ do any necessary flipping, because
// the casting is a bit ugly…
inline unsigned long FlipFloat(float Input)
{
return htonl(*((unsigned long *)(&Input;)))
}

void CreateMotionDesignerFile()
{
unsigned long Frame
unsigned long VertexIndex
V3D_POSITION RealPosition

// In Lightwave, MDD files are attached to layers of the object.
// For each layer in the object, I output a separate MDD file.
// For non-LW objects, I don’t have layers (currently), so there’s
// only one file.
// How MDD files would be used in EiAS (for example) is up to the
// developer of the plugin.
// For a single file, I name it whatever the user told me to name it—“MyAnimation.mdd”
// For multiple layers, each file is named MyAnimation-N-LayerName.mdd, where N is a number
// that is used in certain pathological cases if the layers don’t have unique names…

// The following logic is done for each output file, but is easier to think about it one
// file at a time.

// Output file “headers”—the beginning data—but not the framewise data.

// Fmax (number of frames, not including the first “base” frame.)
// It looks like MDDs assume that the first frame occurs at time 0.00000.
// This also means that they don’t consider the first frame in Fmax…
// Note the use of htonl, to make the disk representation be in network
// canonical form (which happens to be Big Endian, but htonl and ntohl
// are your friends)
WriteFourBytes(htonl(NumFrames-1))

// Pmax (number of vertices in the model—well, technically in the layer,
// but hopefully you only have one layer in the model)
// Keep in mind that if you are using subdivision surfaces, MDD files only
// talk about the control cage vertices.  Everything else is calculated
// by the renderer per frame.
WriteFourBytes(htonl(NumVertices))

// Times
// It looks like MDDs assume that the first frame occurs at time 0.00000.
// TAFA makes the same assumption, so the first recorded timestamp is for
// frame==1 (which is actually the second frame—0 based indices)
// Note that, because each frame has its own timestamp, these are keyframes
// and the rendering/animation system may need to interpolate.  The
// interpolation is not defined in the MDD documentation I have.  TAFA MDD
// files output frames at the full framerate, so interpolation is not
// critical, and linear should be fine.
for (long f=1 f<NumFrames ++f)
{
// Times[f] is the time (in seconds) for frame index f.
// Use FlipFloat to make sure it’s in Big Endian format.
WriteFourBytes(FlipFloat(Times[f]))
}

// The documentation I have for MDDs states that after the times, you output
// the reference position for all of the vertices, and then you output all of
// the animation frames.
// But it looks like MDDs assume that the first frame occurs at time 0.00000.
// That also means that the “original positions” is just what we’re considering
// the first frame.  So don’t record an “original position”, just output all frames
// STARTING at f==0, this time.  (the output is done below)


// Framewise positions
for (long f=0 f<NumFrames ++f)
{
for (long v = 0 v<NumVertices ++v)
{
// Lightwave’s X coords are flipped from ours…
// Take this as you will for other animation applications…
WriteFourBytes(FlipFloat(-Pos[f][v].GetX()))
WriteFourBytes(FlipFloat(Pos[f][v].GetY()))
WriteFourBytes(FlipFloat(Pos[f][v].GetZ()))
}
}
}

Odd… the text lost all the spaces, but in edit mode it looks ok.
Well, the original text is here: http://www.macreitercreations.com/community/?num=1174936527/0#4

FelixCat

Felixcat,

Well.. I wont say to completely abandon MDD… perhaps one format will work better than the other concerning EI. We’ll see how it goes. Either way, we need this kind of technology.