RE: Reference model limitations?

["Andre DeAngelis" <andre.deangelis(at)ubisoft.com>]

Jeff,

 

I have no disagreement with any of your arguments, other than to add that in their current implementation, Reference models do indeed allow for the propagation of geometry, UV’s, enveloping and rigging changes without too much fuss.

 

AD

 

---

From: owner-xsi(at)Softimage.COM [mailto:owner-xsi(at)Softimage.COM] On Behalf Of Jeffrey Dates
Sent: July 26, 2007 4:34 PM
To: XSI(at)Softimage.COM
Subject: Re: Reference model limitations?

 

It’s like saying that a rendering pipeline is only valid if it can achieve the desired result in a single pass.  Think about it gentlemen, what good is a ref model when you need to need to take stuff into Maya?

This is a valid point.  However to dismiss the work-flow entirely isn't the answer either.  Of course Ref models are only XSI specific, and would not be appropriate in every case.  I think the functionality is to allow for a non-linear workflow.   Having an animator animate while the modeler models and being able to propagate changes throughout production is what I'm after in a Referencing workflow.

Reference models themselves represent only one type of referenced data/asset,
and being a complex chunk of data, are more prone to corruption than more granular components such as UV data, envelope data, etc. 

This is a generality that I don't agree with.  The data isn't prone to corruption just because it's Referenced.  ( not any more than any other data I should say )

There reason point caching and ASCII/XML have become popular is because they not only provides a simple interchange format between 3D apps, but because they provide great flexibility when sharing data between animation, FX and lighting.  Why send a fully rigged character with constraints/SCOPS etc to lighting, when they have no need for all that junk?  All you are doing is introducing inefficiencies into the most critical part of your pipeline, which is lighting.

I don't think anyone is arguing the value of Point Caching. ( See Subject line: )
All your points are valid, but still doesn't address the Limitations of the Referencing workflow.

To be able to propagate changes throughout an entire production easily, is where I find the value of Referencing.  Especially DURING the production, as your animator is animating, your modeler is modeling, and your UV/Texture/shading artist is doing their thing in tandem.

 

Animators don’t generally care bout Syflex operators and particle emitters, so why should they be forced to deal with them?   Texturing artists don’t care about rigs so why should they be forced them to deal with them?  All they want is a powerful and efficient rig to get the job done with a minimum of fuss.  Brad Gabe could probably explain this further, but he has mentioned the trend towards converting assets towards smaller, easily reproducible components.   After all, if you are going to reply on ref models as a crutch, you’d better pay that you don’t have a mixed pipeline for modelling and FX (which is usually the case).  What do you say to those poor studios who use Maya, Houdini or in our case XSI/Maya/Max?

Again, valid points.   I think situations are different at different studios.  I find myself primarily in a commercial environment working alongside  software-agnostic Generalists.  So the idea of 'forcing' artists to deal with anything is a funny notion to me.   I also find it funny that you would imply that Reference models are a 'crutch'.  ??   It's a tool, like many of the others.. why would a tool be a crutch?  ( unless a crutch was the tool! )

Now I would love to have all my data broken down into smaller components that can be worked on simultaneously, yet be able to be assembled easily in a shot basis. ( something how Toxik works but applied to a 3D software )

And on your comment about mixed software's.  I use Maya, as well during production, and have no problem mixing softwares.  I don't understand your point?

 

Why send an entirely rigged character to lighting when all they really need is the point cache file?  Is not a point cache file just as valid and powerful as a referenced piece of data as an entire reference model?

Again ( see subject ).  
But yes point cache is great!  But a couple of questions about non-linear workflow with them.

If build a rig and proxy geo, and hand it off to the animator to start blocking in motion, before the model is complete.  Is There is no easy way to propagate modeling changes across many animated scenes without re-caching, and re-importing for each??

Texture/shading changes are occurring on a model during this time, that has already been animated in a number of scenes, how does point caching prevent me from having to re-import and re-assign all the cache files to each scene?

Now please understand, I value Point caching as well.. and find it extremely useful!  It just doesn't answer all my workflow issues either.
( I should use Point caching as a crutch? )

 

I am the first to admit that there is work still to be done on Deltas and making Ref Models more robust, but it pays to use them wisely.  Reference models are certainly valuable, but even if they were bullet proof, they are not the be all and end all of pipelines.

I agree most with this sentiment Andre.  I sure didn't mean to suggest they were.  :-)  In fact, everyone works differently depending on needs of the artist, studio, and project.   But I feel, as you do, that there simply is more work to be done on Deltas.

Ideally in my little world, data is granular, and lives on a database.  The data is independent of one another ( where appropriate ) but can be assembled and associated with each other at the shot level.
This allows things to be ripped out, and replaced with minimal effect to the production.  This allows significant changes to geometry, textures, shaders, animation, FX or a number things, to be propagated across an entire show instantly.  Without the overhead of re-importing, re-caching, managing which shots this has happened to..etc.  I have a dream.



:-)

--
Jeffrey Dates
www.kungfukoi.com
214.280.4353