is Settings/Labs/Undo Send activated?
On Wed, Aug 14, 2013 at 10:42 AM, Raffaele Fragapane < [email protected]> wrote: > ARGHHH, I keep sending stuff before I edit it this week. > > "The local kinematics of an object is nothing but a transform multiplied > by its parent's transform." > Should read: > "The local kinematics of an object is nothing but a transform that will be > multiplied by its parent's transform to create the object's global." > > > On Wed, Aug 14, 2013 at 10:40 AM, Raffaele Fragapane < > [email protected]> wrote: > >> The local kinematics of an object is nothing but a transform multiplied >> by its parent's transform. >> So if you have a transform, and want it to be an object's local transform >> instead of its global, you take that transform, and multiply it by the >> parent's. >> >> IE: You want something to be offset from its parent by 1.0 in the Y all >> you need is >> vector(0.0, 1.0, 0.0) --> (pos)SRT 2 4x4 Matrix --> multiply <-- parent >> transform matrix >> >> What I'm saying is that you DO NOT need write access to the local kine of >> an object, writing to its global is perfectly fine, all you need to do is >> take into account its parent's transform and you can emulate local >> perfectly fine. >> >> The only "limitation" is that an ICE graph can't traverse the scene, so >> you can't have something in the graph saying "parent matrix" and that will >> be scene aware, you always need to explicitly pull in the object that is >> its parent to "configure" your graph so it's aligned to the scene. That >> part you need to script, but it's trivial to do so. >> >> No need to drop ICE for scripts, other than for that connection, if your >> only concern is the lack of write access to local, it's unnecessary anyway. >> >> >> On Wed, Aug 14, 2013 at 10:23 AM, Nicolas Esposito <[email protected]>wrote: >> >>> Ciao Raffaele, >>> >>> >>> The main point is that with ICE I succesfully managed to constraint two >>> nulls together ( one with the animation, the other one basically follow the >>> animated null ), but once I set the kine.global position I can see that it >>> will "jump" to the animated null position as expected, but I don't know how >>> to do: >>> - change the "follow null" position, means that I want this null to be >>> in its original position, not to be in the exact same spot as the animated >>> null >>> - as for "kine.local multiplied by a custom parameter value" I can >>> modulate the animation of a driven null as described above ( ModelB is >>> linked to the nulls.... ), so I'm not able to set the "follow null" >>> original position and then be able to insert a "Multiply by scalar" to >>> modulate its max/min the animation as set using kine.local*custom parameter >>> >>> I was thinking ( and tried ): >>> - I used a third static null that will be in the exact same sport as the >>> "follow null", use Get distance between and set the kine.global >>> properly...but once I set the kine.global how can I add a multiplier for X, >>> Y and Z axes in order to modulate those values as I'm doing using the >>> kine.local by expressions? >>> - Probably there is smething that I'm doing wrong, but in the end of the >>> ICE tree I always need to set the kine.global of my "follow null", so if in >>> the tree below I try to set for example the X, Y and Z value ny multiply >>> everything by a scalar I override the kine.global that I set before... >>> - Used StaticKine, nothing has really changed >>> - Set self.TMP values to store the original position by using a third >>> null, it works, but I always end up of having the same problem of setting >>> the kine.global, but then I'm not able to modulate the animation as >>> described by kine.local >>> >>> I'm willing to use kine.global, but seriously if I can't modulate those >>> values ( and keep the "follow null" in its original position ) I'm still >>> going to use the expressions with custom parameters... >>> >>> I'm learning a lot recently about ICE, but right now I can't think about >>> a solution that allows me do what I just described....its driving me mad :D >>> >>> Cheers >>> >>> Nicolas >>> >> >> >> >> -- >> Our users will know fear and cower before our software! Ship it! Ship it >> and let them flee like the dogs they are! >> > > > > -- > Our users will know fear and cower before our software! Ship it! Ship it > and let them flee like the dogs they are! >
