ModelA.ModelB.null
ModelC.ModelB.null
Would be what I would consider the logical way to go. Just like
a directory hierarchy nothing under a model can affect in any way anything
outside of it. How would you feel if your directories under your root were
renamed because another directory inside a directory already had the same name.
Model space is supposed to have it’s own name space but it doesn’t.
From:
owner-xsi(at)Softimage.COM [mailto:owner-xsi(at)Softimage.COM] On Behalf Of guillaume
laforge
Sent: 03 July 2006 10:37
To: XSI(at)Softimage.COM
Subject: [Norton AntiSpam] Re: Re: constraints dropping off reference
model components
>Create a new model under the root, call it ModelB. It
becomes ModelB1.
I think it is the correct behaviour. This way it is impossible to get two
models with the same name. Otherwise the system would be broken as
Model_A under the scene root and Model_A under an other model could return
children with the same name.
Cheers
Guillaume
On 7/3/06, kim aldis <kim(at)aldis.org.uk> wrote:
Create ModelA, ModelB, ModelC,
each with a null, identical name of the null in each model.
Put ModelB and ModelC under
ModelA
But sorry, I'm a bit off tack on
this. The nulls remain uniquely named but the models under Model A won't be.
Create a new model under the root, call it ModelB. It becomes ModelB1.
Sorry to be misleading.
> Currently
you have null1 under both ModelB and ModelC, they'll be referenced as
ModelA.null1.
Sorry, but I don't understand what you mean Kim.
I create a Model_A with null1 inside. Then Model_B with null1 inside. I drag
and drop Model_B in Model_A and when I select null1in Model_A its name is
"Model_A.null1" an in Model_B it is "Model_B.null1" ( in
5.0 and 5.1 ).
On 7/3/06, kim aldis <kim(at)aldis.org.uk> wrote:
You misunderstand me, I think.
Currently you have null1 under both ModelB and ModelC, they'll be referenced as
ModelA.null1. Both of them. They should be ModelA.ModelB.null1 and
ModelA.ModelC.null1.
>Consider ModelA with ModelB and ModelC
under it. What happens
>if both ModelA and ModelB have an object named 'null1' under them. That's
>going to screw all sorts of things up. I wouldn't go near them no matter
>what.
I think it is the correct behaviour otherwise it isn't possible to put a
"null1" under the scene root model and an other "null1"
under a model, and it would destroy a great "model feature".
Maybe we need a specific object type for "scene root model" with a
different behaviour than "standard models" ? But if you merge a
scene, the merged "scene root model" become a "standard model"...
It doesn't look so simple...
My useless 1/2 euro
Cheers
--
Guillaume Laforge
freelance TD | cg Artist
On 7/3/06, kim aldis < kim(at)aldis.org.uk> wrote:
The fact that they don't follow naming down the hierarchy is enough in
itself for me. Consider ModelA with ModelB and ModelC under it. What happens
if both ModelA and ModelB have an object named 'null1' under them. That's
going to screw all sorts of things up. I wouldn't go near them no matter
what.
> -----Original Message-----
> From: owner-xsi(at)Softimage.COM
[mailto:owner-xsi(at)Softimage.COM]
On
> Behalf Of Bernard Lebel
> Sent: 03 July 2006 05:21
> To: XSI(at)Softimage.COM
> Subject: Re: constraints dropping off reference model components
>
> > > Also, when dealing with saving actions and the likes accross
nested
> > > models, I once or twice noticed that the "lowest"
Mixer (the one of
> > > ModelB for example) would "copy" itself onto all
parents that are
> > > models. Messy. Not sure if this is still the case in XSI 5.11
> though.
> > [kim aldis]
> >
> > In 5.1 and 5.11, any nested models don't have any of their objects
> > stored in the action. They're completely left out. AARRGGHH!!!!
>
> Oh, ouch....... one more reason not to use nested models.
> ---
> Unsubscribe? Mail Majordomo(at)Softimage.COM
with the following text in
> body:
> unsubscribe xsi
>
---
Unsubscribe? Mail Majordomo(at)Softimage.COM
with the following text in body:
unsubscribe xsi
--
Guillaume Laforge
freelance TD | cg Artist
|
