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
