3
$\begingroup$

This is my first post here.

I'm a bit a newbie regarding rigging, and I have been modeling a number of mechanical devices for animating. I have been receiving different kind of errors due to cyclic dependencies and so on.

Although the rigs seem to work, they don't update properly when I try to render the animation; a sort of "manual refresh" is needed before rendering each frame, or objects won't get correctly placed. I guess this can be due to those cyclic errors, but it's difficult to trace them!

The System Console is the only tool for this? I can't copy-paste easily, search, not read the full text or getting old messages. Can't I inspect dependency errors directly within the app?

Many thanks in advance.

For those interested, I'm adding some images of the model:

Rigged model

The upper bone (red rectangle) controls the full scissor mechanism, with cylinders and security system moving around.

Render error

When rendering an animation, I get that result: cylinder orientation is not correctly updated, you can see both parts of the cylinder don't match. The same happens in the security system on the left.

The problem does not appear if I move and render still frames. Weird!

I have uploaded the model, for those interested. The upper red rectangle-bone controls all (or it should...)

Mechanical Rigging Issues Download

I have switched those options and this is the result, which looks even worse: enter image description here

The approach I'm following for rigging all my mechanical models is building a bone armature which behaves as the real model and then parenting all the mechanical parts to different bones. Most armatures are quite simple, with some basic maths and simple constraints, but I'm getting these kind of problems all the time.

Manually switching frames seems to work, with a tiny delay/jump barely noticeable, although existent (which is weird...). No problem wen rendering frames. However, when rendering animations or different poses along different keyframes, update is not correctly done.

I first managed to do these riggings without bones, just with math, dummies, and constraints. All worked fine in that scenario, so I guess it's some sort of problem with bones configurations.

I have done a simple test with OpenGL rendering along four frames. First row shows the result I get when rendering the animation, while second row show the result rendering individual frames after switching them. The result is quite different, but you can see that bones seem to behave properly in both cases, with "bad parenting" of the components, much more noticeable when rendering the animation (you can see the cylinder is not correctly positioned in any case).

enter image description here

I have discovered something interesting after further investigation:

The problem origin seems to be in allowing bone stretching. In my rig, the top horizontal bones have stretching allowed (you can notice it in the image), which allows an easy rig of the main diagonal arms. If I switch that stretching OFF, the whole model seems to work fine, as in all the other models I have rigged and which don't need stretching. So I guess this is an internal limitation on bone stretching.

Thanks for your interest, I will continue investigating...

Improve this question
$\endgroup$
2
  • $\begingroup$ have you tried to use shape keys instead of bones ? $\endgroup$
    – lemon
    Commented Sep 26, 2016 at 14:30
  • 2
    $\begingroup$ Shape keys don't seem a nice approach for a mechanical model in which there are non-lineal movements and a lot of independent components. My first rigging was without bones and worked fine, but required some math. Bones should be a nice and flexible solution, and in fact the armature seems to work fine, so no idea why can't I get the whole model working. $\endgroup$
    – J. Gomez
    Commented Sep 26, 2016 at 14:36

2 Answers 2

Reset to default
3
$\begingroup$

So after inspecting the file the problem is driver on Y axis of mel1200_center_IK bone (the one in the middle of the mechanism).

The "cyclic dependency" is between this driver and both IK constraints (bone_brazo, bone_pivot) and the base (bone_control bone) of both IK bone chains.

I've put the "cyclic dependency" into quotation marks, because logically on bone level there is no cycle - the error is on Blender side and on how it evaluates dependencies and drivers. You hit a limitation that solves the new dependency graph.

Enable it and the rig will update correctly.

Your other option is to build the rig differently either with constaints or drivers, but not mixing them. You can substitute the driver with this to solve the issue:

enter image description here

I suggest to get rid of your other drivers as well (me1200_bone_pestillo) and solve them with constraints only.

Improve this answer
$\endgroup$
1
  • $\begingroup$ Your information really worked, many thanks! From further inspection I have guessed that the jumpy behavior was due to the use of a driver for the center IK. Using the constraints instead works far better, as you said. I also changed parenting in order to avoid hierarchy cycles for the cylnder to update properly. The driver on "pestillo" seems not to generate problems. Python drivers allow for more powerful functionality than constraints, no idea about these incompatibilities with IK!!! $\endgroup$
    – J. Gomez
    Commented Sep 27, 2016 at 11:37
0
$\begingroup$

Besides looking at the system's console, there isn't any definitive, in-app method of checking for cyclic dependency graph errors.

As far as fixing your rig update delay, you may be able to select your armature, navigate to Properties >> Object >> Relation Extras and try selecting either Extra Object Update or Extra Data Update.

enter image description here

Improve this answer
$\endgroup$
9
  • $\begingroup$ I have tried and, in fact, it looks even worse, with more components out of place. Not sure how do internally those options work, but they seem not to work for this. $\endgroup$
    – J. Gomez
    Commented Sep 26, 2016 at 13:20
  • $\begingroup$ Oh really - interesting. Without looking at the rig I can't really help. Is that top controller meant to go up and down, and those IK-constrained hydraulic parts supposed to scissor-fold as it goes down? Might be something better done with drivers. $\endgroup$
    – Mike Belanger
    Commented Sep 26, 2016 at 13:26
  • $\begingroup$ The model works as you said. The top bone controlles all! In fact, original rigging was without bones, just drivers and so, and worked fine. However, that approach requires some math and makes the model less editable so I tried a bone solution. Not sure why does not update properly.... $\endgroup$
    – J. Gomez
    Commented Sep 26, 2016 at 13:37
  • $\begingroup$ Ah, well you had the right assumption anyways. It's generally good practice to use armatures, because they allow the mesh to be edited independent of the animation. Although an editable configuration is possible with just empties, and it sounds like you had that figured out too. Food for thought: I personally think drivers still have some usability issues, and while you've clearly figured it out, I think the Animation Nodes addon would work well if it supported bones -- for usage cases like yours : github.com/JacquesLucke/animation_nodes/issues/103 $\endgroup$
    – Mike Belanger
    Commented Sep 26, 2016 at 13:56
  • $\begingroup$ Plus, I think a node-based workflow like Animation Nodes allows the user to see, or simply avoid circular dependencies,to get back to your original question. $\endgroup$
    – Mike Belanger
    Commented Sep 26, 2016 at 13:58

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .