2
$\begingroup$

I am trying to make an animation of closing/opening of a Book. For this I'm using bones to control the same. I have added the bones as shown in the image, the closing of the covers are controlled by a controller bone on top. But I have an issue in completing the animation with the constraints.

Process followed to achieve it: (Note: Careful with the naming of the bones, check the image)

  • The bones are parented as shown in the image. And then the Cover.L, Cover.R, edge.LRoll and edge.RRoll , I have added the bone constraint of "Copy Rotation" in the local space. The middle two bones (edge.LRoll and edge.RRoll) take the rotation from the controller and the side two covers take the rotation from their opposite edges (i.e Cover.L takes from edge.RRoll). (I have named the bones in the picture and also represented the parenting with the yellow arrows) enter image description here

  • Basically this should help in coordination of the rotation of the covers with respect to the rotation of the edges, when the controller is rotated. Now I added "Limit Rotation" to the middle edges so that they don't rotate more than 90 degrees in local&World space respectively for R and L edges. Everything works fine till now as constraints for middle edges works well. enter image description here

  • Now I want to constraint the rotation of the Covers from 0-180 degrees in World space and added the same to both the covers.

THE PROBLEM: As I added the constraints of limit rotation to covers, the Cover.L works well in its boundaries, but the Cover.R weirdly flips its direction the moment it nears the 180 degrees. SO I want to fix this issue enter image description here

Here is the constraints I have added (May be useful before opening the blendfile) enter image description here

So, I am unable to understand what is wrong with this. Please guide me how to fix this issue?? Im I doing wrong somewhere? or is it a bug?

WHAT I HAVE TRIED - I have tried limiting the rotation with respect to the local space, changing the limit angles but this doesn't give proper limits. - I saw somewhere that the "roll" of the bones can sometimes cause rotation issues, so I even kept all the rolls to Z axis.

Btw: I am new to the working on Armature, that is the reason I might have been asking very basic issue. I have been following this tut https://www.youtube.com/watch?v=hjZa-h_f5Ts&t=6s

My blend File for further investigation: https://pasteall.org/blend/2b57b74d8746407ba12897f0c5d9559b

Improve this question
$\endgroup$
2
  • $\begingroup$ Issues with rotation around multiples of 90 degrees is most often gimbal lock Do your bones use Euler or Quaternion rotation? $\endgroup$
    – batFINGER
    May 30, 2020 at 9:51
  • $\begingroup$ Hi!! The bones are using Quaternion rotation. Is there any way to fix the issue? $\endgroup$
    – Suhas
    May 30, 2020 at 10:46

2 Answers 2

Reset to default
1
$\begingroup$

After researching this issue, I get the impression that there is something problematic about how Blender calculates rotations internally which makes rotation constraints reset bone values to zero whenever exceeding +/-180 degrees. It turns out that Blender continues calculating rotations even within ranges for which constraints are currently limiting rotations, and that these internal rotation calculations can continue after passing the constraint thresholds. What I find particularly baffling is that unchecking the For Transform checkbox for a Limit Rotation constraint stops "out of bounds" rotation values from being reported in the Transform panel, yet this doesn't actually stop the calculations themselves, which will still go on to create flips when transforming past +/- 180 degrees. This leads me to wonder what changing this setting meaningfully, operationally achieves, because it doesn't do anything to change this insufferable behavior.

I noticed in the video that the author doesn't seem to have your issue. But then again, I don't think he ever rotated the control bone far enough at any point to tell me for sure that his rig wouldn't have done what yours is doing. So it's not clear that his rig would behave differently than yours if pushed past +/- 180 degrees.

Some elsewhere have suggested creating drivers to address this problem, which seems to me like a very labor intensive workaround for something that shouldn't even be a problem. I noticed that the author creates drivers toward the end of the video, and I don't see any drivers in your file. I don't know that adding these drivers would have solved your issue, as I only skimmed the video. But I found it of possible interest that you didn't have any drivers set up before reporting this issue.

I can't find any problems with the rig itself, but I could have missed something. I have found other links to similar questions which either go without answers or explicitly report that there is no solution.

I would really like to see a satisfactory solution presented, personally.

Improve this answer
$\endgroup$
1
  • $\begingroup$ The issue is that Blender uses aliased versions of Euler angles for the copied and limited values. The solution is, don't use limit or copy rotation; use damped track and locked track, or use drivers. See devtalk.blender.org/t/… for a bit of discussion. $\endgroup$
    – Nathan
    Aug 18, 2020 at 23:42
2
$\begingroup$

I solved this problem by making sure both Cover.R and Cover.L had Mix: Offset (Legacy) in the Copy Rotation constraint property. Then, I moved Limit Rotation to the top of the stack (above Copy Rotation) for both.

Improve this answer
$\endgroup$
2
  • $\begingroup$ Thanks. This worked for me too. Do you know why it works? $\endgroup$
    – Frank Riccobono
    Oct 20, 2020 at 22:25
  • $\begingroup$ No idea, unfortunately. $\endgroup$
    – Justin
    Oct 22, 2020 at 13:35

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.