Fri, Nov 9
Since last asking for information it has been 7 or more days, due to the policy of our bug tracker we will have to archive the report until the requested information is given.
Thu, Nov 8
Sat, Nov 3
With --threads you can control how many tasks run in parallel in various areas of blender.
One of these areas is dependency graph evaluation (animationsystem, etc).
I created a shortcut to the exe, added -t 1 and now I can translate keyframes. After googling --threads 1 and -t 1 from the other task you posted, I couldn't find any documentation on what it does and why it solves the issue. For the sake of anyone who might experience this, and in the interest of a third task not being made, why does this solve the problem?
Fri, Nov 2
Marking as incomplete until we have an answer...
Cant get it to crash in this simple scenario, but I'm pretty sure this is the same as T57530.
@Boomer FiftyNine (Boomer059) : can you confirm this doesnt happen when you start blender from the commandline with the --threads 1 option?
Thu, Nov 1
Could you share the blendfile?
And try to describe exactly the steps to reproduce then.
(which operations to do, what should be the expected behavior, what is the [buggy] observed behavior)
Wed, Oct 31
Tue, Oct 30
I would like to highlight this bug and better explain it because it is extremely annoying !
I send you a new blend file saved on 2.79b
If we open this file on blender 2.8 we see that the animation does not launch.
I hope you find the error of this compatibility bug between 2.79b and 2.8.
Mon, Oct 29
Behavior of effectors has been changed in Blender 2.8 with new dependency graph, and should have became safe for threading.
Tue, Oct 23
Thanks for the info!
This really is an issue for @Sergey Sharybin (sergey) to look at, it's a limitation regarding animation visibility in the dependency graph. We may not even support it in the first 2.80 release since it is quite complex to solve.
Mon, Oct 22
Initially reported bug is caused by ID properties always tagging for time update. Doing something like this P806 solves the issue.
Fri, Oct 19
Thanks for the answer Juan, that clears it up for me!
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.
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.
Thu, Oct 18
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.
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:
Oct 11 2018
Sep 21 2018
ok, thank you
Sep 20 2018
@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)…
Sep 19 2018
Sep 17 2018
@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… ;)