Computing the shape of a B-Bone is a quite expensive operation, and
there are multiple constraints that can access this information in
a variety of useful ways. This means computing the shape once per
bone and saving it is good for performance.
Since the shape may depend on the position of up to two other bones,
often in a "cyclic" manner, this computation has to be a separate
node with its own dependencies.
Hrm, annoyingly, just committed line wrapping change, since it was too much insane to deal with this file.. But solving conflict is trivial, just accept your changes and then we can re-apply parts of cleanup.
One thing which is not clear for me, is whether armature_cached_bbone_deformation() should be changed to use the new precalculated bbones?
It's using them - now all it does basically is collect the precalculated array pointers from pchans to that structure, and compute DualQuats for non-bbones.
Ah, indeed. must have been confused by some other local changes.
Unfortunately, with this patch i've got an assert failure around
BLI_assert failed: /home/sergey/src/blender/blender/source/blender/blenkernel/intern/armature.c:1074, armature_bbone_defmats_cb(), at 'pchan->runtime.bbone_segments == pchan->bone->segments'
This is due to pchan->runtime.bbone_segments being 0, while pchan->bone->segments is 4. This is happening with a production rig, so if you don't have quick clues i'd need to think how to share that with you :)
That means BKE_pchan_cache_bbone_segments (i.e. BKE_pose_eval_bbone_segments via DEG_OPCODE_BONE_SEGMENTS) didn't actually run on that pchan for some reason - runtime.bbone_segments is for checking that the data is computed and correct size (to avoid buffer overruns).
Maybe something is wrong with update tagging or something?..
The crash is indeed solved now!
Not an expert of the area, but changes seems reasonable, design is what we've discussed in iRC it should be and no known issues so far.
I'd say LGTM. just be around after the push :)