This is my first post here so I’m probably going to get a few things wrong, but I’m having an issue with the Child Of Constraint, I’ve noticed a one frame delay when it comes to the bones updating positions in the viewport, and I’ve been told that this is the result of a Dependency Cycle, and the console says as much. What’s confusing about it is that it doesn’t seem like that error should apply, because it’s chiefly occurring with IK endpoint bones that aren’t parented to anything, and only have one of their Constraints active at any time. (Apologies for the crude console upload, I couldn’t find any tips on how to export and upload the results through text, besides copy pasting)
The primary culprit, the right hand, has been parented to a handful of other bones and rigs but none of them have been left active, I sometimes use a Child Of constraint to parent it to the spine so it can move with the body, but I /must/ stress that the hand IK /is not/ parented to the spine ordinarily, so I don’t see how a dependency cycle could emerge from that.
(Quick note that the ‘knife’ constraint on top isn’t the hand being parented to an object that it’s holding, but rather a sheath hilt for easy animation, which again, the hand should not be, and is not parented to. Including the ‘handoffs’ where the influence switches between the knife hilt and the spine constraints.)
Can I see the bone armature structure with names overlay, a screenshot ofc? The alt hand I think is the problem with some constraint assignment. Dependency cycles happen because a bone is parented to a controller that is also driving the child with a contraint or the other way around. (That the controller is parented to the bone that is constraining for example with a ik constraint setup)
Sorry if I misunderstand, I assume you mean the armature tree in the Outliner, his rig has a TON of bones, so I tried to keep it trimmed down to the relevant bits, (alt_IK_R was at the bottom of the list, but still unparented with the rest of the IKs)
Unfortunately, it doesn’t matter if a bone has a constraint enabled or not-- it still creates a dependency, with everything that results from that.
If you want a reason why this is, consider that enabling a constraint can be driven by something like the position of a bone, and it can take a noticeable chunk of time to recalculate dependencies, leading to weird, stuttery motion of the driving bone when posing it. It’s not necessarily a great reason for why this happens, but it’s at least a reason.
I suppose I understand that, but like you said it’s not /really/ a great reason for this kind of thing to be happening, since Blender doesn’t seem to have much of anything else in the way of a dynamic Parent/Child system, especially compared to SFM’s lock system.
So, is there a workaround or a way to circumvent this? Because if not that seems a pretty substantial issue as far as animation goes, for a 20+ year old program no less.
Thank you! Now, last question, can I import my pre-existing Child Of Constraints and their Set Inverses to the addon after I install it or do I have to do those over again?
The typical way to handle this is with scripting. It’s essentially the same problem people encounter when making IK switches. There can be individual fixes that don’t involve scripting, ways to rework hierarchies so that there is no dependency, but those solutions depend on the exact thing being done (and aren’t always possible, it just depends.) I haven’t examined your hierarchy, there is no file so the hierarchy alone would probably be useless, but even given a file, I’m probably not inclined to figure out how it works until you figure out how it works and simplify it for me, so I can’t tell you what you could do in this particular case.
I know it’s always frustrating when things don’t work how we’d like, but you have to keep in mind that 1) Blender is open source and free and 2) For many of those 20 years, Blender wasn’t a real contender for anything anyways. Nowadays, Blender is a real contender for a lot of things, but it kind of tries to do everything (modelling, animation incl. nodes animation, texturing, sculpting, VSE, compositing, probably more that I never noticed) and that’s a fat list of goals for even commercial software, even though Blender is primarily relying on volunteer contributions. Nobody minds if you prefer some other software that handles this to your liking and use it instead.
Also, to the other point, I don’t believe a program is exempt from criticism purely because it’s free, especially if, in this case, a vastly inferior program has developed a significantly simpler solution to this issue over 15 years ago; And I doubly believe that a blanket response of ‘use another program’ is a reductive approach to an issue that simply will not be solved through migration.
It’s not immune to criticism. You can criticize to your heart’s content, nobody can stop you. Just be aware that your criticism amounts to, Nobody volunteered to write code to do what I want. That should never, ever be a surprise, should never be anything other than what is expected; we don’t expect people to just show up and mow our lawns. The surprising thing is not that they failed to make this feature in their spare time, but that they succeeded in making so much else and just gave it to us. It’s like they washed our car for nothing but failed to mow our lawns for nothing. I’ve made that complaint in the past, several times, in several different contexts, but in hindsight, I feel kind of bad about it.
