View Full Version : "List controlers" -- Max to Xsi Question

05 May 2008, 01:54 AM
Hi there,

I have been using XSI for a bit now and there's one thing that comes up occasionally that stumps me a bit. I came from Max so if there are any other max to xsi swithers out there you might understand.
In Max, if you have an object that has a 'look at' controller (for example) you could add an xyz rotation controller to it and then animate it's rotation on top of the 'look at' controller's rotation. They are called List controllers and it allows you to keep adding onto the one node.
Am i right in saying that if you wanted to do the same thing in XSI you would have to have multiple nodes linked to each other?


05 May 2008, 11:13 PM
you can pile up controllers in XSI like you do in Max (in xsi these are just "Constraints").

In max you'll set a "list controller" to mix those constraints where in XSI each constraint already comes with a blend value and a rest pose.

So if you wanna animate the rotation for example of an object that has a direction constraint, you can inspect the Constraint under the Kinematics of that object and see the direction constraint already has the offsets.

On the direction constraint case, it already let you change the rool in the rotation handles, so if you wanna do offset interactively (not using the offset sliders in the constraint PPG), you do that activating the "CnsComp" button that is in the constraint panel.
Or you can set a direction constraint and a orientation constraint. And use those individual constraints (more like max does).

It's different because XSI don't put a controller to control controllers, like Max need to.
You put all constraints together as they can blend naturally if they don't interfere on each other. If you need two constraints of the same type, you can still animate blends to turn specific constraints on/off depending on what you need.
Hope that helps.

05 May 2008, 11:21 PM
It might be worth mentioning that in xsi constraints are serialized and not parallelized in their blending.

What that means is that if you have three constraints with different blend values (say 1, 1, 1) contribution will not be normalized and result in all of them affecting the final result, but rather the last one being dominant.

It's not particularly bad once you know it, and if you feel you need them to work in parallel it's trivial to create a custom CP and offer sliders that will read values and set a sequence that acts like normalizing contributions (it's also easy to automate it with a little script).

While not always terribly practical it has the upside of making an absolute bias possible, whereas systems that constantly normalize can require some equivalent amounts of trickery when you want absolute bias. It's just worth knowing as it gets some head-scratching sometimes for people who come to XSI used to Maya's or MAX' parallelized blending.

05 May 2008, 12:53 AM
Thanks for clarifying that.

I guess i just find it a bit tricky to get used to. Especially how if you adjust the blend weight below 1 (with nothing 'below') sometimes you get unpredictable results (which could be nice for simple laggy dynamics type effect). Also I would much prefer to allow the animator to control rotations ect with the onscreen transform manipulator rather than sliders referencing offsets, but I might just have to add some extra nodes to my rig.

05 May 2008, 07:04 PM
Hey Rafaelle
bring the constraints to the mixer isn't the way of normalize blending? As the mixer output the blended value instead of the constraint itself...
Or it's gonna be a serialized blend anyway?

Sure that if you blend constraints you'll need a custom PPG for that.

CGTalk Moderation
05 May 2008, 07:04 PM
This thread has been automatically closed as it remained inactive for 12 months. If you wish to continue the discussion, please create a new thread in the appropriate forum.