Page MenuHome

Depsgraph: add a new operation node for computing B-Bone segments.
ClosedPublic

Authored by Alexander Gavrilov (angavrilov) on Thu, Nov 22, 11:38 AM.

Details

Summary

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.

Diff Detail

Repository
rB Blender

Event Timeline

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?

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.

Rebased & resolved conflict.

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 :)

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?..

Fix proxies: copy the computed segment data.

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 :)

This revision is now accepted and ready to land.Fri, Nov 23, 5:07 PM
This revision was automatically updated to reflect the committed changes.