2021-02-18 Animation & Rigging Module Meeting

Meetings
1

The main goal of this meeting was a status update of ongoing work.

The meeting was open on Google Meet for everybody interested.

Present: Bassam Kurdali, bird_d, Christoph Lendenfeld, Demeter Dzadik, Jeremy Bot, Sebastian Parborg, Stanislav Ovcharov, Wayde Moss.

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

Links

Since the Last Meeting / Announcements

  • Announcement: Sculpt, Paint & Texture module is going to make a generic attribute painting system. This will also impact weight painting, which will become official part of that module. Once generic attribute painting is implemented, the weight paint specific responsibilities can go to Animation & Rigging.
    • Sebastian: When did Topology Mirroring last work? He suggests to use UV maps for this, and mirror in UV space. This could be made multi-threaded & fast. Currently it uses a mapping structure from the whole mesh, which is failing (and has been for a while). This in light of T84520, in his investigation he found lots of other things not working well. Still uncertain how much time he can spend on fixing these, though.
    • Weight Paint operators that use symmetry settings should expose this more clearly to users. For example in redo panel. T85789

Short-term goals

  • T57003: Copy visual pose and paste over frame range
    • On hold due to Sybren’s work on the Asset Browser / Pose Library. It is a part of the envisioned workflow with the Pose Library, though, as it should be possible to copy-paste poses between blend files.
    • Bassam: will the Asset system take external and non-blender libraries into account? Sybren: yes, in the sense that the currently envisioned design allows for this. Implementation will come later.
  • T83068: Motion Paths: Refresh all
    • Only feedback so far: it’s going to be slow. Since refreshing all motion paths one by one manually will be even slower, all present see this as not a problem.
  • T84520: Confusing Symmetry settings in Weight Painting: Sebastian Parborg is working on this.
    • He wants more feedback from riggers and other artists using the feature.
    • Bassam: put it in a branch & give a test build? From a superficial looks of the descriptions it in the chat it’s good.
    • Sybren & Sebastian: test builds for patches/branches are going to be automatic at some point; James Monteath (employed by Blender Institute) is working on this.

Other Topics

  • Google Summer of Code

    • Should be technical, non-docs, and something new.
    • Bassam: It could be interesting for a student on Rigify improvements. Sybren: could be, but easy to make the work too fuzzily defined, making it too large a project for a GSoC.
    • Bassam: integrate Rigify with asset system? Probably too early, maybe next year.
    • Sebastian: implicit skinning, has been tried a few times in the past but people dropped out.
    • Sebastian: students are working half-time, so smaller projects.

  • Action Baking: how far can we stretch the current code, and how can we implement a future-proof version?

    • Wayde is working on several patches. He says the current code is not too bad in terms of complexity, once you get a hang of it.
    • For improving it to make it more future-proof, he needs more info from animators on what they’d want from the system.

Help Needed

  • T82932: Mirror Pose: Custom center of symmetry

    • Sebastian: we should have is customizable, pick anything and it’ll mirror around that point. For bones the bone name stays relevant for mirroring, but bones should also be pickable as mirror center.
    • Bassam: you could 3D cursor or active object, depending on what’s chosen in the 3D Viewport as pivot option. Luciano told him earlier that he didn’t like that, but he’s not available to join the meeting today.
    • Demeter: Pablo Fournier also asked him for something like this.
    • Sebastian: could be a per-bone option, like “these bones mirror around that bone”, so becomes more addon-ish scripting than core feature.
    • Bassam: maybe Blender could expose some generic mirroring code that add-ons could use to simplify the implementation of custom mirroring add-ons?
    • Sebastian: yes, something like that is already on the radar, where the operator is given a transform it can use for mirroring.
    • Bassam: maybe not enough, as f.e. 8 selected bones actually could consist of two groups each with their own custom pivot point.

  • Side-discussion when talking about the pivot point:

    • Sybren: this touches on Active vs. Selected + using an unselected Active as pivot point. Sebastian: very fragile, as one mis-click changes the active selection.
    • Bassam: box-select is faster than click-select (heard from other animator, also confirmed by Jeremy and Sebastian), maybe box-select should also set the active bone?
    • Sebastian: box-select also selects everything, while click-selects has logic to toggle between overlapping elements. Might be two things combined, StarCraft style box-select being faster for users AND click-select being slower to respond in Blender.
    • Bassam: OpenGL Depth Picking was reported as influencing this a lot, but unknown in which direction.
    • Jeremy confirmed click-select is slow.
    • Demeter: How about alt-click to select from a list of overlapping bones, similar to overlapping objects? Demeter will create task for this, Sebastian can implement.

Other

  • Christoph: discuss the idea of Time Selection. It could be interesting to try out in smaller context to see what works.
  • Jeremy Bot: bone pivot point should get in Blender. Mostly a matter of deciding where in the UI the option for pivot point position is placed.
    • Jeremy: Should not be option per bone, but global option. If you need it per bone, custom bone shapes are preferred then. All agree.
    • Bassam: The option to display axes is on the armature already, and wherever that option is, the slider could go next to that. With the current “Display Axes” option, this means that the pivot point becomes an option armature.

Next Meeting

The next meeting will be on Thursday 4 March, 16: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.

5 Likes
3

Hi guys! Kids have started school so I won’t be able to attend to the meetings at the currently set time. One hour later would work for me! Let me know how that sounds for everyone!

1 Like
4

+1 for rigify improvemnts. I would suggest making it user friendly so that anyone can create custom rigs for it. I would love to have a gui where I can take any rig I have and automatically convert it to a rigify feature set.

1 Like
5

I don’t know if anyone will read this, but I have a couple of ideas for this module:

_ Possibility to use textures as the mask factor for the Mask modifier. This would enable us to create very detailed geometry masks if you use the modifier after a subsurf modifier for instance.

_ Possibility of using vgroups in the material editor. Vgroups are much more flexible than vertex colors and they would allow us to add more complexity to material rigs such as wrinkle maps and stuff like that.

2 Likes
6

Just to keep it in mind:

  • Tension maps for animations? It was a feature before 2.8 and would be great to add it. Maybe even suitable for a google summer of code.

Currently, he made it with vanilla blender but the setup is extraordinary…
Here to check the video.

1 Like
7

Great. Can we paint unclamped values? Can we data transfer from arbitrarily chosen, dissimilar attributes fluidly? Can we use arbitrary attributes in shader nodes? (Good example of use case, vertex color is often used as a mix factor, when Blender always treats it as sRGB, which complicates interpolation.)

Rigify needs to be generalized to any arbitrary rig, which it could be, given a few new, generally useful, tools:

  1. Copy (replace) bone constraints from arm2 to bones in arm1, on the basis of name, while retaining positions of bones in arm1;
  2. Set the rest length of all stretch-to constraints equal to the rest pose length of the bone;
  3. Merge bones in one armature to another (same names acquire position, constraints, settings of bones in arm1, while remaining bones in arm2 have constraint targets, parenting redirected to bones existing in arm1);
  4. Bone layer names (which technically can be done with text object custom shapes) and improved bone layer UI (like Rigify has);
  5. Generalized snapping, via instant constraints to avoid dependency issues.

When you have all that, a “Rigify” rig is a .blend file where you place a handful of empties and run a few operations, and it can be any style of rig you want, and adding to it is a breeze. No addons or scripts.

The number one problem with bake action as it currently exists is that it slower than it should be, by at least two orders of magnitude. At least, for typical usage (and if weird usage takes long, then you should check for weird usage before doing fast vs. slow versions.) If you improve baking to the point that it can basically be used dynamically, then you can start to see addons that do cool things with it. For instance, you can fix skating, although it would require two bake passes as far as I can tell; you can get re-implementation of abandoned features like slow parents.

Why should it even be an option? It’s purely UI, with no backwards compatibility issues, and I’ve never seen a single person say that they prefer the axes to be displayed at bone tails. “Option” always seems like the safer idea, but you end up clogging up the interface if you choose it too often. (I recognize that the linked post offers, “As we realise there are some advantages to occasionally viewing the display axis at the tip of the bones,” but doesn’t specify; it sounds like the imagined advantage is totally colocated bones, but colocated bones have different axes hopefully [or else you’ve got bigger interface problems], you still have the issue of bones with branching at both ends, and global bone UI settings don’t solve the problem anyways.)

8

The meeting notes are great for continuing discussion on the meeting topics. However, they aren’t the best place to present/request new ideas. Right Click Select is the go-to place for those.

Good question, but another module is going to take care of the abstractions first. They won’t be reading this.

That’s why there is currently a patch under review that addresses its performance.

Because it will break people’s muscle memory. It actually can cause backward compatibility issues with the actual people using Blender.

The fact that it’s implemented in this way shows that at least some point, at least to some people, this was the preferred approach.

9

I second the idea of trying implicit skinning once again. It seems like it would be specific enough, well scaled for a gsoc and have great impact on the rigging process, potentially simplifying deformation rigs a lot.

1 Like
10

Right Click Select is not a great place to submit proposals either. In less than 24 hours as a new user I reached negative karma and I can never post there ever again. They say they will fix the negative karma block in 6 months form now. The fix proposed will prevent you from getting negative karma for proposing unliked ideas. What it doesn’t mention is anything about bringing me back to zero karma. So who knows. It feels like a gut punch as I want to make Blender a better product anyway I can including participating in proposing ideas for the software.

3 Likes
11

Ouch, that’s bad. I’m sure that people can be brought back to zero karma; the system isn’t meant as a punishment.

I’ll contact you via direct message, this isn’t the thread to discuss issues with Right Click Select.

1 Like
12

One hour later would work for me too. Since nobody has responded here either one way or the other, let’s discuss in this week’s meeting.

13

This is what how i think we should have the Mirror Pose / X Mirror option:

it should be a “PER ARMATURE” option (like mirror on off).
it should be an option oriented to animation (not rigging), available always (only maybe?) in pose mode (for rigging you can use 3D cursor and other sorts of tricks)
paste mirror pose should also obey it.
it should be easy to get in the interface like in the following image:

image
image992Ă—723 82.8 KB

When no bone is chosen for the mirroring, we should default to the current mirror system.

2 Likes
14

I feel like the functionality you describe here could be (and perhaps should be at first) an addon. We should brainstorm use-cases and design, I think I could add this to my list. Perhaps it could be included with Blender or even enabled by default, if testing shows it as adequate.

1 Like