Another cycle warning

[wrend]

yeah, seems out of order to me.

[lostpencil]

Hmm... Works fine on my Win Maya 4.5 version. No warnings.

[Wigaru Wiyamoto]

I've gotten this warning before, though not in this situation. Everything has always worked as expected, so I just ignored it.

[rhythmone]

Here is a shot of the hypergraph.... and granted I am really new to the hypergraph so I have yet to fully get what is going on here but I could see a potential connection loop, does this look wrong to anyone?
http://homepage.mac.com/tymznd/motion_weirdness.gif

[wrend]

it looks fine, extactly as expected. really unsure why you are getting the error. it does this on totally fresh scene? new curve, new box.

[mark_wilkins]

I get this warning for version 4.0 as well.

Maya checks for loops in the dependency graph and issues that warning when it finds them because they can often lead to problems. However, there are lots of common situations (particularly with features like motion paths and dynamics) where you'll get the warning and can safely ignore it.

As the warning says, you can use the cycleCheck -e off command to disable the warning if you're keeping enough of an eye on your scene's dependency graph to see these problems yourself. However, it's not a sign that something's actually a problem, it's just a warning that it might be and to check it out.

Version 4.5 may suppress these warnings automatically in some circumstances where 4.0 did not.

-- Mark

[Octagon]

Originally posted by mark_wilkins
I get this warning for version 4.0 as well.

Maya checks for loops in the dependency graph and issues that warning when it finds them because they can often lead to problems. However, there are lots of common situations (particularly with features like motion paths and dynamics) where you'll get the warning and can safely ignore it.
[...]

-- Mark

question is, how can you discriminate between critical and "normal" cycles?

i find it hard to understand how a cycle can be anything but critical at all times :surprised

and I'm _really tired_ (no explicit words here) of worrying about all those cycle warning when doing particle scripting. and your supervisor or fellow animators wouldnt want to use a script or particle setup that spits out cycle warnings right? :thumbsdow

so i'd say there should be some indication in the warning whether the cycle is a problem or not

if anyone from AW is reading this, this specific thing about cycles being spit out by _not_ doing anything wrong really suxx big time ... :annoyed:

matthias

[Wigaru Wiyamoto]

Well, as long as everything is working fine, why worry?

[dwalden74]

Hi Mattias!

this specific thing about cycles being spit out by _not_ doing anything wrong really suxx big time ...

I second that one. I also did a script that, when executed, sometimes issues a warning and sometimes not... :thumbsdow A real downer if you ask me...

:beer:
David

[Octagon]

Originally posted by Wigaru Wiyamoto
Well, as long as everything is working fine, why worry?

:eek:

trying to keep calm here ...

obviously it's very important to be concerned about cycles when writing a script and not only executing a single command that leads to a cycle. what works now migh not in the future ...

for example:
say your write a script that spits out cycles but works just fine, as you say. you assure the supervisor (or whatever guy/gal that is in charge) there's no problem with that cycle.

you wouldnt want your supervisor take you on because some kind of say ... render problem occurs and the error is backtracked to your cycle -after 3 hours of trying to find the error.

matthias

[mark_wilkins]

If you've checked it out and it's all OK, why not just put cycleCheck -e off in your script?

The kinds of cycles that are a big mistake are where node A plugs into node B, which calculates a value that plugs back into node A, which affects the very output of node A that you'd plugged into node B.

It's OK to have such a cycle if not all of node A's outputs depend on every input. Usually these errors pop up when you're doing things where nodes do several, mostly independent calculations and the loops don't screw things up.

I believe that we did that in one of the examples in our book. Kinda sucked, but Maya forced us to do it. :D

-- Mark

[Octagon]

Originally posted by mark_wilkins
If you've checked it out and it's all OK, why not just put cycleCheck -e off in your script?

The kinds of cycles that are a big mistake are where node A plugs into node B, which calculates a value that plugs back into node A, which affects the very output of node A that you'd plugged into node B.

[...]
-- Mark

cycleCheck -e off disables cycle warning for the whole maya session, I believe. I'd love to turn cycleChecks off for specific nodes but not on the whole scene.

i agree that the most problematic cycles are obvious when they apprea first so it's not so hard not to run into them.

but nonetheless my point was AW should work on differentiating the cycles warning messages as i wrote in previous posts.

oc.

[mark_wilkins]

... and I was saying it sounded like they'd started to do this in 4.5, from the comments above.

-- Mark

[Octagon]

Originally posted by mark_wilkins
... and I was saying it sounded like they'd started to do this in 4.5, from the comments above.

-- Mark

yes, you're right. i didn't mean to offend you, I'm sorry if I sounded a bit rude in my previous post.

but since other things that are very common are still not working without cycle warnings those "improvements" (as in the motion path example above) could be more of a hack / fix for a specific node to node connection than a real improvement in how the DG detects cycles

simply try this: get some particles in maya and assign radiusPP attributes. map those attrs with a ramp over age -> cycle error on arrayMapper.
the cycle error doesn't occur when ramp mapping other pp attrs such as color or opacity. *sigh*

-oc

[mark_wilkins]

Oh, I have no doubt that it's a hack, and don't worry, I didn't take offense. :D

-- Mark

[CGTalk Moderation]

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.