2023-09-07 Animation & Rigging module meeting

Meetings
1

The meeting was on 2023-09-07T16:00:00Z. It is open for everybody interested to join on Google Meet (link below).

Present: Alexander Gavrilov, Charles Wardlaw, Christoph Lendenfeld, Fani-Eleni Pandi, Ingo Clemens, Jason Schleifer, Jon Matthis, Michael Kowalski, Nate Rupsis, Nathan Vegdahl, Felipe G, Sybren Stüvel

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

Links

Since the Last Meeting / Announcements

  • The Bone Collections feature was received with great enthousiasm on Blender Today.
  • Sybren back from holiday.

Landed

Short-term goals / Ongoing Work

Patch Review / Discussion / Decision Time

  • #111931: USD: Support armature and shape key export

    • Michael (NVIDIA) working on this. Idea is export of armatures → usdskel + shapekeys → usd blend shapes.
    • A UsdSkel importer is also underway.
    • Discussion in #pipeline-assets-io-module channel.
    • Challenge: Modifiers on top of the Armature modifier, especially when they change the vertex count, things get difficult. USD assumes mesh topology matches the blend shapes, whereas Blender’s evaluated mesh might be different.
    • Open question: what should the default be for deformed mesh exports? On (use UsdSkel deformation) or off (write geometry caches)?
      • Charles: should be ON, as many people exporting will be for import into a game engine.
      • Sybren: ON will also cause faster roundtrips, as having that by mistake will be faster & produce smaller files than exporting geometry caches. So correcting such a mistake will be ‘cheaper’.
      • Nathan: USD, coming from Pixar, is more for the film production use case, which would suggest OFF is a more suitable default. Also agrees with Sybren.
      • Charles: Pixar doesn’t layer deformers (like other companies like Sony or Disney), so exporting those to USD will likely be working without loss (i.e. not need full geometry caches). This would still be using it also as sort of a cache, but then caching a complex rig down to a simpler set of deforming bones in USD.
    • Michael: another issue is choosing which shapekeys to export.
      • Exporting all could be exporting too many, bloating files.
      • Skipping them based on which modifiers use them could work.
      • Nathan: probably better to have users manually specify that, to avoid surprises.
    • For proper support, Blender needs to be able to handle mirrored bones. Mostly X-mirrored for symmetry, hence with scale.x = -1 and thus negative determinant.
    • Charles suggested (in Blender Chat) that adding “a float[3] rest_scale to the Bone struct that is only taken into account when building the rest arm mat” might be enough. Would need to be heavily tested. Maybe Paul Kanyuk (Pixar, also involved in the #pipeline-assets-io-module chat channel) can give a simple setup to start working on this?
    • Charles: might not be a good idea though, as constraints might have a hard time dealing with matrices like this. This kind of mirroring makes copy-pasting animated values / curves from one side to the other super simple, as that wouldn’t require flipping the animation data. He would do this at the control level, though, and not the bone level.
    • Nathan: shares worries about the constraint code, as there are lots of assumptions in there.
    • Alexander: also ‘Preserve Volume’ and bendy bones could add more complications.
    • Charles: even if it works for IK joints and driving things, it might be enough. But probably better to wait until Pixar releases OpenExec (Open Source version of Presto’s constraint evaluation engine).
    • Sybren: might be too much effort & risk to work on for now, if the goal is ‘only’ to support Pixar assets.
    • Nathan: it could fit in a future redesign of more generalisations in Blender’s armature system.
    • Charles: having arbitrary rest positions in Blender could be a way to get this in, without having it as a feature in the UI.
    • Sybren: that would be much more preferred, and that fits in better with the current plants of the module.
    • Charles: could also be super helpful for quadriped-to-biped transitions of characters, where a 4-legged character can also move as a biped.
    • Alexander: do you need float[3]? Or would a boolean like “flipped X” be enough?
    • Charles: yes, as Pixar sometimes uses nonuniform floats, so (-0.5, 0.75, 1.0) kind of vectors.
    • Alexander: what of sheer?
    • Charles: that’s for the rigger to handle.

  • Charles: (in context of the above): it might be a good time to have ‘joint draw mode’.

  • Decide on a color of keys if the curve is locked. #111986: Animation: Graph Editor locked key drawing

    • Currently it’s an ‘x’ for locked keys, as it’s also used for baked curves.
    • This PR changes them to be grey, which matches disabled curves. They are similar (i.e. read-only) but are evaluated differently.
    • Sybren: the curve itself will be different between locked and disabled.
    • Sybren: maybe tiny dot?
    • Jason & Nathan: like the idea.
    • Nate: Square?
    • Jason: likes that too.
    • Christoph: distinguishing square from round might not work at certain resolutions / UI scales.
    • Sybren: using shapes for locked/unlocked might make them unavailable for other purposes. Not sure if locking is an important enough feature.

  • Two PRs for the same thing:

  • Christoph’s proposal: Removing Baked FCurves

    • Consensus in the thread: do not remove them, but rename them to avoid confusion.
    • Christoph: has a PR for better FCurve baking, with stepping, baking FCurve modifiers, etc. That makes them actually useful.

Felipe’s Non-Rigged Lines

Felipe quickly discusses his “non-rigged lines” system, drawing lines on top of rigged & deformed mesh.

  • works like ‘hair curves’ assets, by sampling curves in UV-space.
  • will provide demo file.
  • Will we get weight groups for curves? Now you need a hook per point of the curve. Even setting the weight manually per point would be nice already.
  • Will continue discussion in the module chat, especially since Spiderverse linework was mentioned, and Charles worked on Spiderverse.

Next Meeting

The next meeting will be on Thursday 2023-09-14T16: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.

13 Likes