Messiah for EIAS

#5 
Well, the MDD file format was indeed originally developed by LW, so that's why it is probably not known by users of other apps (except if they use PointOven). You can use it freely (at least NewTek has never objected to someone writing plug-ins for reading/writing that format), so there is no need to "reinvent the wheel". It is a very straightformat format which uses 12 byte (the local x/y/z corrdinates of a vertex) per vertex  and frame (+ some additional data). In the PointOven docs (see the links that Vizfizz gave) the format is explained in more detail.

When using SDS objects, you would only need the animation data of the SDS cage, so a typical MDD file of an animated character might eat up several MB, but it still should be manageable.

Writing a plug-in for MDD files is considerably easier than writing a direct host-connection (as Kurt suggested), since with a host connection you have to care about synchronization of the two apps etc., which usually leads to many headaches.

PointOven is $99 at the moment, but in LW, messiah and Softimage XSI there are now free MDD importer/exporters. For C4D, there is my very own MDD Reader/Writer plug-in, which is also free. I think that EIAS would greatly improve its connectivity with an MDD plug-in.

Against 1. d4, I usually play 1...Nf6, followed by some solid openings, either the Queen's Indian or the Nimzo-Indian. :)
#6

Hi, Brian, Christopher

We know this link, but we’ve some doubts. We imagine the following “scenario” would be attractive/usable:

  • run app, select “save/write” mode in plug-in, run preview/animation. The file is ready

  • run another one app, select “load/read” mode and assign previously saved file. The plug-in generates animated model at each frame.

Unfortunately, we see no way to implement this with MDD, cause, as we understood, only vertices positions are stored. User should have a corresponded model (polygons, UVs, vertex color etc. etc) and be sure that MDD content is in tact with all existed info. Note also that “vertices from other apps” aren’t Ok for EI (there is no corresponding with facets refer to them). For example: cube in max (lw) has 8 vertices but 24 in EI.

#7

I see what you mean … Usually working with MDD files implies that in both apps (the one where you record the animation and the other where you replay it) you have a model with the same number of vertices and the same index order of these vertices. So there is no way in EIAS to merge vertices ? That would be indeed a stumbling block for a MDD plug-in …:sad:

#8

Hi, Christopher

We think an assumption about exactly same topology is too brave and generates numerous mismatches/problems.

A lot of plug-ins merge vertices to make geometry manipulations and then unshares them back to output results. However, there is no any guarantee that merged topology is exactly what other app expects.

In our opinion MDD looks limited/narrow a bit, so not too much is lost :slight_smile:

#9

Interesting.

As usual, there is more than one way for applications to share information. With all these good ideas being bounced around, many good things should develop.

Of course I’m hoping that EITG really wows us with updated Character Animation tools. That would reduce the need for a seperate package. Still, sharing data sets would be handy for fluid and cloth simulations.

#10

Hey,

Since we are importing FBX, wich handles vertices pretty well, Blair could share with Igors the FBX information and add some functions of Motion Builder in a Plug-in.
I think its not soo complex to have a automatic Rig creator based in a Motion Builder Character seteup… improving out CA tools.
and… this is basic step to export fbx characteres from EIAS to other applications…
Why we need a new wheel, if we have the tires?

Thanksss

Tomas Egger

#11

Hi, Tomas

Really? We created in 3ds max vertices animation via EditMesh and FBX exporter said like “such animation will not be saved”. Looks same for anything that manipulates at vertices level

#12

FBX can output postional and rotational information from objects, lights, joints and cameras, but it does not export individual vertex / point positions. The deformation of geometry occurs from the skeleton & weighting system found in the host package. Since FBX provides the necessary joint position and rotational information, the skeleton moves and the geometry deforms.

Any skeleton brought into MB is “characterized” to allow MB’s rig to “drive” the imported skeleton from the host package. The last time I checked, I did not find any method to export out geometry vertex level data from MB. Did that change in v7?

#13

Hey Igors and Brian…

Blair msg me this:
“Well, I’m extracting vertex data in the EI importer so it’s there. Higher-level data like weights are a royal pain in the XXX to work with.”

So, I think, if you dig… you can find more in FBX.

Thanksss

Tomas

#14

Why we need another format?

Tomas

#15

Aren’t we confusing vertices, effectively models, with vertex animation?

#16

I would like to have same good character animation software for use with EiAS. The tools inside the app are not very powerful and limited, and doing some lipsink is a real pain in the **s. To test the sincro of the audio and the morph targets is very innefficient and so on; i know that EiAS was not originally conceived as an character animation app, but times changes and users too. I don´t know if Messiah is the solution, or another packagge…
Right now i´m doing an animation of a naked girl (my wip) and it´s really hard to have her talking.
Maybe we are waiting too much from EiAS…

FelixCat

#17

…BTW, in the Messiah web site, they say:
¨While we have included connections to Maya, 3DS max, Cinema 4D, & LightWave in the base package, it is not very practical for us to develop and maintain connections to all popular apps and the different versions of those apps. However, we do have an animationHost API that allows anyone to connect messiah to virtually any app that has a capable plug-in API.¨
Do EiAS has a capable plug-in API?
They say nothing about porting Messiah to the MAC… :frowning:
Oh, dear!

FelixCat

#18

The particular product we are proposing is a plugin designed to work in both Electric Image and alternative 3D applications. The goal is to exchange vertex level animation and positions back and forth between the two programs. The vertices are “baked” into an external file that records every vertex position for an object for every frame of the animation. This baked information does not include any information outside of the vertex positions themselves. No joints, no rig, no lights, no camera.

If you wanted to create a facial animation in a program like Max, our plugin would write out the vertex positions for that face into a file that EIAS would read on a frame by frame basis. The result within EI would be animating, deforming geometry but without any skeletons, joints, or deformers. By perserving UV data, the geometry would be retextured with EI and rendering could resume.

The whole point for this particular format is to provide EI the ability to read geometry that has been modified and deformed or simulated by another package, strip away all the uncessary rigs, weighting solutions, FK, IK, nonlinear deformers or whatever and provide pure vertex location data. This approach is used all the time in the VFX studios to exchange deformation animation between packages in a simple, consise way.

Now… unless something changed in MB/FBX in v7, I do not believe FBX accomplishes this. Geometry is “translated” from one package to another, yes, but vertex level animation is not passed. What is passed is the joints, geometry, FK rotational data, lights, cameras, etc… FBX depends on the weighting solutions within the hosts packages to maintain proper enveloping.

If I’m wrong. Please correct me. I haven’t used MB since v6.

#19

Brian is absolutely correct. We’re just talking about the vertices of the object itself but Camera data, etc… can be translated as well depending on the apps. I think .mdd is the way to go since it doesn’t require licensing and XSI saw that Point Oven was important enough to be incorporated into their app.

Just to point out another third party plugin to do facial animation using .mdd as it’s translation vehicle. I’m not promoting this program but it goes to show what has been done and can be done using the .mdd format. :slight_smile:

#20

So, we’re suggesting a workflow of animating in Messiah (or other app), possibly doing cloth and/or fluid simulations, then exporting as .mdd files?

Then we only need a small application that can batch convert .mdd to the .fact format and in EIAS use “Group Cycling” to run those data sets.

Light, Texture, and Render with the Power of ElectricImage and use those other apps for what they’re best at.

#21

Hi, Kurt

No, unfortunately it’s not so simple. Mdd file contains vertices only thus no any FACT can be created from it.

#22

So it’s more like a list of morph-targets?

#23

Yes, Manuel, it’s more. See discussion with Christopher in this thread.

#24

Hi, Brian
Whatever it is, if is a plugin designed to work in both Electric Image and alternative 3D applications for exchange vertex level animation and positions back and forth between the two programs… i am IN.
I´m doing some character animation and thinking seriously in switching to a more friendly app. After seeing the Facial Animation plug posted by Chikega i felt depressed, they made in minutes that it take hours to me!.
The next question is if it exists, somewhere, some good face animation app FOR MAC for use with this hipotetical (and badly needed) plugin. If those two points concurr i´m willing to pay for both right now.
Hold my breath?

FelixCat
(Sorry for my english, hope can be understood)