- User Since
- Aug 20 2015, 12:17 PM (155 w, 5 d)
Mon, Aug 13
Rebased and resolved conflicts.
Sat, Aug 11
Rebased to 2.8 and tested.
Thu, Aug 9
Better opcode handling: introduce a helper function to apply logic to all three bones.
This file demonstrates it:
Tue, Aug 7
This branch based on 2.8 fixes it:
Sun, Jul 29
I made a very simple addon that creates that 'deform slave armature' I mentioned: https://github.com/angavrilov/blender-scripts/blob/master/slave_armature.py
Wed, Jul 25
Regarding FBX, I have no idea whether disabling Inherit Scale would work with export, so the only solution may be what I like to call in my head a 'deform slave armature': a copy of the original armature with only deform bones, which are all unparented, and bound to follow the original deform bones with Copy Transforms constraints. Since Stretch To destroys shear, the final world transform of the bones is good, so if parenting is removed from the picture, it should be bakeable.
Tue, Jul 24
Mon, Jul 23
To elaborate a bit:
So, what's really going on here is that mathematically stacking non-uniform scaling and rotation creates shear, and there obviously are blender pose channels for shear. Thus in this bone arrangement it is impossible to reproduce the transformation created by constraints using the pose channels, unless parent-child relations are disconnected, or Inherit Scale is unchecked.
Sat, Jul 21
Introduced a bullet spring type option instead of a second spring constraint type.
@Alexander Gavrilov (angavrilov) Having a drop down menu to select the spring type, like I mentioned above, should be fine.
Fri, Jul 20
Regarding angular springs not being stable, it's not that they are more unstable than linear ones. As I mentioned, it is just the case that unlike linear springs they don't effectively clamp stiffness to prevent exploding. This video was computed with exact same settings as the previous one, except for using 3000 instead of 2000 steps per seconds; yet the oscillation frequency changes. This is because linear stiffness is clamped and increasing step count increases the actual effective stiffness.
So basically what we have here isn't that new springs are broken or something, but primarily that the old ones have a weird implementation of damping, which has a quirk that with the value exactly 1 the spring turns from a spring into something more like plastic deformation, or a spring combined with a ratchet that only extends depending on force and doesn't actually spring back (to get it to move back you actually need to apply opposing external force higher than the one that caused extension).
Thu, Jul 19
Mon, Jul 16
Simplified to only change the Copy Transforms constraint.
Jul 14 2018
And now after some more testing, observations re new springs:
Btw, looking at this file more, it actually relies on this junk damping behavior to work. With the old constraint setting damping all the way to 0 (1 in blender UI) completely kills a velocity term in the computation, which I expect is totally nonphysical, and yet this test file relies on it to achieve the observed behavior. If you set damping values to 0.999999, it actually stops collapsing and becomes all jiggly-bouncy but stable. Set it to 0.99999 or smaller, and the bounce self-amplifies and eventually explodes even with the old constraints.
I'm absolutely against reverting, because damping in the old constraint is junk.
A test demonstrating the difference in damping and limit behavior between spring and spring2 by using both in the same file:
Jul 13 2018
Initially I wanted to expose access to both types of springs, but @Sergej Reich (sergof) suggested to try just switching to the new one first, and that went in as D3125. Maybe exposing both is better after all.
Jul 12 2018
Jul 11 2018
Dramatically improve numerical stability by internally using double in cross product computation.
Jul 10 2018
Added two stages of corrections to deal with two floating point precision problems around the singularity:
Jul 9 2018
This issue is probably extremely unlikely to happen in actual use as it's hard to align things this perfectly in animation, but it easily can happen in artificial rig tests like shown above, and it means that you technically can't rely on Damped Track to fulfill its main goal of pointing the specified axis in the specified direction.
Jul 7 2018
Apr 27 2018
Apr 22 2018
Apr 19 2018
Some observations after just looking through the patch.
Apr 9 2018
Apr 3 2018
Mar 2 2018
Mar 1 2018
Nov 1 2017
Oct 28 2017
Fixed some of the code style problems.
Oct 18 2017
Oct 17 2017
Oct 16 2017
Moved updates into add_modifier and remove_modifier.
Oct 10 2017
Oct 7 2017
Oct 3 2017
Oct 2 2017
Oct 1 2017
Sep 30 2017
After more looking at it: nobody would want this simplistic symmetry that is not aware of vertex group mirroring, and the proper old weight paint specific mirroring is not compatible with parallelism as it updates the mirror vertex inside the single vertex paint function. Plus, vertex group mirroring is another reason why weight paint may affect more than one weight value per vertex.
I just happened to start working on an idea I had more than a year ago and noticed that this commit basically rewrites weight painting while apparently completely ignoring the existence multipaint for some strange reason. I didn't actually test, but I bet it's now broken.
Sep 22 2017
Removed lib_link stuff and made BKE_fcurve_is_cyclic non-static.
Sep 19 2017
After a discussion in IRC it seems D2783 is the way to go, at least for now.
Sep 11 2017
Why no reply for almost a month?
Sep 1 2017
Try Principled with Transmission = 1.