Trying facial ICE rigging setup - getting cycle errors

[sonictk]

Hi all!

I'm starting to try out ICE for facial rigging, and after watching Adam Sale's tutorials on the subject, I wanted to try and use his weightmap-split-blendshapes-into-left-and-right-side approach, but not freeze the map generators so that I could procedurally change the weight map to split shapes up at any time.

So what I did, was have two ICE trees, one that generates the left and right weight maps, and one to handle the shapes and their relationships to the facial controls. The weightmaps would be multiplied with the shapes' positions so that they only result in one side being affected.

However, I'm getting some odd behaviour in XSI, and although my rig seems to be working fine, every now and then, whenever I drag a new get data node in order to grab a new Shape's pointPositions, or do an undo/redo after a shape operation, or random operations like re-ordering the ICE trees in the operator stack, XSI will tell me that I have a cycle error somewhere in the ICE tree.

# WARNING : 3000 - Cycle through mdl_biped.geo_head.polymsh.ICE_LfRtMapping
# WARNING : 3000 - Cycle through scn_bipedRig.grpICE_facialRig.null.ICE_facialRig
# WARNING : 3000 - PROBLEMATIC EVALUATION CYCLES ARE IN THE SPECIFIED GRAPH

Sometimes it will be:
# WARNING : 3000 - **** Cycle breaking point mdl_biped.geo_head.polymsh.modelingmarker
# WARNING : 3000 - Cycle through mdl_biped.geo_head.polymsh.ICE_LfRtMapping
# WARNING : 3000 - Cycle through scn_bipedRig.grpICE_facialRig.null.ICE_facialRig

I'm worried that I may screw something up down the line, would anyone know if there is a way in XSI to find out or query what exactly is causing the cycle?

I've also uploaded the scene at http://sdrv.ms/M0EKHT ; if anyone is willing to take the time to look through my ICE graphs and see what I'm doing wrong, I would really appreciate it!

EDIT: here are my ICE trees. I'm using the same method Adam Sale outlined in order to generate the weightmaps.

http://i.imgur.com/cKNXI9x.png

The Shape Modulator compound, which takes a cluster to act as a mask, and a weightmap to feed its output:
http://i.imgur.com/KEKkCM0.png

And the get and add point positions compound, which is essentially gShapeCombiner:
http://i.imgur.com/mM3Ddew.png

And how the rig is put together.
http://i.imgur.com/T8VPl3J.png

I know it's really spaghetti-like: if anyone could recommend me a better way to improve my ICE tree, I would really appreciate it! I'm kind of going off just Adam Sale's tutorials and the cmivfx Softimage Facial Modeling For Rigging tutorial and I feel like there is probably a better way to do this, but I haven't been able to figure out how I could condense my current tree any further into more reusable compounds.

[mattmos]

What should resolve your cycle errors is moving the weights icetree below the shapes icetree. As it is currently its getting evaluated after the shapes that its supposed to be splitting up.

I posted an example tree of how I approach things on the forum before, though its still spaghetti! Dug up the link for you:

https://app.box.com/s/dxpe8tij42yk6ojc3h2d

[sonictk]

What should resolve your cycle errors is moving the weights icetree below the shapes icetree. As it is currently its getting evaluated after the shapes that its supposed to be splitting up.

I posted an example tree of how I approach things on the forum before, though its still spaghetti! Dug up the link for you:

https://app.box.com/s/dxpe8tij42yk6ojc3h2d

Hi, thank you so much for providing the great example! I was looking through it for quite a bit (I'm not that experienced with ICE yet) so it took me quite a while to figure out how you were weighting the lip tweakers without actually 'weighting' those regions traditionally...I had a lot of questions about this but I'll try to figure out some of the math-related ones myself...(I still don't understand why in your Get Point Position In Null Space compound, that multiplying the null.kine.global's inverse matrix with the global point positions would result in them being converted to null space...)

As far as my simple facial rig goes, I noticed that most of the problems occurred after I froze the Cluster Shape Combiner node. I'm not sure how that would have affected the way my weightmaps were being generated, but I also moved the order of nodes around and now it seems that I don't have the cycleerror anymore (:D ) However, whenever I open the shape manager, I get the warning that there are deform operators in the shape animation stack and that I should delete the ICE operators first. If I move the ICE operators up to the animation region, however, the shape manager re-creates that Cluster Shape Combiner.

Is there any way I can still continue to edit/preview my shapes with the Shape Manager or something similar without having to destroy my ICE trees or work on a seperate mesh with the shape keys attached?

Finally (if you have time!), some XSI-specific questions on your rig I had were:

- You have a tree set up to clone the head_mesh to the head_mesh_deform. Is there a reason for this instead of keeping the ICE tree all on the same mesh?

- Some operations such as that Clone operation and other things are done in ICE instead of via XSI's inbuilt operators, even things like constraints, etc. Is it actually faster in ICE performance-wise, or is it because you were trying to keep EVERYTHING in ICE? In this case, I also tried using the in-built constraint compounds, but ran into problems whenever I needed to have stuff like constraint compensation as well and couldn't figure out how to manually offset the constraint. How would you deal with this sort of thing?

- Why seperate out the ICE tree on the head to a separate null object? I did it for my rig because I kind of saw people doing it too (like on your rig!) but I have no idea why this is necessary/recommended?

- Is there a reason for keeping some of your trees in the Modeling operator region and some in the Shape region?

Again, thanks for sharing your workflow!

[mattmos]

I try not to keep any icetrees in the shape stack for that reason (issues with shape manager) - apologies if that example has led you down a blind alley! I found that it didn't really affect scene playback too much if the weights icetree was in the animation stack, underneath the envelope.

The shape manager does recreate the shape cluster every time you use it to remodel or create new shapes, I have made my peace with that because its still the fastest way to make shapes, and its easy enough to write a small script to clean up the shape stack and model mixer afterwards. Using ice for shapes you don't need any tracks in the mixer at all, as it all works off the clusters.

The clone of the head mesh is used to add the secondary deformation of the nulls in a similar way to the dorritos method. It stops there being any cycles, as the mesh points and shapes drive the position of the null deformers, and the deformers then drive the position of the mesh points, it would cause a cycle all on the same mesh.

-I'm setting it all up in ice as its actually safer - ie if the cloned mesh is frozen, I can rebuild the icetree easily, but if a traditionally cloned mesh is frozen, its harder to rebuild it. Its also quicker most of the time to import a compound than manually set up stuff, especially when it comes to the constraints of the parent deformers. I use a set of locators imported into the model to define the locations where I want the secondary face deformers to be, so they're basically a template, and then when I'm happy with the positions around the face, I freeze off the setup icetree, which saves the locations data to the mesh, and is easy to read in to the ice null constraints. Its re-usable for most characters.

If you want to offset the deformer, I use an extra null as an initial constraint null, and a parent deformer underneath that, and deform null underneath that. Works well for example in the cheek area where it might be nice to have some sliding to the deform effect as the cheek pushes up.

- I've separated out the ice tree to a null because its ice kine data, and if that is kept under a mesh or another object which ends up being transformed, the transforms can affect the kine data. Found it more reliable.

- Its nice to have stuff in the modelling region that doesn't need to be evaluated every frame, like the weights. Again, can just be a bit dangerous when going back and forth between modelling, texturing and rigging, as freeze modelling gets used regularly...

[sonictk]

I try not to keep any icetrees in the shape stack for that reason (issues with shape manager) - apologies if that example has led you down a blind alley! I found that it didn't really affect scene playback too much if the weights icetree was in the animation stack, underneath the envelope.

The shape manager does recreate the shape cluster every time you use it to remodel or create new shapes, I have made my peace with that because its still the fastest way to make shapes, and its easy enough to write a small script to clean up the shape stack and model mixer afterwards. Using ice for shapes you don't need any tracks in the mixer at all, as it all works off the clusters.

The clone of the head mesh is used to add the secondary deformation of the nulls in a similar way to the dorritos method. It stops there being any cycles, as the mesh points and shapes drive the position of the null deformers, and the deformers then drive the position of the mesh points, it would cause a cycle all on the same mesh.

-I'm setting it all up in ice as its actually safer - ie if the cloned mesh is frozen, I can rebuild the icetree easily, but if a traditionally cloned mesh is frozen, its harder to rebuild it. Its also quicker most of the time to import a compound than manually set up stuff, especially when it comes to the constraints of the parent deformers. I use a set of locators imported into the model to define the locations where I want the secondary face deformers to be, so they're basically a template, and then when I'm happy with the positions around the face, I freeze off the setup icetree, which saves the locations data to the mesh, and is easy to read in to the ice null constraints. Its re-usable for most characters.

If you want to offset the deformer, I use an extra null as an initial constraint null, and a parent deformer underneath that, and deform null underneath that. Works well for example in the cheek area where it might be nice to have some sliding to the deform effect as the cheek pushes up.

- I've separated out the ice tree to a null because its ice kine data, and if that is kept under a mesh or another object which ends up being transformed, the transforms can affect the kine data. Found it more reliable.

- Its nice to have stuff in the modelling region that doesn't need to be evaluated every frame, like the weights. Again, can just be a bit dangerous when going back and forth between modelling, texturing and rigging, as freeze modelling gets used regularly...

Ah, I was wondering if you were using the 'doritos' method for the deformers...I was wondering since I wasn't sure which part of the tree took the place of the static kinestate property...

As far as the rest of the rig, I'm going to pick it apart when I have time and try to fully understand what's going on...but one question I have about the constraint compensation solution...is there a way to auto-calculate that in ICE instead of a manual offset (like using an intermediate transform/null like what you're saying?)

Also, I tried using the preset constaint ICE compounds, but it seems they're looking for a .__TmpConstraintPose property which doesn't exist unless the ICE tree is created directly on the constrainee object. I tried to create a ICE preset constraint on a seperate null (look At) but the tree wouldn't evaluate since the .__TmpConstraintPose property couldn't be found. Is that why you made your own version of a point constraint as a ICE compound?

Again, thanks for the detailed explanation and providing the example rig! (Sorry, couldn't find your previous post on it when I initially searched....)

[mattmos]

The parent nulls global kine kind of replaces the static kinestate - moving with the base envelope/shapes.

Not quite sure if I get why you need constraint comp or what you're using it for? Could you explain what you need to do with it?

The inbuilt kine constraints are a little overkill for what I needed - I knew that I would have the nulls parented under the head control so that they are always aligned with the head, and just needed a point constraint, and locations were ideal for that as they can be anywhere on a surface, don't have to be linked to any particular cluster.

The way I used to do it was create individual point clusters for each null, and set up each constraint manually, which got boring really fast with multiple characters!

[sonictk]

The parent nulls global kine kind of replaces the static kinestate - moving with the base envelope/shapes.

Not quite sure if I get why you need constraint comp or what you're using it for? Could you explain what you need to do with it?

The inbuilt kine constraints are a little overkill for what I needed - I knew that I would have the nulls parented under the head control so that they are always aligned with the head, and just needed a point constraint, and locations were ideal for that as they can be anywhere on a surface, don't have to be linked to any particular cluster.

The way I used to do it was create individual point clusters for each null, and set up each constraint manually, which got boring really fast with multiple characters!

Hi, thanks for the explanation! The reason I wanted cns comp on was for stuff especially like parent constraints and direction constraints, where the original position/orientation of the object was important...for now I used the standard XSI constraint, but if it's actually possible to use the in-built LookAt ICE constraint, I would like to do so! So far I haven't been able to figure out how to get past the fact that those ICE compounds all look for a .__TmpConstraintPose property though...

[sonictk]

Hi all:

Hmm, this is getting a little complicated. Now I'm trying to mirror weights on the head, but when I try to create a symmetry mapping template, I get:

Code: Select all

Application.CreateSymmetryMappingTemplate("", "", "", "")
# ERROR : 2057-GetSkeleton - Input object is not a skeleton object - [line 492 in C:\Program Files\Autodesk\Softimage 2013 SP1\Application\DSScripts\enveloping.vbs]

I've checked the deformers that are currently weighted to the head, and they're all implicit bones, just like the rest of my rig. Is there something I'm missing here?

The scene file is available at: http://1drv.ms/1cfWE34 , I'd really appreciate it if anyone has run into this situation before! I've never seen that error occur before and I can't find anything by googling around...

Also: because he is split up into several parts, is it actually possible in XSI to paint values across multiple envelopes? I tried, but it only seems to allow me to paint on the last selected envelope...

EDIT: I tried manually creating the symmetry template myself and specifying the left/right deformers. Still doesn't mirror the weights when I execute the mirror weights command, though it doesn't give any errors. No idea why...?