RE: Nested Referenced Models

Date : Thu, 10 May 2007 20:09:07 +0100
To : <XSI(at)Softimage.COM>
From : "Adam Seeley" <adam.seeley(at)clearpost.co.uk>
Subject : RE: Nested Referenced Models
Ah well, I'll keep it simple then, best laid plans and all.
 
I'd tried to use Instancing within the Nested Ref Model system as well for repeated items, not surprising it lost track of those as well then.
 
Thanks for the heads up.
 
Adam.
 


From: owner-xsi(at)Softimage.COM [mailto:owner-xsi(at)Softimage.COM] On Behalf Of Matt Morris
Sent: 10 May 2007 18:47
To: XSI(at)Softimage.COM
Subject: Re: Nested Referenced Models

Whenever I've used nested referenced models in 5.11 I've had any number of problems - not least losing animation randomly. Avoid like the plague!

If its non-moving parts then maybe nulls that are parents of the nested ref model and that zero out the model, so you can replace it easily, would provide some security.


On 10/05/07, Andy Jones <andy(at)thefront.com> wrote:
Yeah, I think sub-component models for rigging are a good idea, but
having it all work with referencing is a little too non-linear for my
taste.  Usually if you're making rig changes, you want to do it all at
once, when you've decided it's a good idea to do so.  So, perhaps a
better solution for your rigging strategy would be to have scripts that
bring your rigged models in based on "guides."  Then, you'd rebuild your
rig from the guides when there are changes to the subcomponents.  If
this doesn't work because you need to make customizations on top of the
generated rig (for special deformers and stuff), one thing you can do is
set up a more flat heirarchy that links back to the rig via
constraints.  Then, do all your additional deformation and enveloping
onto the flat heirarchy.  I think this has been called "marionette style
rigging," and in my experience is usually best explained by people named
"Brad."  Another advantage of this style of rigging is that once you've
got your animation, you can bake the flat heirarchy animation and kill
the (presumably heavy) rig.

Oh, the other strategy we've used for dealing with nested references in
the past is "build scenes" where a bunch of reference models live in a
scene under a local model, and you can just open the scene and save out
the model again when there are changes to the sub-models.  I was hoping
the need for this workflow was going away with the new referencing
system, but I haven't really gotten to play with it enough to say one
way or another.  Could be a useful work-around, though.  It sort of lets
you do what I described above without scripts or the need for nested
reference models.  And maybe the nested references would actually work
okay for something like that?  Like, you might not have to be worrying
about some of the gotchas Kim is talking about (actions and such).

Historically, nested references were definitely a big no-no, but I think
everyone is hoping that will change somewhat with the new system.
Complexity-wise, I think it's still better to avoid it, though, if you
can.  I think the initial test cases should be stuff like putting
reference models for furniture in a reference model of a house or
something, where there isn't a lot of animation...  What you're
describing is sort of the most ambitious thing you could possibly do
with nested reference models...

- Andy

Kim Aldis wrote:

>I've had issues with nested reference models. For one thing, storing actions
>for the entire set doesn't store actions for the nested models. There are
>other things that escape me, enough that I'd probably avoid nesting, unless
>I had good cause. It'll come back and bite you for sure.
>
>
>
>>-----Original Message-----
>>From: owner-xsi(at)Softimage.COM [mailto: owner-xsi(at)Softimage.COM] On
>>Behalf Of Adam Seeley
>>Sent: 09 May 2007 22:26
>>To: XSI(at)Softimage.COM
>>Subject: RE: Nested Referenced Models
>>
>>
>>Sorry all, should have said, I'm sticking with 5.11 for the mo'
>>
>>A.
>>
>>
>>
>>>-----Original Message-----
>>>From: owner-xsi(at)Softimage.COM
>>>[mailto:owner-xsi(at)Softimage.COM] On Behalf Of Jeff
>>>Sent: 09 May 2007 21:59
>>>To: XSI(at)Softimage.COM
>>>Subject: Re: Nested Referenced Models
>>>
>>>There are some issues with the Delta Reference (I assume you
>>>are using 6.01). The models will fall out of the partitions
>>>if they are referenced, and you can't copy/paste animation,
>>>there are other issues as well.
>>>
>>>I would personally not use 6.01 until these things are fixed
>>>(they are working on them, but I don't know of any timetable
>>>for the patch). But once these things are fixed, the
>>>reference model system should be fantastic.
>>>
>>>Stick with 5.11 if you can, in my opinion.
>>>
>>>-Jeff
>>>
>>>
>>>Adam Seeley wrote:
>>>
>>>
>>>>Hi,
>>>>
>>>>I'm setting up some scenes to be as flexible as possible
>>>>
>>>>
>>>and would like to nest Referenced Models.
>>>
>>>
>>>>e.g. I have a master Referenced Model that holds a car and
>>>>
>>>>
>>>would like that Referenced Model car to have some Referenced
>>>Model tyres inside it which are Instanced four times (again
>>>within the Master model).
>>>
>>>
>>>>I'm trying to keep the Modelling and Render pipelines
>>>>
>>>>
>>>separate so I can create stand-in models that get updated
>>>when the modellers can get to them.
>>>
>>>
>>>>The nesting seems to work on a simple scene, but be a bit
>>>>
>>>>
>>>flakey when the scenes get a bit more complex. e.g. Models
>>>falling out of Partions.
>>>
>>>
>>>>Do we reckon that this is just a plain bad idea, or should
>>>>
>>>>
>>>they hold up these days?
>>>
>>>
>>>>The Referenced Models are using a Referenced Material Lib
>>>>
>>>>
>>>as well which also seems like a good idea.
>>>
>>>
>>>>Any early warnings about these setups are welcome.
>>>>
>>>>Ta much,
>>>>
>>>>Adam.
>>>>

No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.5.467 / Virus Database: 269.6.6/795 - Release Date: 09/05/2007 15:07


Search the XSI List archives here or use the advanced search form to search across mailing lists. Searching help is available.
This site supposedly brought to you by Benjamin Grosser and the Imaging Technology Group.