View Full Version : cycle warnings - ignore them?

05 May 2011, 08:24 PM
I made a space-switching setup with an expression that works, even though it gives me cycle warnings. The objects don't go crazy when I manipulate them, so is it okay to leave it as is?

05 May 2011, 08:30 AM
cycles are never good !

you might want to try "UNDO" while animating , and then you might see - that the rig does not work when undoing certain actions .

( if it is just a simple private home-production ) :
indeed there are a few cycles , that well ... are not causing any bad behavior , when playing the animation forward ( and thats what is mostly needed ) , so in that case ... well, yes , you CAN ignore . then you can disable the cycle-warnings somhow with "cycleCheck -e -warnings off" ... or somehow , i do not know the exact mel-command right now .

but i would suggest , to eliminate the cycle anstead than ignoring it . cycles are never good , and once you work in a professional studio , and your supervisor finds any cycle in your rigs .... you might get fired , because of incompetence . there should never be any cycles in any sort of animation-setup !!!

05 May 2011, 09:38 AM
Yeah I second that, it can cause trouble down the line so its always best to take the secure road and fix it right now. Right now I'm trying to make sense of a cycle warning that seems to come from a node that the attach to motion path creates, it really makes me crazy.

Well, have fun untying that knot. :) And if you have trouble with it you can always upload the file and maybe someone of us can point to where exactly the problem is.

05 May 2011, 03:02 PM
Now I've discovered a cycling issue within the expression itself, it seems. To explain the scene(which I've attached) a bit:
The red sphere is the constrained object, the two blue ones are it's targets. The locators are constrained to the red sphere but parented under the same group as the blue spheres, thus providing the precise target offset location for my parent constraint. I also added a int attribute on my constrained object called slelectParent which drives the weight of the parentConstraint's two targets: when set at 1 means pCube2 is the driver and when at 2, pCube3. My expression then looks like this:

if(pCube1.selectParent == 0){

pCube1_grp_parentConstraint1.pCube3W0 = 0;

pCube1_grp_parentConstraint1.pCube2W1 = 0;

locator1_pointConstraint1.pCube1_grpW0 = 1;

locator1_orientConstraint1.pCube1_grpW0 = 1;

locator2_pointConstraint1.pCube1_grpW0 = 1;

locator2_orientConstraint1.pCube1_grpW0 = 1;[0].targetOffsetTranslateX = locator2.translateX;[0].targetOffsetTranslateY = locator2.translateY;[0].targetOffsetTranslateZ = locator2.translateZ;[1].targetOffsetTranslateX = locator1.translateX;[1].targetOffsetTranslateY = locator1.translateY;[1].targetOffsetTranslateZ = locator1.translateZ;[0].targetOffsetRotateX = locator2.rotateX;[0].targetOffsetRotateY = locator2.rotateY;[0].targetOffsetRotateZ = locator2.rotateZ;[1].targetOffsetRotateX = locator1.rotateX;[1].targetOffsetRotateY = locator1.rotateY;[1].targetOffsetRotateZ = locator1.rotateZ;

}else if(pCube1.selectParent == 1){

pCube1_grp_parentConstraint1.pCube3W0 = 0;

pCube1_grp_parentConstraint1.pCube2W1 = 1;

locator1_pointConstraint1.pCube1_grpW0 = 0;

locator1_orientConstraint1.pCube1_grpW0 = 0;

locator2_pointConstraint1.pCube1_grpW0 = 1;

locator2_orientConstraint1.pCube1_grpW0 = 1;[0].targetOffsetTranslateX = locator2.translateX;[0].targetOffsetTranslateY = locator2.translateY;[0].targetOffsetTranslateZ = locator2.translateZ;[0].targetOffsetRotateX = locator2.rotateX;[0].targetOffsetRotateY = locator2.rotateY;[0].targetOffsetRotateZ = locator2.rotateZ;

}else if(pCube1.selectParent == 2){

pCube1_grp_parentConstraint1.pCube3W0 = 1;

pCube1_grp_parentConstraint1.pCube2W1 = 0;

locator1_pointConstraint1.pCube1_grpW0 = 1;

locator1_orientConstraint1.pCube1_grpW0 = 1;

locator2_pointConstraint1.pCube1_grpW0 = 0;

locator2_orientConstraint1.pCube1_grpW0 = 0;[1].targetOffsetTranslateX = locator1.translateX;[1].targetOffsetTranslateY = locator1.translateY;[1].targetOffsetTranslateZ = locator1.translateZ;[1].targetOffsetRotateX = locator1.rotateX;[1].targetOffsetRotateY = locator1.rotateY;[1].targetOffsetRotateZ = locator1.rotateZ;


They cycle warnings occur when the .parentSelector attribute switches to 1 or 2. However I also discovered on re-opening the file that my expression isn't outputting properly the weight values to my parentConstraint. It now appears to be randomly jumping to and from each if statement and setting the weights as anything whenever .parentSelector changes. When I opened the scene both weights on the parentConstraint were 1, and when I tried resetting them they became 0,1 when .parentSelector was still 0. So there is something there that I can't ignore, but what is it?

05 May 2011, 04:03 PM
Sadly I couldn't open the file but I think I see where the problem is, you constrain the locator to the red sphere and at the same time you collect data from the locator that you use in the red sphere.

Some other things I'm wondering about is, wont there be a jump when you switch between different constraints?. It seems like the classic one constraint per group and using the blendpoint to turn it on or off would be a simpler and cleaner setup.


05 May 2011, 04:11 PM
I forgot to mention: The file was written from a student version of Maya 2012. I don't believe there are any version-exclusive nodes in it, except for some weird apiFileNode (don't know what it is or where it comes from, but if you kill all scripJobs they go away) so maybe it'll open through the "ignore version" option?

At the onset, only the one locator being switched off would jump, but the red sphere remained where it was...

05 May 2011, 04:38 PM
alright, to shed some light on this, as it seems im the only one completely understanding what he wants to do, or at least i think so, cuz i've been through it..

cycles are never good ! ... there should never be any cycles in any sort of animation-setup !!!...

agreed, to certain extent. there might be cycles that are just there and your rig never breaks.
the rule of thumb here is, if you can avoid cycles, do it, period. if you can't, but you have a very good understanding of the deformation order, inputs and outputs and all that, and you're sure that the rig won't break, leave them.

...and once you work in a professional studio , and your supervisor finds any cycle in your rigs .... you might get fired , because of incompetence.

never heard of any case like that. First of all, no one without understanding of proper cycling and work-around techniques would make it to a professional studio, Second, if a supervisor sees a cycle on a rig, that's what he's there for, to control that stuff. If stuff didn't break apart occasionally, what would they do, haha... But seriously, it's the "hiring part" where this should be discovered, not on a feature or anything serious...

But anyhow, back to the main thing.

I understand what you're trying to do, i've tried the very same thing. inputting the precise offset to the parent constraint offset of the objects. I had it working for a while there, but then i saw the bad part about it.
At some point, you can get it working too. The problem arises when you randomly click on the timeline, or do any sort of jumping on timeline or scrub the timeline backwards... what the 'updating offset' does, is takes the position where it switches, meaning if you jump from frame 1 to frame 500, and in the meantime you switched 20 times, the expression ain't gonna know that, and give you the same position as you have on frame 1.
That right there is a textbook example of non-animation friendly thing :) At this point, the expression is setting up the attribute 'dynamically' meaning that only playback to the spot on timeline that you want, will get you the correct position/result. And that is just not right...
I'd like to point you in a right direction, but i don't think there is one, unless you wanna learn loads of scripting. then you might wanna script yourself a node that would do all that stuff. Python here would be the way to go.

05 May 2011, 05:13 PM
Actually, I've been trying that for awhile now. There's another thread about my approaches here. (
The latest attempt is at the end of the thread, if you have the time to look it over I'd appreciate any help you could offer for getting it to work....

05 May 2011, 02:56 PM
man, i'd love to very much, but am currently switching to python, so i have yet to learn all that... at this point, i thank you for sharing the thread, cuz with your permission i'll dig into it and try to understand it :)

hope you get it working tho! if you do, would you inform me please? have never tried the node-approach since it's always been out of my reach, so i'd be interested in how that works out. i know the theory behind it is solid, i just couldn't script that now...

05 May 2011, 12:35 AM
I might be going about this the wrong way again...Wouldn't it be easier to create a callback command for all parentConstraint nodes in the scene? Then it would be just a question of, when would one ever need to not maintain offsets on a parentConstraint with multiple targets?

05 May 2011, 07:29 AM
hey mate, ressurecting this thread since i've had some time to think about the mechanics of it over the weekend, not much tho ^^

how's your node going?

anyhow, here's what im thinking:
the offset in the parent constraint gets setup dynamically. we established that. the thing is, right now, it won't be animation-friendly unless we keyframe the offset in some way (cuz right now, it reads the latest space from the last position we switched, but that position is dependent upon the previous switch, and that one on the previous one, etc, so the animation won't be right unless you key the offset on frame 1 and playback the whole thing from there.)

what i was thinking was a node, that would act as keyframing the offset but would be dynamic in a way that it would get linked and set up like this:
spaceSwitching attr changes - store the coords of the new offset object in say attr 'position[0]' of the node. now that position[0] is linked to the switcher attr, in that it changes when the keyframe on the switcher gets moved with - the animator moves the keyframe on the spaceSwitcher, the node updates the offset it needs to have.
the coords then get pushed in the offset attribute of the parent constraint.

this is obviously just a rough outline, but im just thinking out loud atm... needs a lot of polishing, but hey ;) my basic though was that the numbers being pushed in the offset, need to be stable, not dynamic. which this should take care of...

if you get it to work, really let me know, and i hope this will somehow help you :)

05 May 2011, 06:01 PM
My node is almost functional; there's a repository on GitHub where you can take a look at it:
The latest example scene file doesn't have the node and the parent constraint connected (EDIT: Now Is), but you can see the potential outcome if you compare the outTranslate attribute(s) on the node and the targetOffsetTranslate attribute(s) on the constraint. So far I still can't find a way to set/update the offsets before the constraint's weights are set, and for some reason it wouldn't save the compound attribute ("parents," should be "offsets" I guess EDIT:Now Is) on the node if it's not connected to anything. I haven't even started to think how to get this node to work when the transforms are animated...
Note that the node is compiled for 64-bit versions of Maya....

06 June 2011, 09:43 PM
I think my node is ready for testing. I also have made another node for seamless ik-fk switching. Who's interested?

06 June 2011, 02:05 AM
very good job! (that is if it works as it should :P) i'd take a crack at it this instant. lemme PM you about this...

06 June 2011, 02:41 AM
Hey Nemeru (and anyone else who is interested), I uploaded the latest release on GitHub. I went back to C++ as there might be certain API functions in my plugins that aren't available in python.
The multiparentnode plugin simply works like this for now:
1)create it: "createNode multiparentnode;"
2)in the attribute editor, add matrices to the inputMatrices attribute. also add the same amount of offsets attributes. The number of matrices and offsets should equal the number to targets to your parentConstraint.
3)connect your target's world matrices into the inputMatrices[i]
4 or 5)connect the offset[i]'s outTranslate and outRotate attributes to the parentConstraints target[i]'s targetOffsetTranslate and targetOffsetRotate attributes, respectively.
5 or 4)drive the selector attribute and the weights on your parentConstraint with some custom int or enum attribute on the transform you want to control the space switching with. When that attribute is set, the node should evaluate and update the offsets.

There are example files in my repository, try and use the latest number one, but I'm not sure even that is recent to this method (older ones may be completely incompatible as I've added and removed attributes in my node throughout the iteration of file saves). It still needs work; I'm predicting that it's currently still not friendly for keyframe data....

Oh right. The link:

CGTalk Moderation
06 June 2011, 02:41 AM
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.