I would agree with you, except for the behavior exibited by a node when there are operators simultaneously on global and local kinematics or split between the two. The resolution of a node's kinematics may be expressed in a single matrix, however XSI must perform analysis on an entire stack of kinematic operators before calculating the result per node. In physics, this is analogous to resolving all of your forces to calculate velocity.
In every instance where it's possible, XSI allows you to influence global kinematics with local controls, or to share, or to blend. Since it would require far too much logic to pre-wire all of the kinematic operators to handle any combination we throw at them, the simpler explanation (Occam's Razor) would be to assume there is an ordered stack, per kinematic node, which is resolved into an object's transformation matrix. Evidence:
1- Set a direction constraint with no up vector, which lives on the global transform. But at the same time, you can use fcurves or expressions on the local transforms to control the up vector resolution (I use this ability on my custom spine rigs to split out torsional rotation from the shape of the spine curve).
2- Apply a pose or orientation constraint to control nodeB using nodeA. Rotate nodeA to some random multiple of 180 in each axis. You can control the quadrant nodeB resolves its matrix into euler rotations by setting keyframes on its local rotation.
In each instance, you can predict the kinematic behavior of your node by starting at the bottom of the kinematics stack and working your way up. Resolve whatever is being done locally first, then resolve global.
-Brad
> -------Original Message-------
> that is my understanding as well.
> an object only has one 4x4 matrix, and a hierarchy really is just an
> operator chaining matrices under the hood, with a local transform being
> a commodity representing the last of the matrices in the chain, and the
> global being basically an override, but nothing more.
>
> ******************************
> | Raffaele Fragapane |
> | Rising Sun Pictures |
> | "Remember, TD is for TopDog" |
> ******************************
>
>
>
> kim aldis wrote:
>
> >I'm not sure there is an evaluation order. My understanding of local and
> >global is that they're both just different representations of the same
> >thing. In fact, if you think about it and look at the values, they couldn't
> >be applied one after the other. Concatenating these two matrices would give
> >you the wrong results.
> >
> >
> >
> >>-----Original Message-----
> >>From: owner-xsi(at)Softimage.COM
> >>[mailto:owner-xsi(at)Softimage.COM] On Behalf Of brad
> >>Sent: 01-March-2006 03:19
> >>To: XSI(at)Softimage.COM
> >>Subject: RE: rigging dilemma: driving a parent with
> >>attributes of the child
> >>
> >>I believe the evaluation order can be ascertained by looking
> >>at the node stack, same as with modeling and deformation ops.
> >>Start at the bottom of the kinematic stack and work your way
> >>up. Since the Global node is higher than the Local, anything
> >>applied to Global, such as a constraint happens after
> >>whatever effect is applied to the Local transform.
> >>
> >>
> >>
> >>
> >>> -------Original Message-------
> >>> From: brad friedman <xsibrad(at)fie.us>
> >>> Subject: RE: rigging dilemma: driving a parent with
> >>>
> >>>
> >>attributes of the
> >>
> >>
> >>>child
> >>> Sent: 01 Mar '06 03:12
> >>>
> >>> There's the added complexity of the local transform vs the global
> >>>transform. Constraints apply to the global, not the local. But a
> >>>child's local transform is not affected by the parent's
> >>>
> >>>
> >>translation.
> >>
> >>
> >>>An adjustment to a global seems to trigger a change to the
> >>>
> >>>
> >>local and
> >>
> >>
> >>>visa-versa. This is a scenario you don't find in maya as there is
> >>>but one transform. I'm actually a bit currious as to the
> >>>
> >>>
> >>evaluation
> >>
> >>
> >>>order of the local and global transform in different
> >>>
> >>>
> >>scenarios like this one.
> >>
> >>
> >>>
> >>> -brad
> >>>
> >>> _ANDRE DEANGELIS <ANDRE.DEANGELIS(at)UBISOFT.COM>_ wrote: Yes
> >>>
> >>>
> >>I relise
> >>
> >>
> >>>that Kim,
> >>>
> >>> But having tried it and seeing hat it works (at least in a simple
> >>>test), I am wondering what makes this colution less than desirable.
> >>>
> >>> Andre
> >>>
> >>> -----Original Message-----
> >>> From: owner-xsi(at)Softi! mage.COM
> >>>
> >>>
> >>[mailto:owner-xsi(at)Softimage.COM] On
> >>
> >>
> >>>Behalf Of kim aldis
> >>> Sent: Tuesday, February 28, 2006 2:29 PM
> >>> To: XSI(at)Softimage.COM
> >>> Subject: RE: rigging dilemma: driving a parent with
> >>>
> >>>
> >>attributes of the
> >>
> >>
> >>>child
> >>>
> >>> Because the rotation of the parent is driven by the child,
> >>>
> >>>
> >>but the
> >>
> >>
> >>>rotation of the parent affects the position of the child,
> >>>
> >>>
> >>which then
> >>
> >>
> >>>affects the direction of the parent, which affects the
> >>>
> >>>
> >>rotation of the
> >>
> >>
> >>>child .....
> >>>
> >>> > -----Original Message-----
> >>> > From: owner-xsi(at)Softimage.COM
> >>> > [mailto:owner-xsi(at)Softimage.COM] On Behalf Of Andre DeAngelis >
> >>>Sent: 28-February-2006 19:04 > To: XSI(at)Softimage.COM >
> >>>
> >>>
> >>Subject: RE:
> >>
> >>
> >>>rigging dilemma: driving a parent with attributes of the >
> >>>
> >>>
> >>child >
> >>
> >>
> >>>>There is only one parameter dependency here.
> >>>>
> >>>>
> >>> >
> >>> > If you parent one null to another and then apply a direction >
> >>>constraint to the parent (to point to the child) it workd
> >>>
> >>>
> >>just dandy.
> >>
> >>
> >>> >
> >>> >! ; In fact, you can continur to rotate the parent in
> >>>
> >>>
> >>branch mode,
> >>
> >>
> >>>to
> >>>
> >>> > offset the whole set-up.
> >>> >
> >>> > Am I missing something here?
> >>> >
> >>> > -----Original Message-----
> >>> > From: owner-xsi(at)Softimage.COM
> >>> > [mailto:owner-xsi(at)Softimage.COM] On Behalf Of kim aldis > Sent:
> >>>Tuesday, February 28, 2006 1:48 PM > To: XSI(at)Softimage.COM >
> >>>Subject: RE: rigging dilemma: driving a parent with
> >>>
> >>>
> >>attributes of the
> >>
> >>
> >>>>child > > I'd be intrigued to see how, as rob says, the
> >>>>
> >>>>
> >>child is
> >>
> >>
> >>>dependant upon > the parent which is dependant upon the
> >>>
> >>>
> >>child, which
> >>
> >>
> >>>is dependant upon > the parent which is dependant upon the child
> >>>which ...... And the > whole thing rapidly crawls up it's
> >>>
> >>>
> >>own arse.
> >>
> >>
> >>>Whichever software you > use.
> >>> > Would have been the same in SI3D too.
> >>> >
> >>> > > -----Original Message-----
> >>> > > From: owner-xsi(at)Softimage.COM
> >>> > > [mailto:owner-xsi(at)Softimage.COM] On Beh! alf Of
> >>>
> >>>
> >>David Gallagher
> >>
> >>
> >>>>>Sent: 28-February-2006 18:39 > > To: XSI(at)Softimage.COM > >
> >>>>>
> >>>>>
> >>>Subject: Re: rigging dilemma: driving a parent with >
> >>>
> >>>
> >>attributes of
> >>
> >>
> >>>the > > child > > > > > > Maya has its benefits. It
> >>>
> >>>
> >>handles this
> >>
> >>
> >>>situation better > unfortunately.
> >>> > >
> >>> > > > I don't see how you can avoid a cycle.
> >>> > > >
> >>> > > > As soon as you tranlsate the child in negative Y the
> >>>
> >>>
> >> > parent
> >>
> >>
> >>>rotates > > > causing the child to move causing the parent
> >>>
> >>>
> >>to rotate
> >>
> >>
> >>>>causing the > > > child to move...
> >>>>
> >>>>
> >>> > > >
> >>> > > > _rob
> >>> > >
> >>> > >
> >>> > >
> >>> > > --
> >>> > > David Gallagher
> >>> > > Animator, Blue Sky Studios
> >>> > >
> >>> > > ---
> >>> > > 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
> >>> >
> >>> > ---
> >>> > 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
> >>>
> >>> ---
> >>> 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
> >>
> >>
> >>
> >
> >---
> >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
>
---
Unsubscribe? Mail Majordomo(at)Softimage.COM with the following text in body:
unsubscribe xsi
