Colin Marmont made a design task, needs some decisions. Let’s do that during the meeting.
Jason: “selected keyframes” would be great.
Bassam: could even be an operator in the dope sheet / graph editor: select keys, right-click, make motion paths.
Default choices:
Keyframes range if there is such a selection
Preview range
Scene range
Sybren will turn this into comment on the task.
Patch Review & Decision Time
Decision time: Removal of old pose library has to happen. In Blender 3.1 or 3.2?
Paolo: Remove it sooner than later, because having two pose libraries will cause some confusion. Could be done in two phases, first removal of UI but have the data/operations still available for add-ons, then later remove those too.
Blender 3.1: removal of UI panels, and addition of deprecation notes to the Python interface of the pose library.
Blender 3.2: removal of the Python interface and all the C code.
The conversion of old to new pose library Actions is kept (both the DNA flags and pose markers for old poselib actions and the code to convert to the new).
Sybren will make tasks in tracker for the above, and add info to the manual.
Changes in Module members: Sybren removed Wayde Moss, since he hasn’t been active for a long time. The following people are now included in the module as well:
Daniel
Kevin, UX background from Google & Samsung, also working on Python scripting.
Proposal: rename “Dual Quaternion” back to “Preserve Volume”, keep the drop-down, add “Anti-Bulging” option later. The fact that both use Dual Quaterions is then moved to the tooltip.
The tooltip should explicitly mention “Dual Quaternions” and not just “Quaternions”, so that it’s clearer which exact algorithm is used.
Is the feature wanted? And is it worth expanding the already-fragile action
groups for? There’s code in Blender that assumes “group name == bone name”,
which is not generally true. This may become more problematic when this
feature is added.
Bassam: better to fix the underlying fragility first.
Bassam: UI improvements like reordering with drag & drop are more important. It’s hard to do when some channels are hidden, and then you accidentally end up with the wrong ordering.
Paolo: Action groups are quite fragile, and hard to use well. The current situation is already complex, when it comes to where new keyframes go. The area should be cleaned up first, before adding new features.
Bassam: a next-gen animation editor should show all time-based decisions, not just keyframes. Should be possible to select & offset them all together. He has an add-on that already does this for FCurve Function Modifier data with shift+G, and that makes life a lot easier.
Paolo: reminds him of the history of adding animation layers to Blender. There were various add-ons that added various good ideas and specific workflows, but nothing got into Blender because Blender wasn’t ready to get such changes.
Conclusion: too complex for Blender now, and too vague in terms of what concrete problems it solves.
That helps to keep local transform identical before/after parenting, ensuring drivers, animation data, constraints etc. keep working as before.
Biggest problems:
Non-standard behaviour, so people not familiar with Blender don’t expect this.
parent_inverse matrix is hidden, so those same people won’t be able to easily figure out what’s going on.
Conclusion of the discussion:
Add parenting option that doesn’t use parent-inverse but just updates child’s local transform
Add option to Apply Transform menu that applies the parent-inverse to the child’s local transform
Still unclear whether to show the parent-inverse matrix in the UI. There are reasons to show it (to make it clear it exists), but not as individual loc/rot/scale channels (because that wouldn’t convey the entire matrix). Maybe just as indicator it’s set to a non-identity value. At least a sub-panel in the Transform properties panel would be good.
Next Meeting
The next meeting will be on Thursday 9 December, 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.
Hi!! I’m so excited that this is in the discussion, I’ve already answered on the relative thread, and I’m very sorry that we couldn’t provide a valid proposal. I’m not sure what this particular point mean, but I suspect (and really hope) that this single parenting option could solve the whole issue.
It’s a little more complicated than that, since children can be animated : how does the transformation caused by applying the inverse matrix propagate throughout the animation fcurves ? the whole point of not applying the parent inverse matrix is to not mess up animation, which is defendable, but I think we could do even better.
It’s not nice to publicly announce that you’re taking this discussion private. Either do it really private, and don’t tell anyone else, or just keep the discussion in public.
Full disclosure, we have been exchanging Houdini porn, haha. Definitely not suitable for this board, but we reached the conclusion that we’re going to come up with a perfectly original proposal for an overhaul of the parenting mechanics in Blender, one that allows the user to
choose whether or not they want to apply inverse matrix
access this matrix and change it using value sliders (instead of it being completely hidden)
possibly use delta transform to store this information ? although this means changing delta transforms to act as a parent matrix instead of merely adding to the regular transform values
finally correct animation curves as well as possible when an object changes parent (or is unparented)
I believe we’ve identified most of the shortcomings in the current parenting behaviour but coming up with a user facing design needs some more thinking, and that’s not mentioning the implementation, which I don’t have the skills to do
Cheers,
Hadrien
edit that is, provided we find the time. We can always do it in small steps
Yeah, sorry for that. That was my first PM on this forum and I just wanted to be sure that he read the message, but @Hadriscus just explained what it was about actually, nothing secret, just content not allowed in public discussions.
hello. do you have any plans to introduce animation layers into the blender? I could help a little bit with that. I wrote the concept of these layers. it describes how they should work and how the animator should work with them. yes, maybe not everything is perfect, I am not a ux designer and not an animator with 7 years of experience, but this concept definitely has the right to live, at least with edits from knowledgeable people
I think that if you still want to implement it, it will not be very difficult, because the layers are neatly integrated into the already existing animation process, almost without changing it. in addition, I was able to identify several optimization tricks (they will be recorded in the document). I hope you will not ignore me, and at least take a peek at the document anim layers.txt (4.0 KB)
also, in addition to the document, I have a sketch of the interface of the new editor, in which work with layers will be carried out. if you do not refuse this offer, then I will publish it. Alas, that’s all I can do to help. my programming skills are still too weak to implement this really well, and
I don’t have much free time
Hi @sanek, thanks for your interest in animation layers. To answer your question, yes there are ideas about improving the animation layering system beyond what the NLA currently offers. However, I feel that the current animation system needs a redesign of the code, before any new big features are added to it. There is already quite a bit of technical debt in there, which should be resolved first.
If you want to help developing in the animation & rigging code, take a look at the tasks on the workboard. Fixing some bugs could be a great way of getting your feet wet.
@sybren, why don’t you concentrate on fixing the technical debt and redesigning the animation system? I’ve been looking at your rigging roadmap. I will not reinvent the wheel, and I will repeat the meaning of the reaction to this map of one rigger who works in a blender: if there are no animators who will use a blender, then there will be no sense from professional rigging tools. and they don’t go because the animation tools are bad. and at the same time, this is not only a response from professionals (at least in the Russian blender community, I quite often saw people express themselves vividly, covering everything with a three-story mat, due to the fact that it is difficult for them to animate in a blender due to the lack of many features), I saw a beginner who, having started studying animation, preferred Maya crack to blender. And no, I’m not trying to expose the blender as a bad program, I’m tending to the fact that we really need to make a breakthrough, and deal with the problems you have voiced, and finally start improving the animation toolset. I don’t understand why you didn’t put it in the first place. you understand everything perfectly, quite possibly even better than me
Blender is over 20 years old. Ton is the only one who’s been around for all that time, and he’s no longer writing code for Blender. This means that every developer currently working on Blender does so by continuing someone else’s work, and I’m no exception.
why don’t you concentrate on fixing the technical debt and redesigning the animation system?
Because I had an Asset Browser to work on, and make it possible for it to include a Pose Library. Or because I wrote a USD exporter. There are plenty of things to do, and not that many people to actually do it.
@Hadriscus, @RiccardoBancone, Has the proposal of parent inverse matrix issue been done yet?
I was thinking to make one myself. My idea would be just to expose the matrix in UI for artis at this point.
In first clans, it looks simple enough thing for myself to get into blender development.
No I haven’t been able to work on a mockup yet, it’s too busy on my end right now. Just exposing the matrix would be a nice first step. Do you mean as editable or readonly values? Ultimately I thought exposing a set of transform values would be ideal, they are more human-readable-and-editable than a matrix.
Under Relations menu because “Clear Parent Inverse” is at Object > Parent > Clear Parent Inverse menu in 3D view. And because of its name it sounds most logical place for me.
So my idea would be for me to take reference from delta transform code and implement Parent inverse to UI similar way. (I heard UI stuff is good place start with blender development)
@Felor The problem with this approach is that it’s not guaranteed that the parent inverse matrix can actually be decomposed into loc/rot/scale. When it has sheer, it won’t be possible to do this.
I suppose it could be represented by a 5*5 matrix ? or it could use the “fix shear” method @angavrilov added for bones ? so that the matrix returns to orthogonality. By the way, why aren’t the inherit scale methods available for objects as well ?
