Spline IK 'Fit Curve' scaling incorrect on FBX export #73863

New Issue

Philip Guin · 2020-02-16T02:12:18+01:00

Philip Guin commented

2020-02-16 02:12:18 +01:00

System Information
Operating system: Windows-10-10.0.18362-SP0 64 Bits
Graphics card: GeForce GTX 970/PCIe/SSE2 NVIDIA Corporation 4.5.0 NVIDIA 432.00

Blender Version
Broken: version: 2.82 (sub 7), branch: master, commit date: 2020-02-12 16:20, hash: blender/blender@77d23b0bd7

Short description of error
FBX export of a typical Spline IK with non-uniform scaling options (e.g. Fit Curve) gives incorrect results. Baking via F3 -> Bake Action did NOT reproduce the issue.

Problem has apparently been bugging people for a while (see [this thread ]] and [ https:*www.youtube.com/watch?v=VIEfzo7iqjo | this video for an example.) A suggested fix is to duplicate the bone chain, remove all parenting and constraints from the new chain and add "Copy Transform" constraints from each new bone to the original. Due to animation baking, I can confirm this does initially appear to work, however: it removes parenting information in the final export, meaning that even with baking, blending between multiple animations will fail completely.

Exact steps for others to reproduce the error

Load the attached .blend file.
Hit Space to play the current action. Notice the correct shape of the animated noodle poses.
Navigate to File -> Export -> FBX.
- Under Transform, set 'Apply Scalings' to 'FBX Units scale'
- Under Armature, enable 'Only Deform Bones' and disable 'Add Leaf Bones'
- Make an Operator Preset to save some trouble.
- Hit 'Export FBX'.
Open the exported FBX in Windows 3D Viewer, or whatever application you prefer.

Notice incorrect animated noodle poses.

Blend File: AnimBakeInheritScaleIgnored.blend

Broken FBX: AnimBakeInheritScaleIgnored.fbx

Expected poses: {F8342553}

Result poses: {F8342558}

Comments
I'm not familiar with the source, but in the FBX exporter plugin, a place to look may be in file fbx_utils.py , function fbx_object_matrix, possibly not accounting for the Inherit Scale option. It's pretty hard to decipher without knowing the plugin well, however.

Thanks for your time.

**System Information** Operating system: Windows-10-10.0.18362-SP0 64 Bits Graphics card: GeForce GTX 970/PCIe/SSE2 NVIDIA Corporation 4.5.0 NVIDIA 432.00 **Blender Version** Broken: version: 2.82 (sub 7), branch: master, commit date: 2020-02-12 16:20, hash: `blender/blender@77d23b0bd7` **Short description of error** FBX export of a typical Spline IK with non-uniform scaling options (e.g. Fit Curve) gives incorrect results. Baking via F3 -> Bake Action did NOT reproduce the issue. Problem has apparently been bugging people for a while (see [this thread ]] and [[ https:*www.youtube.com/watch?v=VIEfzo7iqjo | this video ](https:*blenderartists.org/t/spline-ik-bake-and-export-problem/700647) for an example.) A suggested fix is to duplicate the bone chain, remove all parenting and constraints from the new chain and add "Copy Transform" constraints from each new bone to the original. Due to animation baking, I can confirm this does initially *appear* to work, however: it removes parenting information in the final export, meaning that even with baking, blending between multiple animations will fail completely. **Exact steps for others to reproduce the error** - Load the attached .blend file. - Hit Space to play the current action. Notice the correct shape of the animated noodle poses. - Navigate to File -> Export -> FBX. - Under Transform, set 'Apply Scalings' to 'FBX Units scale' - Under Armature, enable 'Only Deform Bones' and disable 'Add Leaf Bones' - Make an Operator Preset to save some trouble. - Hit 'Export FBX'. - Open the exported FBX in Windows 3D Viewer, or whatever application you prefer. # Notice incorrect animated noodle poses. Blend File: [AnimBakeInheritScaleIgnored.blend](https://archive.blender.org/developer/F8342573/AnimBakeInheritScaleIgnored.blend) Broken FBX: [AnimBakeInheritScaleIgnored.fbx](https://archive.blender.org/developer/F8342574/AnimBakeInheritScaleIgnored.fbx) Expected poses: {[F8342553](https://archive.blender.org/developer/F8342553/Input1.PNG)}![Input2.PNG](https://archive.blender.org/developer/F8342555/Input2.PNG) Result poses: {[F8342558](https://archive.blender.org/developer/F8342558/Output1.PNG)}![Output2.PNG](https://archive.blender.org/developer/F8342560/Output2.PNG) **Comments** I'm not familiar with the source, but in the FBX exporter plugin, a place to look may be in file [fbx_utils.py ](https://github.com/sobotka/blender-addons/blob/master/io_scene_fbx/fbx_utils.py), function `fbx_object_matrix`, possibly not accounting for the Inherit Scale option. It's pretty hard to decipher without knowing the plugin well, however. Thanks for your time.

Philip Guin commented

2020-02-16 02:12:18 +01:00

Added subscriber: @Frizzil

blender-admin commented

2020-02-16 02:12:18 +01:00

#71449 was marked as duplicate of this issue

Richard Antalik commented

2020-02-17 12:43:08 +01:00

Changed status from 'Needs Triage' to: 'Confirmed'

Philip Guin commented

2020-02-18 00:21:52 +01:00

Thanks for acknowledging this issue, hopefully someone takes a look at it soon! If I get some time, I might see if I can get involved, though I'd specifically want to work on this problem.

Also, I haven't tested this, but I suspect it may be affecting non-uniform scale in exported animations unrelated to the Spline IK. If true, I imagine that would affect priority.

As to evaluating importance: as a game dev, this is completely blocking my ability to have "squash and stretch" animations on my main character model (which if you're Disney, is an important feature!) Anyone modeling a creature or humanoid with a tail may also be blocked by this, as evidenced by discussion of this issue on other platforms. And if it's blocking all non-uniform scale, then that's a huge feature that both UE4 and Unity support, and game developers would be missing out on.

Godspeed, Blender devs!

Thanks for acknowledging this issue, hopefully someone takes a look at it soon! If I get some time, I might see if I can get involved, though I'd specifically want to work on this problem. Also, I haven't tested this, but I suspect it may be affecting non-uniform scale in exported animations unrelated to the Spline IK. If true, I imagine that would affect priority. As to evaluating importance: as a game dev, this is completely blocking my ability to have "squash and stretch" animations on my main character model (which if you're Disney, is an important feature!) Anyone modeling a creature or humanoid with a tail may also be blocked by this, as evidenced by discussion of this issue on other platforms. And if it's blocking all non-uniform scale, then that's a huge feature that both UE4 and Unity support, and game developers would be missing out on. Godspeed, Blender devs!

Bastien Montagne commented

2020-05-27 18:29:01 +02:00

Added subscriber: @hufeng

Philip Guin commented

2020-05-28 00:12:29 +02:00

I should give an update, this may help in decision-making:

I went through the trouble of cloning the Blender repo and trying to fix this issue, which turned out to involve "Non-Uniform Scale Inheritance." As it just so happens, FBXNode has an attribute for this, "TransformInheritType", that can be set to one of three values, RrSs = 0, RSrs = 1, Rrs = 2. (See here, but search for "Transformation Propagation") In the current build, it's always set to RSrs, and the output transforms implicitly assume this inheritance type as they're computed. When I modified the code to output the correct inheritance type, and compute the transform accordingly, something interesting happened. I opened it up in Unity and got this warning:

ImportFBX Warnings:
File contains 7 (out of 11) nodes with Scale Compensation. Scale Compensation is not supported by Unity (because it works differently in 3dsMax and Maya). This might result in scale imported incorrectly, if this happens try disabling Scale Compensation in your file.

It was also very, very incorrect. I got much better results in Windows 3D Viewer, however, but still incorrect. (Ultimately I have no idea if my transforms were actually correct, but I don't know of a way to verify besides heavily modifying my game engine, which is not independently reproducible.) This leads me to believe that scale compensation is not a well supported feature, and an effort to add it to Blender might also necessitate an effort to add it to other software packages.

The best approach? We could add it to Blender but leave a checkbox to "Disable Scale Compensation", checked by default. Then everyone's happy - if some software package or game developer (like yours truly) wants to use Scale Inheritance as documented by FBX, they can; and other packages can stay the same, or migrate to the "correct" method over time.

Now, we could do nothing... but like I said before, that's a major feature that these engines claim to support, and it would be great to have for "toon-like" animation. In any case, Disney thought it was important enough to invent and publish their own algorithm for visualizing it in real-time, for artists working on Frozen .

More research should probably be done on this. Also, I can post my source changes and/or exported models with "Scale Compensation" if needed. Thanks for reading.

I should give an update, this may help in decision-making: I went through the trouble of cloning the Blender repo and trying to fix this issue, which turned out to involve "Non-Uniform Scale Inheritance." As it just so happens, FBXNode has an attribute for this, "TransformInheritType", that can be set to one of three values, RrSs = 0, RSrs = 1, Rrs = 2. (See [here](http://docs.autodesk.com/FBX/2014/ENU/FBX-SDK-Documentation/index.html?url=cpp_ref/class_fbx_node.html,topicNumber=cpp_ref_class_fbx_node_html), but search for "Transformation Propagation") In the current build, it's always set to RSrs, and the output transforms implicitly assume this inheritance type as they're computed. When I modified the code to output the correct inheritance type, and compute the transform accordingly, something interesting happened. I opened it up in Unity and got this warning: ``` ImportFBX Warnings: File contains 7 (out of 11) nodes with Scale Compensation. Scale Compensation is not supported by Unity (because it works differently in 3dsMax and Maya). This might result in scale imported incorrectly, if this happens try disabling Scale Compensation in your file. ``` It was also very, very incorrect. I got much better results in Windows 3D Viewer, however, but still incorrect. (Ultimately I have no idea if my transforms were actually correct, but I don't know of a way to verify besides heavily modifying my game engine, which is not independently reproducible.) This leads me to believe that scale compensation is not a well supported feature, and an effort to add it to Blender might also necessitate an effort to add it to other software packages. The best approach? We could add it to Blender but leave a checkbox to "Disable Scale Compensation", checked by default. Then everyone's happy - if some software package or game developer (like yours truly) wants to use Scale Inheritance as documented by FBX, they can; and other packages can stay the same, or migrate to the "correct" method over time. Now, we *could* do nothing... but like I said before, that's a major feature that these engines claim to support, and it would be great to have for "toon-like" animation. In any case, [Disney thought it was important enough to invent and publish their own algorithm for visualizing it in real-time, for artists working on Frozen ](https://disney-animation.s3.amazonaws.com/uploads/production/publication_asset/98/asset/dualQ.pdf). More research should probably be done on this. Also, I can post my source changes and/or exported models with "Scale Compensation" if needed. Thanks for reading.

Aleksandr commented

2020-09-29 13:43:48 +02:00

Added subscriber: @viadvena

Aleksandr commented

2020-09-29 13:43:48 +02:00

Looks like Blender has big problem with scale. SplineIK, Stretch To - completely unusable and useless for export. No controlled ropes, no controlled tails. Rigify due this issue is also damaging bones and corrupt animation. It's sad that fundamental issues does not resolving for so long time. Where is Animation 2020?)
Blender can not handle standard animation tricks. I think there is no place for new features until so big issues will be resolved.

Looks like Blender has big problem with scale. SplineIK, Stretch To - completely unusable and useless for export. No controlled ropes, no controlled tails. Rigify due this issue is also damaging bones and corrupt animation. It's sad that fundamental issues does not resolving for so long time. Where is Animation 2020?) Blender can not handle standard animation tricks. I think there is no place for new features until so big issues will be resolved.

Jan Schneider commented

2020-12-18 10:03:22 +01:00

Added subscriber: @chuderluuri

Jan Schneider commented

2020-12-18 10:03:22 +01:00

I can confirm, that the Spline IK Baking is broken.
I had a fairly long chain ofbones (~30) and when baking the animation, the tip of the cian was just everso slightly off to not match with other animations.
I managed to solve it in the end by creating a second chain of bones, then clearing all the parents, and then constraining the with a "copy transform ocnstriant" to the corresponding bone in the spline ik chain.
Its an ugly hack, but it works.

Is is possible that when baking rotation (or saving it to fbx in that matter) somehow reduces accuracy in the numbers that store rotation? if so this would make sense, as small inaccuracies woul acumulate through the bone chain. but i am no expert, just a guess

I can confirm, that the Spline IK Baking is broken. I had a fairly long chain ofbones (~30) and when baking the animation, the tip of the cian was just everso slightly off to not match with other animations. I managed to solve it in the end by creating a second chain of bones, then clearing all the parents, and then constraining the with a "copy transform ocnstriant" to the corresponding bone in the spline ik chain. Its an ugly hack, but it works. Is is possible that when baking rotation (or saving it to fbx in that matter) somehow reduces accuracy in the numbers that store rotation? if so this would make sense, as small inaccuracies woul acumulate through the bone chain. but i am no expert, just a guess

Aleksandr commented

2021-10-05 19:38:48 +02:00

Is there some hope for 3.0? This constraint doesn't work for game engines and this is big deal...

AM commented

2021-12-04 16:29:47 +01:00

Added subscriber: @AM-1

AM commented

2021-12-04 16:36:58 +01:00

This is not only a FBX-Export (Add-On) Problem, but also a Object > Animation > Bake Action Problem. ("Bastien Montagne (mont29) moved this task from Backlog to Long Term on the Add-ons (BF-Blender) board.")
wich is very unfortunate, because with this issue, spline IK is only usable with y-scale = original bone scale and nothing else.

Personally i need it for a game engine workflow and didnt expect it to fail at that stage.

This is not only a FBX-Export (Add-On) Problem, but also a Object > Animation > Bake Action Problem. ("Bastien Montagne (mont29) moved this task from Backlog to Long Term on the Add-ons (BF-Blender) board.") wich is very unfortunate, because with this issue, spline IK is only usable with y-scale = original bone scale and nothing else. Personally i need it for a game engine workflow and didnt expect it to fail at that stage.

Kanno commented

2024-09-17 16:58:16 +02:00

I believe we've hit this issue on 3.5 as well, and indeed it seems that heavy use of non-uniform scaling in general triggers this as mentioned above, not just SplineIK.

We were able to get around the issue by setting the bones of the chain to not inherit scale, and then manually baking the action using Blender's built-in baking tools. This resulted in a properly scaled and positioned chain but was not a serviceable workflow for us and relying on the exporter's baking did not work.

Our quick and dirty solution was similar to those mentioned above - we used a non-deforming SplineIK chain and then had free-floating bones the mesh was actually skinned to constrained to the non-deforming chain. We only constrained position and rotation however, and drove scale manually for our needs (therefore ignoring the SplineIK's scaling along the Y axis).

Would be great to have this properly fixed for game pipelines indeed!

I believe we've hit this issue on 3.5 as well, and indeed it seems that heavy use of non-uniform scaling in general triggers this as mentioned above, not just SplineIK. We were able to get around the issue by setting the bones of the chain to not inherit scale, and then manually baking the action using Blender's built-in baking tools. This resulted in a properly scaled and positioned chain but was not a serviceable workflow for us and relying on the exporter's baking did not work. Our quick and dirty solution was similar to those mentioned above - we used a non-deforming SplineIK chain and then had free-floating bones the mesh was actually skinned to constrained to the non-deforming chain. We only constrained position and rotation however, and drove scale manually for our needs (therefore ignoring the SplineIK's scaling along the Y axis). Would be great to have this properly fixed for game pipelines indeed!

Sign in to join this conversation.