Separate bone constraints calculations to before-IK and after-IK parts (more like a multipass constraint concept now) #39962

New Issue

Fazekas Laszlo · 2014-04-30T08:16:55+02:00

Fazekas Laszlo commented

2014-04-30 08:16:55 +02:00

Bone constraints now calculated entirely before the IK solver. I'm trying to write a patch for separating the bone constraints into "before IK" and "after IK" parts but first I'd like to ask the developers which way you prefer:

the backward compatible way: I can add a flagbit to the existing constraint DNA structure, there is empty place in the flags field so this can be fully backward compatible. In this case the GUI headline of the constraint will get a new toggle button so you can select the constraint as before-IK or after-IK. However, this is a bit ugly: these constraints can be in a mixed order and you must switch them one by one.
the nice way: the constraints before the IK constraint will run before IK, and the remainings are after. Of course the middle bones of the IK chain has no IK constraint, so I can add an a new empty "IK placeholder" constraint type to mark the position where the IK calculations separate the two parts. IMHO this is nice, intuitive but not fully backward compatible.
or something else?

Bone constraints now calculated entirely before the IK solver. I'm trying to write a patch for separating the bone constraints into "before IK" and "after IK" parts but first I'd like to ask the developers which way you prefer: - the backward compatible way: I can add a flagbit to the existing constraint DNA structure, there is empty place in the flags field so this can be fully backward compatible. In this case the GUI headline of the constraint will get a new toggle button so you can select the constraint as before-IK or after-IK. However, this is a bit ugly: these constraints can be in a mixed order and you must switch them one by one. - the nice way: the constraints before the IK constraint will run before IK, and the remainings are after. Of course the middle bones of the IK chain has no IK constraint, so I can add an a new empty "IK placeholder" constraint type to mark the position where the IK calculations separate the two parts. IMHO this is nice, intuitive but not fully backward compatible. - or something else?

Fazekas Laszlo commented

2014-04-30 08:16:55 +02:00

Changed status to: 'Open'

Fazekas Laszlo commented

2014-04-30 08:16:55 +02:00

Added subscriber: @totoro-4

Joshua Leung commented

2014-04-30 16:36:12 +02:00

Added subscriber: @JoshuaLeung

Joshua Leung commented

2014-04-30 16:36:12 +02:00

I guess I should comment a bit on this as the maintainer of this area.

Firstly, I think you need to be aware that this part of the code is something that is slated for some radical changes in the depsgraph refactor. Therefore, it is unlikely that any changes here will be accepted to the main repo before then. You are of course free to tinker with this (that's the beauty of open source :) though

One of the things I wonder a bit with this is what the intended use cases of this are. For instance, when would it be useful that some constraints are able to run after/on top of the IK results, perhaps in the middle of the IK chain even? What would be the implications of this on the final result, given that some constraints may have made the original IK solution point to the wrong places now?

Regarding your original questions:

I don't think this necessarily needs to be an "either or" situation. For example, one way this could work is that you would have a new flag that goes on the IK constraints to say whether they should be evaluated after the stack (i.e. when flag is not set => backwards compatability for old files) vs "in place" (i.e. when the flag is set => perhaps the default for new files, if this makes sense that is).
You may be interested to know that we have a "null" constraint type. This basically does nothing, and is used to represent any constraint a version of Blender knows nothing about (e.g. if the constraint came from a newer version). While versions from 2.5 onwards don't show this anymore, it has always existed in the codebase.

Hopefully this doesn't come off sounding too harsh :)

I guess I should comment a bit on this as the maintainer of this area. Firstly, I think you need to be aware that this part of the code is something that is slated for some radical changes in the depsgraph refactor. Therefore, it is unlikely that any changes here will be accepted to the main repo before then. You are of course free to tinker with this (that's the beauty of open source :) though One of the things I wonder a bit with this is what the intended use cases of this are. For instance, when would it be useful that some constraints are able to run after/on top of the IK results, perhaps in the middle of the IK chain even? What would be the implications of this on the final result, given that some constraints may have made the original IK solution point to the wrong places now? Regarding your original questions: - I don't think this necessarily needs to be an "either or" situation. For example, one way this could work is that you would have a new flag that goes on the IK constraints to say whether they should be evaluated after the stack (i.e. when flag is not set => backwards compatability for old files) vs "in place" (i.e. when the flag is set => perhaps the default for new files, if this makes sense that is). - You may be interested to know that we have a "null" constraint type. This basically does nothing, and is used to represent any constraint a version of Blender knows nothing about (e.g. if the constraint came from a newer version). While versions from 2.5 onwards don't show this anymore, it has always existed in the codebase. Hopefully this doesn't come off sounding too harsh :)

Joshua Leung self-assigned this 2014-04-30 16:36:57 +02:00

Fazekas Laszlo commented

2014-04-30 20:39:33 +02:00

Hello @JoshuaLeung,

Sometimes I make complex armatures, specially with stretched bones where volume must be preserved or the bone's X/Z scales must not change. In these cases the possibility to modify a bone after the IK calculations could be more than useful. Now the only solution for these to use additional copy bones, just like rigify does. It is not nice, hard to build, hard to modify, hard to debug. And perhaps - I cannot check yet:) - it is slower to calculate in real time.

Currently, if you put a constraint after the IK on the GUI list, it seems it is "after" the IK solver, but really is not. I don't fully understand yet how it works but it seems that all other constraint calculations are done right before the IK solver (in iksolver_execute_tree).

I want to keep this, but finish the BKE_pose_where_is() at the first KINEMATIC constraint/IK marker (I'm talking about my second solution). After calling the IK solver, it goes through the bPoseChannels again, and execute the remaining constraints. I don't see yet what modifications needed in the depsgraph but surely will be some.

The null constraint sounds perfect. I assume it is just a simple bConstraint struct. What is the conventional way to define its sub-type? Is it enough if I set its name- [ ] to something specific like "IK placeholder"?

Hello @JoshuaLeung, Sometimes I make complex armatures, specially with stretched bones where volume must be preserved or the bone's X/Z scales must not change. In these cases the possibility to modify a bone after the IK calculations could be more than useful. Now the only solution for these to use additional copy bones, just like rigify does. It is not nice, hard to build, hard to modify, hard to debug. And perhaps - I cannot check yet:) - it is slower to calculate in real time. Currently, if you put a constraint after the IK on the GUI list, it seems it is "after" the IK solver, but really is not. I don't fully understand yet how it works but it seems that all other constraint calculations are done right before the IK solver (in iksolver_execute_tree). I want to keep this, but finish the BKE_pose_where_is() at the first KINEMATIC constraint/IK marker (I'm talking about my second solution). After calling the IK solver, it goes through the bPoseChannels again, and execute the remaining constraints. I don't see yet what modifications needed in the depsgraph but surely will be some. The null constraint sounds perfect. I assume it is just a simple bConstraint struct. What is the conventional way to define its sub-type? Is it enough if I set its name- [ ] to something specific like "IK placeholder"?

Joshua Leung commented

2014-05-01 01:12:45 +02:00

Regarding the depsgraph:
The plan is that we're going to break up the hardcoded/monolithic pose eval code with a network of operation nodes. Bone transforms, individual constraints, IK solver steps, and init/cleanup steps for bones/constraint stacks/armature eval will all become separate operation nodes, allowing more possibilities for interleaving the evaluation of bones/constraints with drivers and other objects/geometry.

Regarding null constraints:
For your purposes, I think a name based method will do initially

Regarding the depsgraph: The plan is that we're going to break up the hardcoded/monolithic pose eval code with a network of operation nodes. Bone transforms, individual constraints, IK solver steps, and init/cleanup steps for bones/constraint stacks/armature eval will all become separate operation nodes, allowing more possibilities for interleaving the evaluation of bones/constraints with drivers and other objects/geometry. Regarding null constraints: For your purposes, I think a name based method will do initially

Fazekas Laszlo commented

2014-05-01 06:28:15 +02:00

Aw, the depsgraph sounds good, will it be accessible through the node editor too? Is there already a fork to try?

I decided to make the second method anyway (no flagbit) maybe with some file loader code to rearrange the order of constraints in old files (put the kinematic to the end). This way it remains backward compatible. The separator will listen to the first two characters ('IK') of the null constraint.

Aw, the depsgraph sounds good, will it be accessible through the node editor too? Is there already a fork to try? I decided to make the second method anyway (no flagbit) maybe with some file loader code to rearrange the order of constraints in old files (put the kinematic to the end). This way it remains backward compatible. The separator will listen to the first two characters ('IK') of the null constraint.

Fazekas Laszlo commented

2014-05-02 06:31:13 +02:00

The null constraint is not good (used and filtered at many places in the program) so I've made a new constraint type. Now I have a new concept: the whole thing is not related to IK but it is a general pass separator. The passes can contain separate IK-s too or you can repeat a constraint in the different passes if required. I can't see all the possibilities now, but there are many. The new constraint contains a numeric field to split the constraint calculations into independent passes.

Fazekas Laszlo changed title from ~~Separate bone constraints calculations to before-IK and after-IK parts~~ to Separate bone constraints calculations to before-IK and after-IK parts (more like a multipass constraint concept now)

2014-05-02 06:33:46 +02:00

Fazekas Laszlo commented

2014-05-02 20:03:08 +02:00

Sooo... it is not as easy as I thought. Constraints are often recalculated for individual objects in the code everywhere. This means it is nearly impossible to make a multi-object-multi-pass solution (I don't want a heavy caching for every passes). No sense to make this for objects, only for bones within an armature.

I'm really curious now about the new depsgraph.

Sooo... it is not as easy as I thought. Constraints are often recalculated for individual objects in the code everywhere. This means it is nearly impossible to make a multi-object-multi-pass solution (I don't want a heavy caching for every passes). No sense to make this for objects, only for bones within an armature. I'm really curious now about the new depsgraph.

Fazekas Laszlo commented

2014-05-04 19:29:31 +02:00

This is the first version. I made this as harmless as can be and fully backward compatible with everything.

Basically it is a new constraint type for bones. Always processed after the IK solver and changes only the bone's x and z scaling. Very similar to the maintain volume or stretch to constraints. The bone's head are tail are never changed.

The sample .blend file contains a simple armature modifying a cylinder mesh. You can move the upmost bone as an IK target and the other two bones are using IK with scaling. Try to change the new Post IK constraints at the lower bones to see the difference.

post_ik_constraint.diff

post_ik.blend

This is the first version. I made this as harmless as can be and fully backward compatible with everything. Basically it is a new constraint type for bones. Always processed after the IK solver and changes only the bone's x and z scaling. Very similar to the maintain volume or stretch to constraints. The bone's head are tail are never changed. The sample .blend file contains a simple armature modifying a cylinder mesh. You can move the upmost bone as an IK target and the other two bones are using IK with scaling. Try to change the new Post IK constraints at the lower bones to see the difference. [post_ik_constraint.diff](https://archive.blender.org/developer/F86920/post_ik_constraint.diff) [post_ik.blend](https://archive.blender.org/developer/F86921/post_ik.blend)

Fazekas Laszlo commented

2014-05-04 19:37:14 +02:00

![postik.png](https://archive.blender.org/developer/F86922/postik.png)

Dalai Felinto commented

2019-12-23 18:43:57 +01:00

Added subscriber: @dfelinto

Dalai Felinto commented

2019-12-23 18:43:57 +01:00

Changed status from 'Confirmed' to: 'Archived'

Dalai Felinto closed this issue

2019-12-23 18:43:57 +01:00

Dalai Felinto commented

2019-12-23 18:43:57 +01:00

Hi, thanks for your patch.

We are undergoing a Tracker Curfew where we are automatically closing old patches.

If you think the patch is still relevant please update and re-submit it. For new features make sure there is a clear design from the user level perspective.

Hi, thanks for your patch. We are undergoing a [Tracker Curfew ](https://code.blender.org/?p=3861) where we are automatically closing old patches. If you think the patch is still relevant please update and re-submit it. For new features make sure there is a clear design from the user level perspective.

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

Separate bone constraints calculations to before-IK and after-IK parts (more like a multipass constraint concept now) #39962