Bake Action inaccurate for Spline IK #52063

New Issue

Adam Janz · 2017-07-15T00:03:04+02:00

Adam Janz commented

2017-07-15 00:03:04 +02:00

System Information
Windows 8.1 64 bit; EVGA GTX 970

Blender Version
Broken: (2.78c e92f235283)
Worked: Unknown

Short description of error

Hi Blender developer team,

I just wanted to report an issue I've discovered regarding baking actions on a rig that uses a Spline IK chain. Firstly, the rig is setup correctly: I have a Control Rig that uses 2 bones as Hooks to control a Bezier Curve; then I have a separate Deform Rig that contains the Spline IK chain which has the Bezier Curve set as its target. All other bones in the Deform Rig have copy transform constraints which point back to their duplicate bones in the Control Rig. This avoids cyclic dependency issues.

However, the deform rig is the one that needs to be exported with all the animation applied for use in another program. This requires baking each action into the deform rig, since the deform rig actually has no animation data of its own. So, for each action in the Control Rig, I would duplicate the Deform Rig, and name it Export Rig. I would then Bake the Action using the following settings:

After the bake, I began to notice a discrepancy in the bone positions of those which had been Spline IK bones. Interestingly, sometimes I could get it to work perfectly, usually by adding a visual keying LocRotScale keyframe first. But sometimes, that didn't work, and Blender had to be closed and re-opened. And sometimes THAT didn't work either, resulting in the final workaround which was manually adding a Visual LocRotScale keyframe for all bones in the Export Rig for EACH frame, and then baking the action (except with the "Overwrite" checkbox selected in the Bake Actions options). Essentially, that last step of baking was probably unneeded, but I did it as a quick way to remove all constraints. You can see the difference below, the selected (blue) rig is the baked one, and in the 2nd picture, you can see the baked and unbaked rigs line up perfectly:

Thanks so much for looking into this.

Sincerely,
Adam Janz

**System Information** Windows 8.1 64 bit; EVGA GTX 970 **Blender Version** Broken: (2.78c e92f235283) Worked: Unknown **Short description of error** Hi Blender developer team, I just wanted to report an issue I've discovered regarding baking actions on a rig that uses a Spline IK chain. Firstly, the rig is setup correctly: I have a Control Rig that uses 2 bones as Hooks to control a Bezier Curve; then I have a separate Deform Rig that contains the Spline IK chain which has the Bezier Curve set as its target. All other bones in the Deform Rig have copy transform constraints which point back to their duplicate bones in the Control Rig. This avoids cyclic dependency issues. However, the deform rig is the one that needs to be exported with all the animation applied for use in another program. This requires baking each action into the deform rig, since the deform rig actually has no animation data of its own. So, for each action in the Control Rig, I would duplicate the Deform Rig, and name it Export Rig. I would then Bake the Action using the following settings: ![BakeActionSettings.PNG](https://archive.blender.org/developer/F667392/BakeActionSettings.PNG) After the bake, I began to notice a discrepancy in the bone positions of those which had been Spline IK bones. Interestingly, sometimes I could get it to work perfectly, usually by adding a visual keying LocRotScale keyframe first. But sometimes, that didn't work, and Blender had to be closed and re-opened. And sometimes THAT didn't work either, resulting in the final workaround which was manually adding a Visual LocRotScale keyframe for all bones in the Export Rig for EACH frame, and then baking the action (except with the "Overwrite" checkbox selected in the Bake Actions options). Essentially, that last step of baking was probably unneeded, but I did it as a quick way to remove all constraints. You can see the difference below, the selected (blue) rig is the baked one, and in the 2nd picture, you can see the baked and unbaked rigs line up perfectly: ![BakeActionError.PNG](https://archive.blender.org/developer/F667395/BakeActionError.PNG) ![BakeActionCorrect.PNG](https://archive.blender.org/developer/F667397/BakeActionCorrect.PNG) Thanks so much for looking into this. Sincerely, Adam Janz

Adam Janz commented

2017-07-15 00:03:04 +02:00

Changed status to: 'Open'

Adam Janz commented

2017-07-15 00:03:04 +02:00

Added subscriber: @AdamJanz

Adam Janz commented

2017-07-15 00:48:17 +02:00

I can confirm there is still a very slight discrepancy (basically negligible) at times even when manually setting visual LocRotScale keyframes and then clearing all constraints manually using Ctrl Alt C. This is likely the nature of Blender not being able to truly pinpoint the position of bones affected by the Spline IK constraint after visually keying. However, there is no doubt something wrong with the way Bake Action does the visual keying on Spline IK affected bones, as 9/10 times there is a fairly large discrepancy.

Adam

I can confirm there is still a very slight discrepancy (basically negligible) at times even when manually setting visual LocRotScale keyframes and then clearing all constraints manually using Ctrl Alt C. This is likely the nature of Blender not being able to truly pinpoint the position of bones affected by the Spline IK constraint after visually keying. However, there is no doubt something wrong with the way Bake Action does the visual keying on Spline IK affected bones, as 9/10 times there is a fairly large discrepancy. - Adam

Joshua Leung commented

2017-07-16 09:08:16 +02:00

Added subscriber: @JoshuaLeung

Joshua Leung commented

2017-07-16 09:08:16 +02:00

Here's a first guess at what may be happening (without having checked the file or the Bake Action operator):
It's likely that because the pose gets evaluated again for each bone (in order to compute what effect the visual keying should have), the results of the previous bone in the chain (that got keyed first) will end up influencing the results for latter bones, causing drift in the results. IIRC, there are similar problems with certain operations for the IK constraint.

Here's a first guess at what may be happening (without having checked the file or the Bake Action operator): It's likely that because the pose gets evaluated again for each bone (in order to compute what effect the visual keying should have), the results of the previous bone in the chain (that got keyed first) will end up influencing the results for latter bones, causing drift in the results. IIRC, there are similar problems with certain operations for the IK constraint.

Adam Janz commented

2017-07-16 20:52:49 +02:00

Thanks Joshua and Brendon for your input. I did notice that manually setting visual LocRotScale keyframes and then hitting Bake Action produced much more accurate (but not perfect) results than just hitting Ctrl Alt C to clear the contraints. Maybe because the visual keying gets applied twice?

Brecht Van Lommel commented

2017-07-17 11:31:32 +02:00

Added subscriber: @brecht

Brecht Van Lommel commented

2017-07-17 11:31:32 +02:00

This seems unrelated to #51971, spline IK is totally different code than IK.

Joshua Leung commented

2017-07-17 17:11:05 +02:00

Indeed, I'd be very surprised if this was related to #51971.

Juan Pablo Bouza commented

2018-01-12 20:53:21 +01:00

Added subscriber: @jpbouza-4

Juan Pablo Bouza commented

2018-01-12 20:53:21 +01:00

I'm having the same problem when trying to export a complex rig to FBX. From what I can see, the problem could be related to the scaling of the bones. In other words, the scale of the parent bone affects the transforms of the child bone, thus, rotations end up looking totally sheared. I really don't know what kind of math could solve this, but it seems a pretty nasty issue if you are exporting things to a game engine.

So far, the only way I could manage to get an undistorted result, was to make all the bones children of the root bone, therefore making each bone independent from each other. Of course, this would not be what you wanted if you were planning on setting up an IK chain inside of the target Game Engine...

I'm having the same problem when trying to export a complex rig to FBX. From what I can see, the problem could be related to the scaling of the bones. In other words, the scale of the parent bone affects the transforms of the child bone, thus, rotations end up looking totally sheared. I really don't know what kind of math could solve this, but it seems a pretty nasty issue if you are exporting things to a game engine. So far, the only way I could manage to get an undistorted result, was to make all the bones children of the root bone, therefore making each bone independent from each other. Of course, this would not be what you wanted if you were planning on setting up an IK chain inside of the target Game Engine...

Adam Janz commented

2018-01-13 04:58:32 +01:00

Hi Juan, you might be encountering [this issue ]]? If so, I posted a workaround; and there is also a solution [ https:*answers.unrealengine.com/questions/474908/blender-to-ue4-squash-and-stretch-bone-heirarchy-s.html?childToView=708553#answer-708553 | inside UE4 if you are using that game engine. I hope this helps!

Hi Juan, you might be encountering [this issue ]]? If so, I posted a workaround; and there is also a solution [[ https:*answers.unrealengine.com/questions/474908/blender-to-ue4-squash-and-stretch-bone-heirarchy-s.html?childToView=708553#answer-708553 | inside UE4 ](https:*developer.blender.org/T51614) if you are using that game engine. I hope this helps!

Juan Pablo Bouza commented

2018-01-13 05:09:52 +01:00

Hi Adam! Thanks for the link!

And yes, I found a similar solution, I also had a couple of bones moving like crazy in the export, so in my case I added some new parent bones that wouldn't scale along wit the rig, but would only copy rotation and location. From what I see, the main issue is with scaling.

Hi Adam! Thanks for the link! And yes, I found a similar solution, I also had a couple of bones moving like crazy in the export, so in my case I added some new parent bones that wouldn't scale along wit the rig, but would only copy rotation and location. From what I see, the main issue is with scaling.

Adam Janz commented

2018-01-13 05:11:28 +01:00

You're welcome! Glad you got it working. :-)

Andy Bay commented

2018-10-18 08:39:16 +02:00

Added subscriber: @Geminoidi

Andy Bay commented

2018-10-18 08:39:16 +02:00

Hi!

For those reading later:

I had a similar problem with baking spline IK and found a really easy fix that worked perfectly at least in my situation:

Take the armature to edit mode and remove the "inherit scale" checkbox from each bone. After this the baking works perfectly (bake action-->"visual keying", "clear constraints" and "replace action" checked.)

Hi! For those reading later: I had a similar problem with baking spline IK and found a really easy fix that worked perfectly at least in my situation: Take the armature to edit mode and remove the "inherit scale" checkbox from each bone. After this the baking works perfectly (bake action-->"visual keying", "clear constraints" and "replace action" checked.)

Adam Janz commented

2018-10-18 14:06:17 +02:00

Thanks Andy for sharing that tip! :)

Adam

Thanks Andy for sharing that tip! :) - Adam

Alexander Gavrilov commented

2018-10-18 14:29:59 +02:00

Added subscriber: @angavrilov

Alexander Gavrilov commented

2018-10-18 14:29:59 +02:00

If disabling Inherit Scale fixes this, it may be related to #54159. Basically, inherited non-uniform scale plus local rotation fundamentally creates shear, and it's impossible to avoid except by only using uniform scale, or not inheriting scale.

Brecht Van Lommel commented

2018-10-18 14:53:14 +02:00

We should probably disable Inherit Scale by default for new bones? It doesn't really solve the bug, but might avoid the problem in most cases. I except that usually you don't even want to inherit scale from parent bones anyway.

Alexander Gavrilov commented

2018-10-18 15:01:33 +02:00

In #52063#544010, @brecht wrote:
We should probably disable Inherit Scale by default for new bones? It doesn't really solve the bug, but might avoid the problem in most cases. I except that usually you don't even want to inherit scale from parent bones anyway.

Reasons not to do it:

Inheriting uniform scale is perfectly fine.
Usually you'd expect resizing your character root bone to work.
When not all checkboxes are enabled the code uses more advanced math to do it, instead of just simply multiplying matrices.
I wonder if export file formats for bone animations actually support these checkboxes - if they only can support full parenting, this would be pointless.

The real cause of user confusion in this case is that constraints, by working directly on matrices, can produce transformations that cannot be replicated using LocRotScale channels. I.e. inheriting scale induces shear into the local coordinate space, but constraints like Stretch To remove it from the world matrix, and this ends up impossible to bake.

> In #52063#544010, @brecht wrote: > We should probably disable Inherit Scale by default for new bones? It doesn't really solve the bug, but might avoid the problem in most cases. I except that usually you don't even want to inherit scale from parent bones anyway. Reasons not to do it: * Inheriting *uniform scale* is perfectly fine. * Usually you'd expect resizing your character root bone to work. * When not all checkboxes are enabled the code uses more advanced math to do it, instead of just simply multiplying matrices. * I wonder if export file formats for bone animations actually support these checkboxes - if they only can support full parenting, this would be pointless. The real cause of *user confusion* in this case is that constraints, by working directly on matrices, can produce transformations that cannot be replicated using LocRotScale channels. I.e. inheriting scale induces shear into the local coordinate space, but constraints like Stretch To remove it from the world matrix, and this ends up impossible to bake.

Juan Pablo Bouza commented

2018-10-18 16:05:16 +02:00

I agree with Alexander, the inherit scale option shouldn't be turned off by default. You want it to be on in 99% of the cases.

Unfortunately, I just tested this and though baking within Blender is in fact fixed by turning off the inherit scale option, FBX export seems to ignore this option and bones get exported with shearing nevertheless.

The only way to avoid shearing is to actually unparent all bones, but though that would export things correctly, visually speaking, you lose hierarchies, and that results in an armature that can't get used in the game engine to add an IK constraints and stuff.

I agree with Alexander, the inherit scale option shouldn't be turned off by default. You want it to be on in 99% of the cases. Unfortunately, I just tested this and though baking within Blender is in fact fixed by turning off the inherit scale option, FBX export seems to ignore this option and bones get exported with shearing nevertheless. The only way to avoid shearing is to actually unparent all bones, but though that would export things correctly, visually speaking, you lose hierarchies, and that results in an armature that can't get used in the game engine to add an IK constraints and stuff.

Alexander Gavrilov commented

2018-10-19 10:57:39 +02:00

In #52063#544056, @jpbouza-4 wrote:
Unfortunately, I just tested this and though baking within Blender is in fact fixed by turning off the inherit scale option, FBX export seems to ignore this option and bones get exported with shearing nevertheless.

So, this seems to answer my last point :)

The only way to avoid shearing is to actually unparent all bones, but though that would export things correctly, visually speaking, you lose hierarchies, and that results in an armature that can't get used in the game engine to add an IK constraints and stuff.

Do you know how game engines deal with the non-uniform scaling problem? Or is non-uniform scaling simply not used in game animation due to this, thus making any rigs using Stretch To or other similar mechanisms in effect not suitable for games? The shear problem is a fundamental aspect of any system that uses matrix multiplication based parenting.

> In #52063#544056, @jpbouza-4 wrote: > Unfortunately, I just tested this and though baking within Blender is in fact fixed by turning off the inherit scale option, FBX export seems to ignore this option and bones get exported with shearing nevertheless. So, this seems to answer my last point :) > The only way to avoid shearing is to actually unparent all bones, but though that would export things correctly, visually speaking, you lose hierarchies, and that results in an armature that can't get used in the game engine to add an IK constraints and stuff. Do you know how game engines deal with the non-uniform scaling problem? Or is non-uniform scaling simply not used in game animation due to this, thus making any rigs using Stretch To or other similar mechanisms in effect not suitable for games? The shear problem is a fundamental aspect of any system that uses matrix multiplication based parenting.

Andy Bay commented

2018-10-19 12:29:54 +02:00

I tested an FBX export as well and there was indeed a slight discrepancy when I brought the file to Unity. Juan, could you describe the unparenting process in more detail? I tried unparenting the bones from each other both before and after baking and the results were messed up in both cases.

Adam Janz commented

2018-10-19 13:49:49 +02:00

In #52063#544179, @angavrilov wrote:
Do you know how game engines deal with the non-uniform scaling problem? Or is non-uniform scaling simply not used in game animation due to this, thus making any rigs using Stretch To or other similar mechanisms in effect not suitable for games? The shear problem is a fundamental aspect of any system that uses matrix multiplication based parenting.

I've used a rig with squash and stretch animations in UE4 which had a stretch to constraint in Blender. However, you can run into problems with undesired bones also stretching based on the parenting relationship. I posted a workaround [here ]], and also someone found an [ https:*answers.unrealengine.com/questions/474908/blender-to-ue4-squash-and-stretch-bone-heirarchy-s.html?childToView=708553#answer-708553 | alternate solution inside UE4 .

> In #52063#544179, @angavrilov wrote: > Do you know how game engines deal with the non-uniform scaling problem? Or is non-uniform scaling simply not used in game animation due to this, thus making any rigs using Stretch To or other similar mechanisms in effect not suitable for games? The shear problem is a fundamental aspect of any system that uses matrix multiplication based parenting. I've used a rig with squash and stretch animations in UE4 which had a stretch to constraint in Blender. However, you can run into problems with undesired bones also stretching based on the parenting relationship. I posted a workaround [here ]], and also someone found an [[ https:*answers.unrealengine.com/questions/474908/blender-to-ue4-squash-and-stretch-bone-heirarchy-s.html?childToView=708553#answer-708553 | alternate solution inside UE4 ](https:*developer.blender.org/T51614).

Juan Pablo Bouza commented

2018-10-19 15:34:11 +02:00

Andy, what I mean is that all bones should be parented to the root bone or some bone that doesn't scale. When you do that, the result is more or less reliable, although it's never 100% correct for some reason.

Andy Bay commented

2018-10-19 19:06:08 +02:00

Juan but is it really possible to get spline IK to work without a standard bone to bone parent hierarchy?

Juan Pablo Bouza commented

2018-10-19 19:18:53 +02:00

Andy, well, yes, the thing is that you've gotta have a control armature and a deformation armature. So, in the control armature you set all the constraints up, spline IK and stuff. When you have everything working, you create the deformation armature that consists of bones that might be parented just to the root so that they don't have a child/parent hierarchy. You then add a copy transforms constraint to each of those bones, pointing to the spline IK bones of the control armature. That way the deformation armature will mimic exactly what the control armature does, but it won't have a hierarchy that ruins the export.
From my experience, you might want to use a copy loc + copy rot + copy scale + damped track + stretch to constraint on each of the deformation bones, instead of just a copy transforms constraint. This has given me better results on export.
Finally for exporting, you just select the mesh and the deformation armature, you don't export the control armature.

Andy, well, yes, the thing is that you've gotta have a control armature and a deformation armature. So, in the control armature you set all the constraints up, spline IK and stuff. When you have everything working, you create the deformation armature that consists of bones that might be parented just to the root so that they don't have a child/parent hierarchy. You then add a copy transforms constraint to each of those bones, pointing to the spline IK bones of the control armature. That way the deformation armature will mimic exactly what the control armature does, but it won't have a hierarchy that ruins the export. From my experience, you might want to use a copy loc + copy rot + copy scale + damped track + stretch to constraint on each of the deformation bones, instead of just a copy transforms constraint. This has given me better results on export. Finally for exporting, you just select the mesh and the deformation armature, you don't export the control armature.

Alexander Gavrilov commented

2018-10-19 19:32:48 +02:00

In #52063#544372, @jpbouza-4 wrote:
From my experience, you might want to use a copy loc + copy rot + copy scale + damped track + stretch to constraint on each of the deformation bones, instead of just a copy transforms constraint. This has given me better results on export.

That's strange. Although one thing about Stretch To is that it rebuilds the matrix from scratch, so it is guaranteed to be pure loc+rot+scale.

Edit: So I wonder what if you use Copy Transforms + redundant Stretch To.

> In #52063#544372, @jpbouza-4 wrote: > From my experience, you might want to use a copy loc + copy rot + copy scale + damped track + stretch to constraint on each of the deformation bones, instead of just a copy transforms constraint. This has given me better results on export. That's strange. Although one thing about Stretch To is that it rebuilds the matrix from scratch, so it is guaranteed to be pure loc+rot+scale. Edit: So I wonder what if you use Copy Transforms + redundant Stretch To.

Andy Bay commented

2018-10-19 20:33:43 +02:00

Thanks for the answer Juan, that clears it up for me!

Sybren A. Stüvel commented

2020-01-09 17:53:36 +01:00

Added subscriber: @dr.sybren

Sybren A. Stüvel commented

2020-01-09 17:53:36 +01:00

Changed status from 'Confirmed' to: 'Archived'

Sybren A. Stüvel closed this issue

2020-01-09 17:53:36 +01:00

Sybren A. Stüvel self-assigned this 2020-01-09 17:53:36 +01:00

Sybren A. Stüvel commented

2020-01-09 17:53:36 +01:00

This report does not contain all the requested information, which is required for us to investigate the issue.

Please submit a new report and carefully follow the instructions. Be sure to provide system information, Blender version, and a minimal .blend file with exact steps to reproduce the problem.

This report does not contain all the requested information, which is required for us to investigate the issue. Please submit a new report and carefully follow the instructions. Be sure to provide system information, Blender version, and a minimal .blend file with exact steps to reproduce the problem.

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

Bake Action inaccurate for Spline IK #52063