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

In T52063#544372, @Juan Pablo Bouza (jpbouza) 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.

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.

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

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.

In T52063#544179, @Alexander Gavrilov (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.

Another thing I noticed when having an animated custom property is that even other keyframes might not be evaluated anymore (and this is even true for 2.79 with new depsgraph)...:

@Antonio Vazquez (antoniov): asked in IRC if I could also have a look, and here are my findings (sorry for the lengthy detour, this might all be totally obvious for others...)

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.

In T52063#544056, @Juan Pablo Bouza (jpbouza) 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.

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.

In T52063#544010, @Brecht Van Lommel (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.

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.

If disabling Inherit Scale fixes this, it may be related to T54159. 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.

Thanks Andy for sharing that tip! :)

For those reading later:

ok, thank you

@Joshua Leung (aligorith) not sure about that one, animation of those properties is not explicitly disabled in RNA code, so I guess animation is prevented by missing valid RNA path handling for FCurve modifiers? But I kind of doubt we'd want to support that, would be some sort of inception (animation within animation)…

@Sergey Sharybin (sergey) you worked on hair recently, maybe you can check on that one? Thanks.

Thanks for your response.

Does this still happen within 2.8? Otherwise there is very little chance this get fixed in 2.7x series now… ;)

Crash still occurs, but very intermittently. Hard to see an obvious cause.

Thanks for the report, but bugs about new depsgraph in old 2.7x series are really not relevant at all now, new deg is only developed and maintained in 2.8 branch.

One have to wiggle a lot to make it crash indeed… Looks like yet another COW/threading issue (threaded code from deg evaluation using some COW data already freed from somewhere else)…

@Joshua Leung (aligorith) not sure how to fix this, looks like recalcData_actedit() does not have access to fcurves, so it cannot check whether re-ordering of keyframes is actually needed… Maybe we should just always call remake_graph_transdata() there?

Reminds me of similar issue with some VSE properties in 2.7x… IIRC, animation gets re-evaluated when editing those values, hence they get reset to animated value immediately…

Seems to be an update issue, clicking on the show/hide 'eye' icon, or on the render 'camera' one in the outliner fixes to visibility too, but clicking again on the viewport 'grid' one exhibits again the problem. As if driver eval was not updating things properly. not suer what exactly is the problem here, would suspect again some COW/depsgraph thingy, @Sergey Sharybin (sergey)?

ok. you are the coder.

That’s the last time I say it: THIS BUGTRACKER IS NOT A USER SUPPORT SERVICE!

I think that it not necessary to look into the code as first thing to check. Maybe I used wrong configuration on the settings of the FBX panel,or it's necessary to use a "special" combination of settings,that I don't know. The best solution I think could be to make some attempts by the cross users,users who uses/know blender and nuke. I think that it worth trying before to close this post. If It was not strictly a bug,it was very close to be a bug,because each combination of setting should produce a different kind of effect,but since it could work only in some circumstances,it could be a bug.

You’ll have to give proof that issue is from Blender side, not from Nuke side first… afaik meshes are pretty reliable in our FBX io addon. Not our job to investigate that kind of issue, especially not with a closed-source software we don’t have access to.

ok for the armature,but not good for the mesh. Nuke should import correctly the FBX file format.both in 6.1 ASCII and in 7.4 binary format. If it does not do it correctly,it's a bug of blender. So,I suggest to re open this bug. And anyway,the question deserves to be deepened,not closed on two feets.

Thanks for the report, but this sounds more like user support than bug to me - we don’t even know whether Nuke supports rigging at all, even less if it can import it correctly from FBX…

Cannot confirm here on linux, might be something specific to OSX… @Arto Kitula (akitula), maybe you can check? Thanks.