2021-06-10 Animation & Rigging Module Meeting

The main goal of this meeting will be a status update on & discussion of ongoing work.

The meeting will be open for everybody interested to join on Google Meet (link below).

Present: Bassam Kurdali, Christoph Lendenfeld, Daniel Zan Salazar, Demeter Dzadik, Juan Pablo Bouza, Luciano Muñoz, Nacho Conesa, Sergio, Sybren Stüvel

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


Since the Last Meeting / Announcements

  • Meeting is moved back by one hour to 18:00 to make it more accessible from New Zealand.
  • Bassam making Inkscape mockups of graph editor header/menu improvements, in coordination with UI module.
    • Moving some settings around & changing some booleans to enums (so list of values to choose from, instead of bunch of on/off toggles)
    • Make it more consistent with curves in the 3D View when it comes to the drawing of handles.
  • Christoph Lendenfeld got commit access!
  • Sybren talks a bit about last week’s Asset Workshop, blog posts coming!
  • Sergio introduces himself: Blender user for a year, aware of Blender since 2010. Works on pipeline, starting his own company. Wants to contribute to Blender.

Short-term goals

Decision Time

  • T66946: NLA strip unexpectedly auto-switching from Hold to Hold Forward

    • Current code has /* FIXME: this needs to be more automated, since user can rearrange strips */
    • Bassam: user’s choice shouldn’t be overwritten. Could be noted in UI why it’s not valid.
    • Sybren: currently it’s three options (NLASTRIP_EXTEND_HOLD, NLASTRIP_EXTEND_HOLD_FORWARD, NLASTRIP_EXTEND_NOTHING), maybe we should just have a boolean for each direction it’s extending in.
    • Sybren: maybe even having backward extrapolation makes sense on 2nd and further strips on the same track, if they animate different options. Might be tricky to get fast, though.
    • Bassam: maybe just trust the user and let them do strange things?
    • Sybren: the patch should take things further, and avoid overwriting the extrapolation property altogether.
  • D11528: Fix T88068: Changed default Alt-I behavior to be more intuitive

    • Demeter: Nobody uses Alt-I, just commit it and see who complains.
    • Luciano doesn’t use it, Juan Pablo didn’t know about it.
    • Everybody agrees to just commit.

Help Needed

  • T78794: Running scripts on append/link

    • Bassam: understands why, did something like that himself too for Tube and other projects. They have Python Post-hooks in their custom asset manager, which can for example create a proxy armature, and parent some things together, when placing a character into the scene.
    • Bassam: might be a security risk, though.
    • Christoph: has seen malware that embeds itself into a Maya node.
    • Demeter: less of an issue at Blender Anim Studio because of their pipeline tool that automatically prepares files for animators.
    • Sybren: would this be part of an asset system, or in Blender for datablocks in general?
    • Bassam: it’s a side-effect; you append something and then something else happens as well. For an asset system that makes more sense; an asset is more of an abstraction than just appending a datablock. There are already some side-effects, like instancing a collection into the scene.
    • Christoph: wouldn’t be much of an issue, as those scripts would be user-created and would be expected by the user of a certain rig.
    • Demeter: proposed it before the asset system; his idea was as simple as a checkbox in the Append/Link operator. Any text datablock referenced from a linked-in datablock would be run.
    • Sybren: this may make it too easy to accidentally run too much code, and to run code that wasn’t intended to be run for this feature.
    • Bassam: it could also cause a problem with scripts marked as “Register” running not only on append but also on every subsequent file-open.
    • Sybren: I think it’s best to include this in the asset browser system.
    • The rest agrees.
  • VSE Performance With Animation addresses a Video Sequence Editor performance issue. With a bit of optimization, its performance could increase quite a bit. The basic idea is that most animation on VSE strips themselves are only relevant for when the current frame intersects that strip (i.e. when it’s visible). This needs feedback from people with VSE experience.

Other Things

  • Daniel: Workbench engine settings allow influencing object colours, like setting it to Random.
    • This is useful in regular object or mesh edit modes.
    • These colour-influencing options are reduced to only shading (and not colouring) in texture painting mode, because in texture painting the colour of the texture itself should be clearly visible.
    • In Weight Paint mode, however, the colour is still applied, and totally messes up the viewport.
    • Demeter: this is a known issue, filed in T73434: Weight Paint Overlay

Next Meeting

The next meeting will be on Thursday 24 June, 18:00 CET/Amsterdam time. 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.

I’ve seen this vague idea of strip occlusion multiple times but I’ve never understood it. Can someone help explain it? The comment is added by rB4ec5a9a42c00 and the initial commit is rB0f4fd4f5b17d But those commits are decades old and doesn’t explicitly explain the problems it actually intends to fix or the situations where they would occur.