Re: Re:center/pivot was - XSI Montreal "Tips & Tricks" session, looking for presenters

["Tim Leydecker" <BauerOink(at)gmx.de>]

Hi Luc-Eric,

thanks for the in-depth explanation. I won´t be
able to post an according reply until later tonite
or maybe even tommorow.

I´ll go through everything you pointed out, to see
if I can reasonably illustrate why I´d expect the
MCP SRT axis text fields to reflect the coordinate
system set in the Manipulation modes and why I´d
expect to be able to nummerically enter values in
those fields and - from a user perspective - would
also expect this for the KP/L. Stating it´d be powerful
is obviously not enough.

Basically, I had expected a higher level of automation
and conversion implemented to cope with the added
ability to explicitely set a working mode, e.g. it being
fully implemented throughout XSI to allow to simply hit [k].

Cheers

tim


----- Original Message ----- 
From: "Luc-Eric Rousseau" <lucer(at)Softimage.COM>
To: <XSI(at)Softimage.COM>
Sent: Friday, June 02, 2006 7:45 AM
Subject: RE: Re:center/pivot was - XSI Montreal "Tips & Tricks" session, looking for 
presenters


> If you want to use features of both the Transform Panel and the Keying Panel, it's 
> totally fine, make a layout that has both on-screen.   The keying panel publishes 
> the real object parameters to be keyed to the animator.  It's only 'by default' 
> that 9 parameters from the local transforms property set are in there, normally in 
> a rig they are not.  It could show only 'X' for translation, or only local rotation 
> in 'Z'. There can be custom parameters driving the transform some other way.  It's 
> a customizable panel for the TD to control what's animatable and what is not, and 
> if local translation is there it's suposed to show that and not show some value 
> made up by combining other parameters, unless it's a custom parameter setup that 
> way by the TD.  The keying panel will have been setup to be EXACTLY what the 
> animator wants and needs to look at and is not suposed to be re-interpreted by the 
> application depending on some heuristics.
>
> If you're going to be playing around with various reference modes tools AND 
> animating, you need to know exactly what low level parameters these tools change, 
> because those parameters are the ones that need to be keyed and will be 
> interpolated.  For example, try to animate that example of scale in COG mode when 
> the center is off screen as it were.  It probably won't animate the way you think, 
> if it works at all, it's not right method to animate that effect.  The math doesn't 
> work that way. On top of this if you use the 'K' key in XSI mode to set the keys, 
> since only the scale parameter is marked by the scale tool, only the local Scale 
> will be keyed, but that scale operation modified  both Transform and Scale.  You 
> need to know how the tool works and what fcurves are going to be generated.
>
> > If you say this can´t be expected to be supported you´re actually
> > limiting any form of reliable animation
>
> It's useless to accuse me of this, I did not invent mathematics or rigging.  If you 
> need to animate an object in relation to another point, you've got pivots, 
> constrains, parenting, expressions, and other tools, it's basic rigging.  It works 
> for everyone the same and no one is really being limited in terms of precise or 
> reliable animation.  It's the very goal of rigging to setup thing so that the 
> values and range of the parameters being animated have proper meaning, and it's in 
> the keying panel that they are published.  When he opens the animation editor, the 
> animator will then see the curves with the same values entered in the keying panel, 
> animation interpolates the right things, and there are no suprises.
>
> > -----Original Message-----
> > From: Tim Leydecker
> >
> > Hi Luc-Eric,
> >
> > since you offer the option to work in different "switch modes" while
> > modeling, even offer the option to animate the object pivot, the
> > keying panel should of course allways display the correct values,
> > e.g. show data that fit´s the mode selected to work in currently.
> >
> > Even if the keying panel is to be thought of as the left side of the
> > animation editor, supposed to hold animation curves expressed
> > in local space, this would only require a translation step between
> > current mode and the resulting key in local space.
> >
> > If you say this can´t be expected to be supported you´re actually
> > limiting any form of reliable animation as well as modeling
> > that involves numerical input, either through script or direct userinput to
> > local space therefore don´t really support the other spaces as workingmodes.
> >
> > You where relating to Maya´s channelbox in a previous mail, which
> > allways shows the corresponding SRT values but doesn´t have more
> > than local space or the option to directly animate the pivot,
> > therefore aturally doesn´t need to have any conversion steps but is also just
> > as limiting as it doesn´t allow to, let´s say plant the right
> > foot onto a 0° angled plane, theleft foot an exact 3 units onto that same plane
> > (one could do that by getting something out of curvelength, livepaint
> > a curve onto the planesurface, attach foot (indirectly) to follow the
> > curvepath and dial in a percentage). In XSI, one "should" be able
> > to simply set the 30°plane the ref plane, snap to it, key, snap other
> > foot to it, add +3 in the KP/L and key. Resulting curves could still
> > be stored in local space, plotted in worldspace. See the power?
> >
> > Cheers
> >
> > tim
>
> ---
> 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