Very strange constraint jiggling not present in blender 3.6.3 #115915

New Issue

michael campbell · 2023-12-07T22:23:27+01:00

michael campbell commented

2023-12-07 22:23:27 +01:00

System Information
Operating system: Windows-10-10.0.19045-SP0 64 Bits
Graphics card: NVIDIA GeForce GTX 1070/PCIe/SSE2 NVIDIA Corporation 4.6.0 NVIDIA 537.58

Blender Version
Broken: version: 4.1.0 Alpha, branch: main, commit date: 2023-11-25 22:37, hash: 1b6cd937ffc8
Worked: (3.63)

Caused by 6b872079fe

Short description of error
rig jiggles in 4.1alpha, but copy/pasting it into 3.6.3 works fine

Exact steps for others to reproduce the error
open below blend files in the blender version the filename indicates
play back in both.
4.1alpha jiggles

I noticed this whilst updating a 3.63 course to 4.1 by following along in the newer version. The rig was created in 4.1 and then copy/pasted into 3.63. When I originally created the same rig in blender 3.63 last year, the jiggle problem wasn't there either.

Perhaps this is a bug introduced by the recent bug fix that prevented inactive constraints from causing circular dependancies? (I think I heard it mentioned on one of the live streams).

**System Information** Operating system: Windows-10-10.0.19045-SP0 64 Bits Graphics card: NVIDIA GeForce GTX 1070/PCIe/SSE2 NVIDIA Corporation 4.6.0 NVIDIA 537.58 **Blender Version** Broken: version: 4.1.0 Alpha, branch: main, commit date: 2023-11-25 22:37, hash: `1b6cd937ffc8` Worked: (3.63) Caused by 6b872079fec9336865638ad9cfa76e37e8e627c5 **Short description of error** rig jiggles in 4.1alpha, but copy/pasting it into 3.6.3 works fine **Exact steps for others to reproduce the error** open below blend files in the blender version the filename indicates play back in both. 4.1alpha jiggles I noticed this whilst updating a 3.63 course to 4.1 by following along in the newer version. The rig was created in 4.1 and then copy/pasted into 3.63. When I originally created the same rig in blender 3.63 last year, the jiggle problem wasn't there either. Perhaps this is a bug introduced by the recent bug fix that prevented inactive constraints from causing circular dependancies? (I think I heard it mentioned on one of the live streams).

blender 4.1alpha jiggles.blend

1.1 MiB

blender 3.6.3.blend

1.2 MiB

michael campbell added the

labels 2023-12-07 22:23:28 +01:00

michael campbell commented

2023-12-07 22:29:26 +01:00

See video below. right is 4.1. Very jiggly hands throughout the animation, and then incorrect placement on first frame. Neither issue present in 3.63

2023-12-07 21-27-16.mp4

15 MiB

michael campbell commented

2023-12-07 22:33:11 +01:00

there are no circular dependencies reported, and it only affects the bone overlays. The geometry that's parented to the bones aren't jiggling thankfully.

Iliya Katushenock commented

2023-12-08 09:45:01 +01:00

Can confirm but haven't deep into bissect/regression fact.

Christoph Lendenfeld commented

2023-12-08 09:57:08 +01:00

This behavior also appears in 4.0
and I am pretty sure it was caused by 0c2afa7c17
Interestingly it works the other way, as in running the hand in IK causes no dependency cycles

This behavior also appears in 4.0 and I am pretty sure it was caused by 0c2afa7c17 Interestingly it works the other way, as in running the hand in IK causes no dependency cycles

Philipp Oeser commented

2023-12-08 09:57:19 +01:00

Can confirm, will check

Philipp Oeser added

and removed

labels 2023-12-08 09:58:09 +01:00

Philipp Oeser commented

2023-12-08 10:57:37 +01:00

and I am pretty sure it was caused by 0c2afa7c17

Seems this was already broken in 30de3d7c1a

> and I am pretty sure it was caused by 0c2afa7c17 Seems this was already broken in 30de3d7c1a79

Philipp Oeser commented

2023-12-08 10:58:39 +01:00

Cant check further atm. since opening the file with 65f91bd53a or below will render the armature invisible?!

Cant check further atm. since opening the file with 65f91bd53a4d or below will render the armature invisible?!

👍 1

Philipp Oeser commented

2023-12-08 11:04:15 +01:00

For some reason, this also does not trigger with a lite build

For some reason, this also does not trigger with a `lite` build

👍 1

Philipp Oeser commented

2023-12-08 11:15:29 +01:00

Cant check further atm. since opening the file with 65f91bd53a or below will render the armature invisible?!

Ah, some sort of issue with the bone layers refactor (layers are not set for any of the bones -- this can be enabled again and I can bisect further)

> Cant check further atm. since opening the file with 65f91bd53a4d or below will render the armature invisible?! Ah, some sort of issue with the bone layers refactor (layers are not set for any of the bones -- this can be enabled again and I can bisect further)

🎉 1

Philipp Oeser commented

2023-12-08 12:43:50 +01:00

Caused by 6b872079fe

I havent read through all of #88752 (yet), @nathanvegdahl : mind checking?

Caused by 6b872079fec9336865638ad9cfa76e37e8e627c5 I havent read through all of #88752 (yet), @nathanvegdahl : mind checking?

Philipp Oeser changed title from ~~Very strange constraint jiggling not present in blender 3.6.3~~ to Very strange constraint jiggling not present in blender 3.6.3 (overlapping IK)

2023-12-08 12:44:21 +01:00

Philipp Oeser changed title from ~~Very strange constraint jiggling not present in blender 3.6.3 (overlapping IK)~~ to Very strange constraint jiggling not present in blender 3.6.3

2023-12-08 12:51:55 +01:00

Nathan Vegdahl commented

2023-12-08 15:32:10 +01:00

I've added it to my todo.

Having said that, @brecht might have more insight here. I don't really have a good handle on the IK code, and the fix I committed that apparently caused this was largely thanks to him figuring it out. (I don't mean that as any kind of blame for this bug, of course. Just acknowledging my lack of expertise.)

I've added it to my todo. Having said that, @brecht might have more insight here. I don't really have a good handle on the IK code, and the fix I committed that apparently caused this was largely thanks to him figuring it out. (I don't mean that as any kind of blame for this bug, of course. Just acknowledging my lack of expertise.)

Nathan Vegdahl commented

2023-12-14 11:49:19 +01:00

Some additional information, discovered while trying to create a minimal repro case:

There is a cyclic constraint chain in the provided repro files:

forearm.L/R has an IK constraint with ik right hand.L/R as the target.
ik right hand.L/R has a Copy Location constraint with forearm.L/R as the target.

The IK constraints are disabled in the file, but nevertheless present. Removing the disabled IK constraints resolves the issue.

If I recall correctly, cyclic constraint dependencies aren't supported even if one of the constraints in the cycle is disabled. For example, it's trivial to create issues by making two bones with Copy Location constraints to each other, even if one of them is disabled. However, in that case the cyclic dependency is reported in the terminal.

So I'm thinking the bug here may simply be that the cyclic dependency isn't reported, rather than the apparent jiggly misbehavior.

Some additional information, discovered while trying to create a minimal repro case: There is a cyclic constraint chain in the provided repro files: - `forearm.L/R` has an IK constraint with `ik right hand.L/R` as the target. - `ik right hand.L/R` has a Copy Location constraint with `forearm.L/R` as the target. The IK constraints are disabled in the file, but nevertheless present. Removing the disabled IK constraints resolves the issue. If I recall correctly, cyclic constraint dependencies aren't supported even if one of the constraints in the cycle is disabled. For example, it's trivial to create issues by making two bones with Copy Location constraints to each other, even if one of them is disabled. However, in that case the cyclic dependency is reported in the terminal. So I'm thinking the bug here may simply be that the cyclic dependency isn't reported, rather than the apparent jiggly misbehavior.

michael campbell commented

2023-12-14 13:02:14 +01:00

@nathanvegdahl Any idea why this rig has worked fine in previous Blender versions? Only reason I ask is that I've just spent 2 years creating an animation course based on this rig, everything was fine until testing in 4.1 (didn't test in 4.0)

Nathan Vegdahl commented

2023-12-15 11:45:59 +01:00

@3di

Edit: sorry, just to make this clear: I haven't finished investigating this, so this is what I think is going on.

Any idea why this rig has worked fine in previous Blender versions?

In a word, coincidence. When it comes to dependency cycles in a rig, there's no guarantee that they won't behave the way you want nor any guarantee that they will. It's just unsupported, and considered an invalid rig configuration (a little bit like undefined behavior in C/C++ if you're familiar with that). Blender is supposed to catch those cycles and report them, so that users don't end up with invalid rig configurations. But for some reason it didn't in this case. And that is (I think) the actual bug here: it didn't inform you that your rig, although seemingly working, was actually broken to begin with.

Here's a blend file with a much simpler setup that demonstrates the same jiggly behavior: two bones with copy location constraints to each other, with one of those constraints disabled:

cyclic_dependency_with_disabled_constraint.blend

In this case the cyclic dependency is properly reported. (Admittedly, this reporting could and probably should be directly in the user interface to make it obvious, but it's at least reported in the console if you open Blender from a console.)

Some more detail:

IK constraints are different than the other constraints in Blender because they are cooperative on the whole armature. Most constraints just operate on a single bone/object, and are independent of the other constraints in the scene/armature. But the IK constraints that you create as a user are more like markers on the armature, which then serve as the input to a single IK solve on the whole armature at once. This is what allows e.g. branching tree IK to work, among other things.

Because of that, there's a lot more room for bugs to slip in, being a significantly more complex situation than most constraints in Blender. In this case, there was a bug (#88752) where some parts of the IK system were being erroneously ignored by the IK solver, even though they were part of the dependency graph. This resulted in some really nasty jumping-around behavior in certain IK setups.

Part of fixing that bug was slightly tweaking how IK is evaluated in certain situations. This tweak didn't affect valid setups (aside from those we were fixing), but it seems it did affect setups with cyclic dependencies, such as your rig.

Only reason I ask is that I've just spent 2 years creating an animation course based on this rig, everything was fine until testing in 4.1.

Damn, that really sucks. I honestly feel for you.

I'm not sure what we can do on the coding side about this for you. But perhaps it's possible to change your rig to use a valid setup, in a relatively non-disruptive way, that requires re-recording as little as possible?

You could hop on #blender-riggers on blender.chat, and we could try to help you figure out an alternative rig set up there. There's also BlenderArtists, and you could perhaps get some help there.

You could also perhaps specify in your course a maximum Blender version before the relevant fix was introduced, and explain the situation.

@3di Edit: sorry, just to make this clear: I haven't finished investigating this, so this is what I *think* is going on. > Any idea why this rig has worked fine in previous Blender versions? In a word, coincidence. When it comes to dependency cycles in a rig, there's no guarantee that they won't behave the way you want nor any guarantee that they will. It's just unsupported, and considered an invalid rig configuration (a little bit like undefined behavior in C/C++ if you're familiar with that). Blender is supposed to catch those cycles and report them, so that users don't end up with invalid rig configurations. But for some reason it didn't in this case. And that is (I think) the actual bug here: it didn't inform you that your rig, although seemingly working, was actually broken to begin with. Here's a blend file with a much simpler setup that demonstrates the same jiggly behavior: two bones with copy location constraints to each other, with one of those constraints disabled: [cyclic_dependency_with_disabled_constraint.blend](/attachments/44118df9-ef4f-4a0a-b1e0-dd2952bd3c46) In this case the cyclic dependency is properly reported. (Admittedly, this reporting could and probably should be directly in the user interface to make it obvious, but it's at least reported in the console if you open Blender from a console.) Some more detail: IK constraints are different than the other constraints in Blender because they are *cooperative* on the whole armature. Most constraints just operate on a single bone/object, and are independent of the other constraints in the scene/armature. But the IK constraints that you create as a user are more like markers on the armature, which then serve as the input to a single IK solve on the whole armature at once. This is what allows e.g. branching tree IK to work, among other things. Because of that, there's a lot more room for bugs to slip in, being a significantly more complex situation than most constraints in Blender. In this case, there was a bug (#88752) where some parts of the IK system were being erroneously ignored by the IK solver, even though they were part of the dependency graph. This resulted in some really nasty jumping-around behavior in certain IK setups. Part of fixing that bug was slightly tweaking how IK is evaluated in certain situations. This tweak didn't affect valid setups (aside from those we were fixing), but it seems it did affect setups with cyclic dependencies, such as your rig. > Only reason I ask is that I've just spent 2 years creating an animation course based on this rig, everything was fine until testing in 4.1. Damn, that *really* sucks. I honestly feel for you. I'm not sure what we can do on the coding side about this for you. But perhaps it's possible to change your rig to use a valid setup, in a relatively non-disruptive way, that requires re-recording as little as possible? You could hop on #blender-riggers on blender.chat, and we could try to help you figure out an alternative rig set up there. There's also BlenderArtists, and you could perhaps get some help there. You could also perhaps specify in your course a maximum Blender version before the relevant fix was introduced, and explain the situation.

cyclic_dependency_with_disabled_constraint.blend

867 KiB

michael campbell commented

2023-12-15 12:00:11 +01:00

Thanks for the detailed response. Wouldn't be possible to re-record the whole course as it's taken 2 years to make, and is around 30 hours of video. The editing for Blender 4.1 has taken 3 months alone! Perhaps when I re-record for Blender 5's new animation system I'll modify the rig. It's not too big of a deal because the bone is never used for parenting, the copy location constraint is just to make sure the IK hands are easy to find and rotate in FK mode, because they still control rotation of the actual hand bone.

Do you think blender will ever respect whether or not bone constraints are disabled, so that rigs that dynamically enable/disable constraints can work properly (as if the disabled one's weren't there)?

Thanks for the detailed response. Wouldn't be possible to re-record the whole course as it's taken 2 years to make, and is around 30 hours of video. The editing for Blender 4.1 has taken 3 months alone! Perhaps when I re-record for Blender 5's new animation system I'll modify the rig. It's not too big of a deal because the bone is never used for parenting, the copy location constraint is just to make sure the IK hands are easy to find and rotate in FK mode, because they still control rotation of the actual hand bone. Do you think blender will ever respect whether or not bone constraints are disabled, so that rigs that dynamically enable/disable constraints can work properly (as if the disabled one's weren't there)?

Nathan Vegdahl commented

2023-12-15 17:02:41 +01:00

Some notes from further investigation:

As far as I can tell from looking at the actually constructed dependency graph (via the Dependency Graph Debug addon), it's not clear to me why there's a jiggle here. There is still conceptually a cyclic dependency here, which I believe still makes this rig setup invalid and unsupported. However, the dependency graph is constructed such that the Copy Location constraint of ik right hand.L/R only depends on the pre-IK transform of forearm.L/R, not the post-IK position. So in theory this set up should still work in current Blender (albeit coincidentally, and not supported).

So there may still be something going on here (beyond just not detecting some dependency cycles) that deserves attention. Not sure.

Do you think blender will ever respect whether or not bone constraints are disabled, so that rigs that dynamically enable/disable constraints can work properly (as if the disabled one's weren't there)?

There are tentative plans in the future to add some kind of rigging node system, which would allow the user to have full control over rig evaluation. Such as system would allow this and many other setups that would normally create dependency cycles to be valid, ableit with a bit more work from the rigger.

Some notes from further investigation: As far as I can tell from looking at the actually constructed dependency graph (via the Dependency Graph Debug addon), it's not clear to me why there's a jiggle here. There is still *conceptually* a cyclic dependency here, which I believe still makes this rig setup invalid and unsupported. However, the dependency graph is constructed such that the Copy Location constraint of `ik right hand.L/R` only depends on the *pre*-IK transform of `forearm.L/R`, not the post-IK position. So in theory this set up should still work in current Blender (albeit coincidentally, and not supported). So there may still be something going on here (beyond just not detecting some dependency cycles) that deserves attention. Not sure. > Do you think blender will ever respect whether or not bone constraints are disabled, so that rigs that dynamically enable/disable constraints can work properly (as if the disabled one's weren't there)? There are tentative plans in the future to add some kind of rigging node system, which would allow the user to have full control over rig evaluation. Such as system would allow this and many other setups that would normally create dependency cycles to be valid, ableit with a bit more work from the rigger.

👍 1

Sybren A. Stüvel commented

2024-01-09 16:17:29 +01:00

For future bug reports, please take some time to mimize the example blend file. In this case, there are bone shapes and many bones that are irrlelevant to this particular issue. The Armature contains bone collections that are hidden, which contain more bones that are again irrelevant, yet they are even animated. These things add up, unfortunately, and make it considerably slower to investigate in detail. From the description, it seems that this situation should be reproducible with only a handful of bones (pun very much intended).

To illustrate, here is the resulting dependency graph of the attached example file:

As far as I can tell from looking at the actually constructed dependency graph (via the Dependency Graph Debug addon), it's not clear to me why there's a jiggle here. There is still conceptually a cyclic dependency here, which I believe still makes this rig setup invalid and unsupported. However, the dependency graph is constructed such that the Copy Location constraint of ik right hand.L/R only depends on the pre-IK transform of forearm.L/R, not the post-IK position. So in theory this set up should still work in current Blender (albeit coincidentally, and not supported).

I don't share the "not supported" conclusion here, I think we can investigate further on the Blender side.

For future bug reports, please take some time to mimize the example blend file. In this case, there are bone shapes and many bones that are irrlelevant to this particular issue. The Armature contains bone collections that are hidden, which contain more bones that are again irrelevant, yet they are even animated. These things add up, unfortunately, and make it considerably slower to investigate in detail. From the description, it seems that this situation should be reproducible with only a handful of bones (pun very much intended). To illustrate, here is the resulting dependency graph of the attached example file: ![depsgraph.svg](/attachments/cf7179d2-0806-4e9d-bae1-ba6e07e21419) > As far as I can tell from looking at the actually constructed dependency graph (via the Dependency Graph Debug addon), it's not clear to me why there's a jiggle here. There is still *conceptually* a cyclic dependency here, which I believe still makes this rig setup invalid and unsupported. However, the dependency graph is constructed such that the Copy Location constraint of `ik right hand.L/R` only depends on the *pre*-IK transform of `forearm.L/R`, not the post-IK position. So in theory this set up should still work in current Blender (albeit coincidentally, and not supported). I don't share the "not supported" conclusion here, I think we can investigate further on the Blender side.

depsgraph.svg

885 KiB

👍 1

michael campbell commented

2024-01-09 17:31:21 +01:00

Will do, thanks. I guess what needs to happen is that constraints which are turned off should be treated as not there. Easier said than done I'm sure. It's not a massive issue in this case, because the copy location is there only to ensure the IK bone remains in place when the arm is in FK mode because it's still used for rotating the hand bone. It also saves having to use your copy global transform addon to re-position the IK hand each time the arm changes from FK to IK.

Sybren A. Stüvel commented

2024-01-09 17:58:46 +01:00

Blender's current behaviour has the advantage that 'influence = 0%' and 'turned off' have the same result, and gradually increasing the influence produces smooth motion. Unfortunately this is only possible when the mere existence of the IK constraint already influences the bone.

Still, there's something to be said for the "a disabled constraint should be have as if it does not exist" view on this, as it opens up interesting possibilities for riggers. I'll investigate Brecht's alternative approach he mentioned in #88752 (comment)

Blender's current behaviour has the advantage that 'influence = 0%' and 'turned off' have the same result, and gradually increasing the influence produces smooth motion. Unfortunately this is only possible when the mere existence of the IK constraint already influences the bone. Still, there's something to be said for the "a disabled constraint should be have as if it does not exist" view on this, as it opens up interesting possibilities for riggers. I'll investigate Brecht's alternative approach he mentioned in https://projects.blender.org/blender/blender/issues/88752#issuecomment-972531

👍 1

Sybren A. Stüvel self-assigned this 2024-01-09 17:58:54 +01:00

michael campbell commented

2024-01-09 18:07:51 +01:00

That would be awesome, 0 influence and disabled constraints being treated as 'not there' for individual frames would make rigging waaaaay easier, saving riggers from the need to create extremely complex rigs with duplicate arms etc just to avoid the problems caused by disabled constraints causing dependency loops.

Nathan Vegdahl commented

2024-01-11 10:16:51 +01:00

@dr.sybren

I don't share the "not supported" conclusion here, I think we can investigate further on the Blender side.

As you pointed out in our in-person discussion, as long as the enabled/disabled states aren't animated then indeed this seems like something we can support.

However, I'm now recalling that part of what brought me to the "not supported" conclusion is that the enabled/disabled states of the relevant constraints here are (as far as I can tell) effectively serving as an IK/FK switch. And typically IK/FK switching is intended to be animatable.

As long as the intention with this rig is to only ever be in one state or the other for an entire shot, and never animate between the two, then that should be fine. But it's not clear to me that we can support this kind of setup having its IK/FK switches animated, within Blender's current constraint system.

@3di

would make rigging waaaaay easier, saving riggers from the need to create extremely complex rigs with duplicate arms etc just to avoid the problems caused by disabled constraints causing dependency loops.

Just a note from my own experience as a rigger and animator: avoiding dependency loops isn't actually the primary reason for the duplicate-arm setup, at least not in the rigs that I've built. The main reasons are:

To allow animators to more easily manage the transition between IK and FK at the switch-over point. I won't go into the details here, but you can run into some annoying situations as an animator if you don't have separate access to and separate control over the FK and IK controls. (At least, with Blender's current animation/rigging system. Rethinking how these things work more radically could change that in the future, but that's not relevant to Blender right now.)
To make the IK solve predictable. Blender's IK solver starts its solve from the current FK pose, which is really powerful and a huge boon in many situations, but if you share the same bone chain for both IK and FK, that means that when the animator manipulates the FK controls it can alter the IK solve in surprising ways. (There are almost certainly ways around this with a single-chain setup as well, but that would likely introduce similar complexity as the duplicate setup anyway.)

The duplicate setup does additionally have the benefit of avoiding dependency cycles, of course. But I would use it in my rigs even if dependency cycles weren't an issue.

@dr.sybren > I don't share the "not supported" conclusion here, I think we can investigate further on the Blender side. As you pointed out in our in-person discussion, as long as the enabled/disabled states aren't animated then indeed this seems like something we can support. However, I'm now recalling that part of what brought me to the "not supported" conclusion is that the enabled/disabled states of the relevant constraints here are (as far as I can tell) effectively serving as an IK/FK switch. And typically IK/FK switching is intended to be animatable. As long as the intention with this rig is to *only ever be in one state or the other* for an entire shot, and never animate between the two, then that should be fine. But it's not clear to me that we can support this kind of setup having its IK/FK switches animated, within Blender's current constraint system. @3di > would make rigging waaaaay easier, saving riggers from the need to create extremely complex rigs with duplicate arms etc just to avoid the problems caused by disabled constraints causing dependency loops. Just a note from my own experience as a rigger and animator: avoiding dependency loops isn't actually the primary reason for the duplicate-arm setup, at least not in the rigs that I've built. The main reasons are: 1. To allow animators to more easily manage the transition between IK and FK at the switch-over point. I won't go into the details here, but you can run into some annoying situations as an animator if you don't have separate access to and separate control over the FK and IK controls. (At least, with Blender's current animation/rigging system. Rethinking how these things work more radically could change that in the future, but that's not relevant to Blender right now.) 2. To make the IK solve predictable. Blender's IK solver starts its solve from the current FK pose, which is really powerful and a huge boon in many situations, but if you share the same bone chain for both IK and FK, that means that when the animator manipulates the FK controls it can alter the IK solve in surprising ways. (There are almost certainly ways around this with a single-chain setup as well, but that would likely introduce similar complexity as the duplicate setup anyway.) The duplicate setup does additionally have the benefit of avoiding dependency cycles, of course. But I would use it in my rigs even if dependency cycles weren't an issue.

michael campbell commented

2024-01-11 15:03:59 +01:00

Yes, treating the zero influence and enabled/disabled state as 'not there' would need to happen on a frame by frame basis during animation for it to be useful. There are a few unpredictable annoyances during the switch and the keyframed position not matching what's shown in the viewport, but I find there are ways to easily overcome those without the added complexity of separate limbs for FK/IK. I'm just on the verge of releasing a course which touches on those problems, 3 years in the making 🥂 Holiday needed! :)

Nathan Vegdahl commented

2024-01-15 15:12:25 +01:00

I've created a minimal repro file:
minimal_repro.blend

I think even more bones can be deleted, and it still exhibits the issue, but it becomes subtle/occasional and harder to see. This is the fewest bones I could get it down to that still obviously exhibits the issue right off the bat.

I've created a minimal repro file: [minimal_repro.blend](/attachments/9375ba2e-ca93-4fec-8c81-7d2628adca27) I think even more bones can be deleted, and it still exhibits the issue, but it becomes subtle/occasional and harder to see. This is the fewest bones I could get it down to that still obviously exhibits the issue right off the bat.

minimal_repro.blend

1.0 MiB

Sybren A. Stüvel referenced this issue

2024-01-16 17:42:14 +01:00

WIP: IK: distinguish 'off' from '0% influence' in IK constraints #117178

Sybren A. Stüvel added

and removed

labels 2024-02-09 12:16:27 +01:00

Sybren A. Stüvel commented

2024-02-09 12:25:43 +01:00

Lowered priority as discussed in yesterday's Animation & Rigging meeting notes.

Lowered priority as discussed in [yesterday's Animation & Rigging meeting notes](https://devtalk.blender.org/t/2024-02-08-animation-rigging-module-meeting/33297).

michael campbell commented

2024-02-09 17:39:06 +01:00

Thanks for trying 👍

Sign in to join this conversation.

No Label

Download

What's New

Blender Studio

Manual

Developers Blog

Documentation

Benchmark

Blender Conference

Development Fund

One-time Donations

Very strange constraint jiggling not present in blender 3.6.3 #115915