I’m working on updating a character rig that works in blender 2.76. The foot roll control bone has drivers on it’s location based on the rotation of the bone. The end result of this is as the bone is rotated upwards, it pivots on the root of the bone. When rotated downwards the bone’s root location changes to make it appear like the bone is rotating at the tip of the bone.
This driver set up works fine in blender 2.76, but it’s causing a cyclic dependency error in 3.1.2 - yeah I need to upgrade blender - but that’s not the problem.
I’ve created a file with a driver on the Y-axis of the bone duplicating the problem… please see the attached file. How to overcome the cyclic dependency problem?
Dependencies changed hugely at 2.80. I would say they got much improved, but I guess it’s not impossible that it was two steps forward, one step back.
I would sandwich in a new child for the bone (duplicate it, parent duplicate to original, reparent children of original to duplicate) and then leave the driver only on the duplicate, not the original. Optionally, move the duplicate to another layer and/or give it transform locks so you don’t mess with it.
Thanks for suggestions @bandages - but I’ll keep looking to getting this to working as-is for now
Thanks @cmto - indeed that doesn’t give any dependency warnings and it works - mostly.
That solution works but it is a little bit jittery. The bone lags slightly when rotated, almost like the calculations are taking too long for blender - see attached file. When rotating the bone around quickly, it bounces quite a bit. Not really a deal breaker, but an area for improvement if possible. Any ideas?
Also, when resetting rotation, the bone doesn’t return to it’s original location, but maybe it acted that way in 2.76 too. I’ll have to check that the next I’m on my older computer…
It’s a dependency loop, even though it doesn’t say it’s a dependency loop. That happens sometimes, dunno why.
What I suggested earlier isn’t quite right, because it would change the local space of the bone. Here’s a (3.3.0) file demonstrating what I would do-- again, by separating control from deform, by adding in another bone:
Here, I’m using its rotation to drive the location of a different bone, and then copying world space rotation to that bone. In a real life situation, both bones should have the same parent.
TBH, I was in a hurry when I made my last file and didn’t really get to test it very well. I was hopeful that it could be improved somehow, but it just didn’t feel right…
I looked at your file, but that’s not what I am after. The bone I’m having problems with is the controller bone. When rotated clockwise, it pivots at the root of the bone. When rotated counter-clockwise, it pivots at the tip of the bone.
I was hoping to get this fixed easily, without having to preform major orthopedic surgery on the character…
@bandages I don’t mean to argue about this and I think there is a misunderstanding here.
In my case, I am only talking about the control bone. The heel roll control bone changes it’s pivot point from tip to tail depending upon it’s rotation. The deform bones have nothing to do with it. In your example file, the bone ‘Bone.001’ changes it’s pivot point like I want it to, but now it is being controlled by another bone. I wanted the controller bone to change it’s pivot point on it’s own.
I could use your example and do a quick fix of this rig by adding in a new controller bone to drive the old controller bone like your example shows. But I didn’t do that. Instead I used a setup like rigify uses. Took some time to get it working, and then this caused other problems with the toes, which took more time to figure out. So I wasted a lot of time on this, but at the same time it wasn’t a waste because it helped me re-learn parts of rigging in blender.
I’m thinking about reporting this as a bug and see what happens. Maybe this was something that was missed in the 2.8 overhaul, or maybe it’s something that can’t work because of the overhaul…
