The goal of this three-day workshop will be to come up with a design for a new character animation system in Blender. It’ll be the kickoff of a 3-year project Animation 2025.
If you’re joining the workshop, or even if you just want the workshop-peoples to see something you think is important (max 5 minute video), please use this sign-up sheet. It’ll help us streamline the process.
Schedule
Every day, there will be three “sync moments” to make sure online/remote attendees are in sync with what’s happening at Blender HQ, and vice versa.
All times are in local time, so CEST / Amsterdam time.
Time
Your local time (ignore the date, it’s on all workshop days)
@sybren It looks like I missed the window to add to the blank slate doc, so hopefully it’s okay if I post a comment here. I am very surprised to not see Cumulative Root Motion on these lists. Many people use Mixamo and other mocap motion clips because it is one of the fastest and easiest ways to animate a character. However, Blender is very cumbersome to work with when combining these motion clips together for a longer animation. I would actually recommend having a look at Reallusion iClone’s workflow for this, which has become a fairly powerful animation tool. It is a simple drag and drop to add multiple motion clips onto a character, the root motion is preserved, so the location doesn’t reset back to the world origin or suddenly change rotation. The motion clips can be easily blended together. It works intuitively and produces super fast results that can then be further refined with animation layers or easily applied to only certain body parts. I think a solution for this type of motion clip combining workflow would be very powerful for anyone who uses Mixamo, mocap suits, AI video mocap, or similar. Even for traditional animators creating walk cycles and other highly reusable actions. Imagine how fast you could get results if you had a library of motions you could quickly retarget to a character, quickly string a few motions together, and easily adjust them. To me, that is the definition of the tools getting out of the way and keeping animators animating.
Thanks for writing it down @blaqkshadow. It’s very similar to something I’ve had in mind for a while, but never put into words myself. It’s useful to have it here & fresh on our retina.
Thinking about Nathan Vegdahls “no more armatures - just bones”.
An only-bones approach might clash with Blender’s unique-object-names approach.
Imagine, you copy a rig few times. Then, you add/remove bones randomly across all rigs. Blender still follows unique-naming across whole Blend-file. Naming would not follow rig structure, but naming would be determined by the time a bone is created. In several rigs with hundreds of bones, how to prevent blender’s unique-name-for-objects to create a naming mess?
Probably with auto namespaces. Personally I don’t mind if armatures and pose mode go out in favor of object based rigging, but I would never want to throw out all the convenience that comes with it : the fact that every bone is zero’d out, the bone-specific color groups, the poses, etc.
I dont think there is a plan to remove armatures.
It was one idea Vegdahl published in the paper ‘Blank State - Character Animation in Blender’.
I tried to pount out that Blender’s current naming convention might clash with this idea.
But (as Hardiscus said) namespacing might resolve this.
@Hadriscus If bones are objects, we still could use Delta transformation to place our bone where it belongs. We do not need to touch Local transformation.
Yep. The only thing I’m worried about is it might mean additional work. I don’t want to have to create offset groups as in Maya, Blender’s design is lightyears ahead of this and I wouldn’t trade it for anything. As long as it stays automated I’m all good. But who knows, maybe the rigging design will change so drastically that these matters will become totally irrelevant. “What’s a bone? it’s all nerves and tendrils now, haven’t you heard”
That’s the thing I am worried about, it seemingly has some benefits, but also huge drawbacks and it looks like just copying archaic workflow from “Some industry standard software that shall not be named” to please some audience, which will not be using Blender anyway.
The people who have contributed to the document are Blender users, and Nathan Vegdahl specifically is a professional who knows what he’s talking about. So I think it comes from a good place and isn’t a desire to copy some software. There’s a drive to deduplicate animation tools : have them work on all objects and not have armatures be such a special case. On the other hand, having an entire rig contained in an armature object like that is super practical and allows for some unique behaviours we mentioned earlier, not to mention parent hierarchies in Blender would have to be drastically improved before character rigging can move to the object level.
The typical field of tension for blender: “We should not just copy software [x].” “Why is feature [y] so cumbersome in blender when software [x] did it pretty right years ago?” “Blender is Open Source and legally not allowed to copy anything from anywhere just like that…”
As it is a kickoff meeting I’d stay clear of dismissing any ideas upfront already. It’s usually a good practice to start out by throwing anything into the field first. Just “Yes-And” to all ideas for starting over. Then remix some of these ideas and think them over and in this process discard some that feel like they don’t work as well as thought initially.
The rest of the problems and benefits will arise when actual first prototypes begin.
Being worried is okay but in the phase of idea finding it’s not really necessary. It’s much more beneficial to just let every idea happen. Every idea. Nothing concrete has happened or started yet. And who knows. Maybe it’s even better than expected or maybe the original idea get an unexpected spin making it even better.
Let worries creep in once a design is more or less settled upon.
Blender being Open Source doesn’t have anything to do with that. Blatantly copying other software’s approaches is dubious at best, regardless of what is being copied into. Copying as-is, without deeper understanding of why something is so good, and without thinking about what would need to change to make things fit into a Blender workflow, is a good way to create a pile of inconsistent, ill-integrated features.
As it is a kickoff meeting I’d stay clear of dismissing any ideas upfront already. It’s usually a good practice to start out by throwing anything into the field first.
I know. Which is why we opened up various documents for people to provide such feedback, weeks before the workshop even started. They’re actually linked from the top post.
Sorry, my bad. My reply was meant in reply to MeshVoid’s worries about blindly copying some other software. I think so far Blender has proven very well that this is rarely the case and things change and get refined along the way.
