Hello Brad..

Love the Maya2EIAS pipeline sample by Johnathan Banta in the product literature. I completely overlooked that section until now. Very cool. The more of this I see, the happier I get.

I hope to continue to show all the benefits of EIAS today and the EIAS of tomorrow!

I missed it too..where is it? Link please. Thanks.

http://eitechnologygroup.com/products/electric_image_animation_system

Half way down the page.

I’m really interested by this comment/ news:
“As a official Autodesk Developer Partner, EITG has committed to working with Autodesk in making EIAS friendly to our Maya brethren.”

Ian

Yes, very interesting indeed.

There should be the same commit to ZBrush. And, I do mean Zbrush over Mudbox. Reason being MudBox is not supported on Mac. Does that matter with MacPro?  ...for me it does. To stop several operations on the Mac for one PC process is bothersome.

I don’t care how you slice it, Zbrush is next gen modeling. Though Zbrush’s advance and uniquely different interface goes across the grain of conventional thinking, it’s evident in Hollywood films like Pirates, the rest of the world just need catch up to it if they want to compete, in particular EI. Take in consideration all the other apps whose renderers may not be as sweet as EI’s but are inclusive to the line up of fully functional ZB render output. They win by default, while EI is benched.

So stuidios probably using Maya, will probably use ZBrush and probably by pass EI if it’s still stuck in the mud thinking ZB is esoteric or arcane.  You don’t have to be the sharpest pencil in the box to see this technology was one of the main effects tools for the last Oscar award winner (ILM). EI need 50% gray point and 32 bit (?) subpixels to compete with the other apps as renders.

I said that to say this, It’s an opportinuty for EI to go one step beyond in ZBrush support. I would love to see a renderer that could simply import a Ztool and skip mapping and have on the fly SudDivs. Ok. that’s too much to ask, but I got can dream

I have one more thing to say about Maya intergration before I get back to business. (been posting a lot)

I would like to see a full character pipeline solution for importing and rendering Maya file in EIAS. 
I will skip FBIK import, to focus on import Vertice/Blendshape animation. (maybe hair?)

Any simulation is usually baked to delete recomputing, especially cloth. Even character animation like walkcycles and performances are baked because bone deformations which are compute instensive can slow a scene, especially when calculating a cloth sim.  I don’t know if vertex animation can be exported directly from Maya in one file with point interpolation but EI needs ways to directly import vertice animation from Maya without hsssle. My method, though accurate is like many of my non-programmer, home-baked solution. It’s a hodge-podge of slipping through undocumented loopholes as oppose to a solid production pipeline. 
Maybe I will sell it in a VLog for Radical user, but it’s not something I reccomend for the mild mannered.

EI should be the QuarkXpress or InDesign of 3D renders, where data assets are gathered and compiled. Using it for it’s strength...milions and millions of polys. It’s a fantastic intergrating assets from several different people in several cities into one EI file for renderama.  Doing so can make collaborating with clients and content creators that only use 3D character work occasionally for support a joy.

Ok back to modeling, the end product is going to be rendered in EI in another city. They wants true HDRI.

Don’t forget opportunities in the CAD world. This is a HUGE untapped market. Most of these guys think Mental Ray or Maxwell is “where it’s at”. EIAS would be very competitive in price, performance, and quality in this arena.

Some sort of advanced pipeline “plugin” for formZ, and Autocad would have it’s place in Architecture,
and another “plugin” for Solidworks for Industrial Design/ Engineering.

(Of course there are others too like Concepts Unlimited)

So when can we expect some details about the two new upcoming products?

Hello, gentlemen

We heard many times sentences like “EI2Maya” etc. etc. But we’ve no idea WHAT is it technically/concrete. A “dream” is enough clear: “I work in Maya in my usual way and I use all cool maya features. Then I press “a big pink magic button” to activate EI render(er) and.. voila.. it renders with speed and quality of EI”.  Right? Or we are wrong?

If so, let us ask you: are you really so naive? With/by your logic EI render should “understand” almost everything what’s going inside maya and does react/response adequately. Hmm.. how? Not say about huge difficulties sorta “how to hybrid a hyppo with rhino”, but is anything fully documented (in maya or any other app) to be a subject to implement by “third party” renderers?  Yes, there are Mental Ray and others, but they are supported from hosts (that wants to have MR render) .

So, what your dream is?

Hello Igors,

I believe that most of the “experienced” users out there realize that there is no “big pink magic button” out there that will provide instant and complete Maya compatibilty. However, plenty of strides can be made to make working with Maya (and other programs for that matter) more enjoyable and reliable.

Typically, within in the VFX, Film and animation industries, inter-platform compatibility and data transfer is critical to use and implementation of different software packages. Without it, “closed” software packages rapidly become isolated and obsolete. One of the chief complaints of EIAS within ILM was the difficulty encountered getting data out of EIAS and into their pipeline. Studios like ILM, Sony, and so forth then purchase more “open” programs that allow them to get access to certain pieces of data without a lot of hassle. Maya’s MEL is an example of being more “open”. By using MEL, Maya users can tap into the program in ways that are impossible in EI without EITG’s help. However Maya has been designed to be an open / nodal software package from the beginning while EIAS was not. So what can we do?

EITG has been attempting to solve this problem by providing methods of exporting and importing data within EIAS with less difficulty. For example, EIAS can export Maya cameras. This is a good thing, but its not enough. Xpressionist was another step forward, but again, this is more of an expression editor than an embedded language like MEL. For v6.5 we got FBX import. Another great bridge but so far reliability seems dependant on a number of factors that confuse the user.

So when we talk about a Maya2EI / EI2Maya pipeline, we’re looking for additional methods to allow the exchange of data between the two programs more efficiently. So what exactly do we need?

1. Reliable static geometry exchange. This is currently being handled by Obj2Fact, Transporter, and FBX import. The difficulty here is the user seems to need all three and a little bit of voodoo to get solid exchange without dropping polygons, screwing up the winding order, or loosing information. UV texture map transfer can also be an issue.

2. Reliable FBX implementation. In addition to FBX import, EI needs FBX export. This protocol is a method to help exhange positional and rotational data for: Joints, Lights, Cameras and nulls in addition to polygonal geometry. While some users are having some success with FBX import, most are not. This isn’t really Blairs’ fault. The FBX libraries update constantly and each program does its share of translations which can really cause headaches within EI. However, by including FBX export, we can prepare a character rig within EI, along with EI generated weight maps, and bring the results into Motionbuilder for animation and then back into EI for rendering. Right now we’re dependant on creating a skeleton in some other package which results in users going through 2 levels of translation for results.  The issue we’re seeing is unusable weight maps and problems that make FBX less fun to use.

3. Transfer of vertex positional data. While FBX attempts to address animation based on positional and rotational data of joints and geometry, no method exists within EI to bring vertex level animation into the program from other packages. Deforming meshes from Maya from blendshapes or deformation animation from programs like TAFA or .mdd files from Point Oven are not supported. Paralumino’s gNome file format could address this issue if its made to be comptible with existing vertex exchange formats somehow. Either that or we provide gNome exporters for other software packages.

4. Direct export/import support. Now we realize its ridiculous to expect EI to read a Maya project files and vice versa..however, as mentioned earlier, EI can write out .mb files for camera animation. It would be nice to see this capability expanded to allow EI to export out animation curves for any object, light, camera or null within the scene. Hierarchy support would be even better.  Maya possesses this capability already with its .anim export/import function. This tool exports an object’s animation curves out to a file. EI should be able to read these files and apply those animation curves to any object within the EI scene. Obviously differences between coordinate systems and scale factors should be addressed.

5. Better texture/shader transfers. We’re all aware of the UV coordinates issues within EI. The procress of bringing in models with UV textures is getting better but without an internal editor to EIAS..we’re still not there. Custom shaders within Maya and EI can’t be exchanged and this is on of the reasons to justify texture baking. If someone is using a custom shader within EI and wants to bring the look of those shaders into Maya, a way to bake out the shader into a texture map that can be applied within Maya via UVs could be helpful. Maya already possesses texture baking capabiltiies and a method to ensure the transfer of those baked textures into EI could be useful.

More ideas anybody?

Hi, Brian

After reading your long article it seems like all is going as it should, EI makes steps in right direction, need only more and bigger steps. We don’t think all is so simple though. Let’s consider a little but concrete example: MDD files.

A normal programmer needs 2-3 days to implement them in EI. But, as we discussed, mdd file contains only vertices. So EI user should have an imported model too and rely on exact corresponding “vertex to vertex” (in model and mdd).  AFAIK importers do not guarantee that. And eventual result of “mdd in EI” will be not a happy user but a series of confusions like “Why it does not work for me??”. And what to answer? Simply cause it’s how mdd works? So, why need to repeat and repeat “we need mdd” ?

And a few words about “glory to MEL” that sounds loud in begin of your letter. There are things that go nice, perfectly etc., but.. “only with a little help of friends”. Yes, in a big studio with guy(s) who are familiar with MEL - it’s going really nice. But artists-individuals are not always enthusiastic to learn a big scripting language. Scripting is a kind of programming too, thus it’s not suitable for anyone. So, the glory should be addressed to scripters, not to script itself.

First I want to say, that I made a mistake in one of my post. EI’s does have a scale constraint. I have been using EI for some time and sometimes I overlook what there. Also, No one has taught me rigging in EI. I just break stuff and see if I can fix it. Now, I’m learning formal rigging in Maya. My hope is to bring this experience to EI. Hopefully Scale constraint will prove useful.

Paralumino - 13 March 2007 04:57 PM

Maya’s MEL is an example of being more “open”. By using MEL, Maya users can tap into the program in ways that are impossible in EI without EITG’s help.

For years I naively couldn’t figure out why EI wasn’t popular VFX studios, even more so frowned upon. The answer became obvious when I saw the last “Pirates of the Carribean” movie, why EIAS wasn’t a big studio contender as well as why only an Open/nodal system could be.

All the plugins in EIAS are locked off in their separate little world. The interface and plugin are lacking interoperability. Several editor in Maya allows a technician to seamlessly rewire one component of a feature to enhance another. With Hypergraph One person can look at a map of a whole production.  With Mel and connection editors that operator can interwine and control functions that don’t normally mix to achieve a unique effect. The reason why this is important in a movies which has so many diverse effects like Pirates, is to flexibly rewire the interface and funtions to accommodate many dynamic tasks. It’s one overdriving way of controlling many assets with one controller or language.MEL, Liken this to cultures which speaks their different languages but have one common or dominant market language to do trade. Hypergraph is like a super highway between all the countries or like cityblocks (nodes) connected via a mass subway.  So that one technician can go into every town quickly underground like a subway below the surface of the interface. It’s quick like skipping all the stoplights or threading through tabs or dialog boxes. An interface with nodal features are like houses except you can go in every room or every part of the feature, say a feature like IK. Unlike EI, an IK Handle is simply an IK handle and bone is a bone. It’s a house with a closed door. In Maya you can go into every component or room of the (IK) house, take out the furniture and put it in another house that has a photo shoot that day, say for Better Homes or your ground breaking effect of that day

Well that’s my take on it.

Anyway, AfterEffects has this flowchart though it’s not reconfigurable (I don’t use AE much), and Shake is nodal and can be reflowed. Many would like this feeding one component into another for shaders in EI.  EI has no way of looking at a production as a whole or reorganizing it’s asset for a particular job. Dante can’t directly see or communicate with Rodeo. It’s a closed and compartmental.

I believe PYThon is an open source scripting being incorporated along with MEL (?) Maybe EI should consider using the script standard as well? It will standardize EI. (?) XP is a great start at digging deep into the EI workings, and I believe it can call out objects, nulls etc.  At least it should have an Set Driven Keys interface as a quick animation tool.

Igors - 14 March 2007 04:10 AM

Hi, Brian

After reading your long article it seems like all is going as it should, EI makes steps in right direction, need only more and bigger steps. We don’t think all is so simple though. Let’s consider a little but concrete example: MDD files.

A normal programmer needs 2-3 days to implement them in EI. But, as we discussed, mdd file contains only vertices. So EI user should have an imported model too and rely on exact corresponding “vertex to vertex” (in model and mdd).  AFAIK importers do not guarantee that. And eventual result of “mdd in EI” will be not a happy user but a series of confusions like “Why it does not work for me??”. And what to answer? Simply cause it’s how mdd works? So, why need to repeat and repeat “we need mdd” ?

Is this gNome available online? Is it out?

Igors - 14 March 2007 04:10 AM

And a few words about “glory to MEL” that sounds loud in begin of your letter. There are things that go nice, perfectly etc., but.. “only with a little help of friends”. Yes, in a big studio with guy(s) who are familiar with MEL - it’s going really nice. But artists-individuals are not always enthusiastic to learn a big scripting language. Scripting is a kind of programming too, thus it’s not suitable for anyone. So, the glory should be addressed to scripters, not to script itself.

I agree Igors. So this is why XP should be extended to have a Set-Driven Key interface. Then artist, don’t have to script. It’s faster, more inuitive and very powerful.

Igors,

I’m ok with EI not being Maya. I don’t think its necessary to turn EI in to Maya. If that were true, I’d only use Maya in the first place. I like EI for being EI, I just want to see it continue to improve. The tasks you programmers have to accomplish is monumental so I hope you don’t think I’m trying to make your lives difficult.

As far as “Glory to MEL” goes....You’re right that the average user may not take advantage of a MEL like system within EI the way it should be taken advantage of, however, I’m also trying to look at the big picture. I’d like to see a way that expands EI’s connectivity and capabilities in order to see larger VFX and animation companies start choosing EIAS again. Now this level of expansion may not be possible with EIAS’ current infrastructure and if that’s the case, so be it. It might take a whole new application to go down that road. But if the exchange of data between packages continues to get smoother and smoother, more and more advanced artists may start working with EIAS again which results in more sophisticated tools and works of art. This ultimately becomes a boon for EI’s marketing department and more seats of EIAS are sold.

Alonzo,

gNome is currently being implimented in Paralumino’s ClothSim plugin.

Igors,

Ok. Let me rephrase my statement. We don’t need .mdd files, what we need is a method to exchange deformation animation between software pacakges. If you feel .mdd isn’t appropriate for EIAS, then continued advancements of gNome could potentially solve the problem provided we then solve the export issue from other software packages. That would mean you (or others) would have to write gNome exporters for Maya, Max, LW, and so forth. The only reason .mdd is constantly being brought back up is because of the existing number of programs that implement that technology. I agree with you that its limitations doesn’t make it appealing. But it is being used effectively in other applications.  Having our own proprietary format is useless if it doesn’t work with other software packages.

Igors,

Another option would be to provide a .mdd to gNome converter. If .mdd only contains vertex information, could that data be grafted into a gNome file and replace its vertex information?

I’m still very interested in this comment/ news:
“As a official Autodesk Developer Partner, EITG has committed to working with Autodesk in making EIAS friendly to our Maya brethren.”

Very promissing direction for EiAS, i can´t wait for better communication between apps.

FelixCat