2023-08-10 Animation & Rigging module meeting

Meetings
1

The meeting will be on 2023-08-10T16:00:00Z. It is open for everybody interested to join on Google Meet (link below).

Present: Alexander Gavrilov, Brad Clark, Christoph Lendenfeld, Eduardo Rubio, Eleni Pandi, Nathan Vegdahl, Pierrick Picaut

People present are referred to by first name for brevity. Others are referred to by full name.

Links

Since the Last Meeting / Announcements

  • SIGGRAPH this week! Sybren StĂĽvel and others are away, having a good time and making the rest of us jealous.
  • Nathan moved the animation-level constraints document to devtalk, since that’s better for long-form discussion. Comments and ideas wanted!
    • Nathan: Brecht Van Lommel recently commented, noting that it’s pretty abstract and hard to follow. Good point. Should work on making it more concrete and visual, with better examples.
  • Brad is working on a design document for Animation 2025, based on the last months of research and design work: Animation 2025 “Flow state” design roadmap - Google Documenten
    • Brad: it’s been a long road, lots of research and discussion. Trying to make a solid framework for Blender to build on. Still a lot of work to do–very WIP. Feedback welcome.

Landed

Short-term goals / Ongoing Work

Patch Review & Decision Time

Help Needed

Next Meeting

The next meeting will be on Tuesday 2023-08-15T10:00:00Z. Again it will be open for everybody who’s interested. The provisionary meeting agenda will be linked in the #animation-module channel before the meeting.

8 Likes
2

I knew there was something off deformation-wise when a bbone’s rest pose was strongly curved… Couldn’t quite put my finger on it. Really nice seeing improvements in that area.
The discussion kinda flies over my head, but from what I understand you’re wondering how best to map vertices to bbone segments when several segments’ normals intersect at a certain distance from the bone ? If a given vertex is only ever mapped to two bbone segments, and the bbone describes a circle arc so that every segment normal converges to a point, how is that case handled ? what happens to that vertex ?

3

you’re wondering how best to map vertices to bbone segments when several segments’ normals intersect at a certain distance from the bone?

The problem most discussed is that while the current mapping (since a certain point in time - wasn’t the case when bbones were first added) weights every vertex to two segments to produce a smooth deformation gradient, the curved mapping creates a boundary with an abrupt jump between mapping to the nearest end of the curve and somewhere in the middle - this can be seen from the coloring on the images. This jump is fundamentally caused by a discontinuity in the underlying math problem, so I don’t see any clear non-hacky way to avoid it. Arguably it may be better to deal with an easy to understand discontinuity to work around, than potentially less predictable hacks added to mask it…

If a given vertex is only ever mapped to two bbone segments, and the bbone describes a circle arc so that every segment normal converges to a point, how is that case handled ? what happens to that vertex ?

One of the comments has a blend file that allows you to view the mapping boundaries in real time using geometry nodes to emulate them (it’s quite slow for some reason but usable). You would get this result, with a smooth gradient around the circle when closer to the bone than the center of curvature, and an abrupt jump between the ends of the curve further than that. I think the center of curvature would be mapped basically randomly, dependent on floating point math precision errors.

bbone-splits-circle

1 Like
4

Thanks for taking the time to unwrap this for me. I’ll check out the blend file once our undersea cable is fixed, it’s impossible to download anything right now.
You also mention a performance concern, how noticeable is it ? with many bbones ? have you profiled it ?

5

You also mention a performance concern, how noticeable is it ? with many bbones ? have you profiled it?

I didn’t measure anything, but the new method objectively needs to do about log2(Nsegments) + 4 times more math than the old one per transformed vertex (i.e. for 8 segments about 7-8x), plus about 15 of those units of computation per every B-Bone segment during the armature update.

Compared to the whole per-vertex cost of the Armature modifier it may not amount to a significant percentage though - the cost of simply transforming a vector by a matrix is 3 units, and the modifier needs to do that for all painted bones and blend the result.

1 Like