Mesh doesn't follow rig ...


… except from the first frame. There the mesh moves, but then it stands still.

I don’t get it. The rig should be able to deform more than one object?! Actually it does already deform two objects, although the second object is a copy of the first one.

The mesh (which doesn’t deform) got envelopes, a static_kinestate, so why doesn’t it get deformed always, only on the first frame (the first frame when the play button gets pressed)?

I can’t see a difference between what I did with the first mesh which does deform and this one. The envelope operator is enabled, so I don’t get it. Is there somewhere a button which needs to be enabled (“deform on every frame”)?

My rig is based on nulls, deformed with ICE. The rig gets deformed in the simulation stack.

Anybody who can help? I’m really frustrated, as I need to finish this project instantly.

Thanks for any advice or tip!!!



You list your problem in your own post.
For ice simulations ice needs an initialstate of the mesh. By having it you are telling it to use the stack below in whatever state it’s in at the first frameof the simulation.
Your rig below is only acting until the sim starts, then it gets cached in that state.

You need the rigged mesh to be an input into another simulated one, possibly as an added force per point, to simulate on top of that.


Not quite sure to understand you.

There is no mesh that is rigged at all. There is a model in a scene. This model contains several meshes, a hierarchy with nulls (the rig) and a null with two ICE trees. An Init tree under the pre-sim stack and a Eval tree in the simulation stack.

The initial model I brought into the scene gets displaced by the moving nulls of the rig hierarchy (Athough I discovered problems lately when I tried to reposition controlers at frames other than the first one. Needed to press play again from the start in order to update the rig and deformations).

The other mesh doesn’t gets displaced, although the envelope got coppied via GATOR.

I kind a feel what you tell me, though I don’t understand it yet and can’t come up with a solution so far. If the nulls are moving, so should the mesh. Only if the evaluation order gets kind of strange than I understand that the mesh still thinks the nulls are at there original position. But how do I tell the mesh (without any ICE trees at all) to deform after the simulation took place?

Thanks so far!


O.k., I was digging a bit deeper and realized that the bunny in the ICE examples scenes does have its own ICE tree which deforms it. Actually the envelope operator is disabled, so only the ICE deforms apply.

So far I didn’t need this custom ICE deformer, as I didn’t disable the envelope operator yet. And so far it did work. The rig deformed my mesh.

But as I said, this doesn’t work all the time if I bring in additional geometry, use GATOR to copy the envelope and the hope that the mesh gets deformed. It doesn’t.

So I tried to go the way as seen in the rabbit rig example, added the deformer to my mesh and it worked. Kind of, as the mesh goes in all directions, but not the one which it should go.

I found out, that the custom BoneID attribute of each defomer (null) and the envelope deformer indices attribute are out of sink.

So the envelope on the mesh points refers to deformers which arent responsible for this region. But how do I get these back into sync? I spent quite a lot of time to tune this envelope, so I wouldn’t like to start over again to paint it.

Point is, whenever you bring in new bones to enhance the rig, your Bone IDs might change, as they get recalculated.

So this may be the point, where Softimage looses the connection between envelope and deformers.

But how can I fix this? Easily?


If you’re using ice for skinning it relies on the group order to sync with the envelope. Select deformrers from envelope create a group and hook that one up and get rid of the previous one. Or re-gator if it’s on aseparate mesh. It’s kind of hard to understand what you are doing with what tbh :slight_smile:


Selecting the object in the alphabetical order and create a new group shouldn’t be a problem, but as you said: The deformer ID (Bone ID, which is a custom attribute) needs to be in sync with the internal. This makes me think thant I would need to select the envelopes null in the order of the ID numbers. With 200 bones + this is going to be a nightmare.

And even if I’d manage and add the bones again to my envelope,does SI keeps the weight I already created and fine tuned?

I just thought about enveloping the same object again and then create an ICE tree which compares the bones from the original, correctly weighted one, with the bones from the new one and exchange the order according to a kind of look up table.

What I don’t get is that if there is no deformer ICE tree on my mesh and I just use the envelope and rely on SI on deformer (like for real bones), the object transforms correctly. If I go the ICE way and disable the deformer op, then it get screwy. Shouldn’t it behave the same in both cases?


P.S.: Would it be possible to create a script which selects all the envelope nulls in a group in order of their Bone IDs? If I would create a group with this selction and re-apply these bones to the envelope, would this solve my problems? At least the order of the bones and the deformer enevelope indices should be in sync?


Re-read my reply.
Select the mesh, use “select deformers from envelope” (will be returned within the new selection in the correct order, it’s an xsi command), group them up (groud ID will be in sync with envelope ID), connect that new group (in the ICE tree), get rid of the old (in the ICE tree). Synchronicity problem solved.


Sounds cool! Will try it instantly as soon as I got SI up und runing this morning.

Thanks very much!



Thanks so much!


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.