Improvements to "Bake Action..." Operator #82168

New Issue

Luciano Muñoz Sessarego · 2020-10-27T22:41:13+01:00

Luciano Muñoz Sessarego commented

2020-10-27 22:41:13 +01:00

With the developments happening in the blender animation module more robust tools and feature are being needed.

The "Bake Action..." operator is a rather useful tool that feels incomplete:

Here are some options that would take it to the next level.

Options to set between Current frame range, preview range and custom range.
Frame step should only output the desired frame step, currently it merges the current keys with the frame step so in example: if I have keys on ones and I bake on 2's the current result is ones as there are already keys there. It should remove the keys (in the baked range) and replace them with the new keys on 2's.
When baking, the resulting keys should obey the default keyframe interpolation type set in the animation preferences. (if its set to constant, all the resulting keys should be constant, if its linear the resulting keys should be linear)
A "smart bake" which should only perform the baking action where key frames already exist in the selected objects/bones (up for discussion but maybe going up one level up in the chain and transfer those keys to the object would be good too.
Include "custom properties" in the result of the bake, currently custom properties lose their keys. (and anything that can be stored stored in the action)
option to "merge actions" that will bake the animation data from all the available actions and put it in the main "non pushed" action and delete the other actions (without needing to go into the nla and get rid of them manually)

These seem from my ignorance very minor features that would make the operator much more useful in production.

With the developments happening in the blender animation module more robust tools and feature are being needed. The "Bake Action..." operator is a rather useful tool that feels incomplete: Here are some options that would take it to the next level. - Options to set between Current frame range, preview range and custom range. - Frame step should only output the desired frame step, currently it merges the current keys with the frame step so in example: if I have keys on ones and I bake on 2's the current result is ones as there are already keys there. It should remove the keys (in the baked range) and replace them with the new keys on 2's. - When baking, the resulting keys should obey the default keyframe interpolation type set in the animation preferences. (if its set to constant, all the resulting keys should be constant, if its linear the resulting keys should be linear) - A "smart bake" which should only perform the baking action where key frames already exist in the selected objects/bones (up for discussion but maybe going up one level up in the chain and transfer those keys to the object would be good too. - Include "custom properties" in the result of the bake, currently custom properties lose their keys. (and anything that can be stored stored in the action) - option to "merge actions" that will bake the animation data from all the available actions and put it in the main "non pushed" action and delete the other actions (without needing to go into the nla and get rid of them manually) These seem from my ignorance very minor features that would make the operator much more useful in production.

Luciano Muñoz Sessarego commented

2020-10-27 22:41:13 +01:00

Added subscriber: @LucianoMunoz

Wayde Moss commented

2020-12-29 22:08:20 +01:00

Added subscriber: @wbmoss_dev

Wayde Moss commented

2020-12-29 22:08:20 +01:00

For (1), would it be sufficient to use the active frame range? If the preview range is ON, then that's the default for the bake range. If OFF, then it would use the non-preview range?

Luciano Muñoz Sessarego commented

2021-01-26 14:22:10 +01:00

The only problem that i see here is that would be implicit rather than explicit and that is the problem in a lot of areas in blender even if the zen of python says otherwise.
In any case I'd place a little clock watch icon in the panel too that would be turned on if the one in the timeline is on and so on just so its clear to the user what is being done on what range and WHY.

But you're on the right track nevertheless.

The only problem that i see here is that would be implicit rather than explicit and that is the problem in a lot of areas in blender even if the zen of python says otherwise. In any case I'd place a little clock watch icon in the panel too that would be turned on if the one in the timeline is on and so on just so its clear to the user what is being done on what range and WHY. But you're on the right track nevertheless.

Wayde Moss self-assigned this 2021-02-11 01:39:00 +01:00

Wayde Moss commented

2021-03-03 01:04:41 +01:00

For the smart baking levels idea:

Maybe we could support "Baking Sets" where bones grouped together in the same set are keyed together. Then that leaves the proper definition of them to the rigger who knows the rig inside out. The animator can expand upon it if needed for specific uses. To make it more automated, we can provide operators to create the baking sets (based on constraints and drivers on the added bone). These sets can then be cleaned up and fixed by the rigger or animator.

I suppose the more general implementation of "Baking Sets" are normal bone collections which should replace Armature Layers anyways.

For the smart baking levels idea: Maybe we could support "Baking Sets" where bones grouped together in the same set are keyed together. Then that leaves the proper definition of them to the rigger who knows the rig inside out. The animator can expand upon it if needed for specific uses. To make it more automated, we can provide operators to create the baking sets (based on constraints and drivers on the added bone). These sets can then be cleaned up and fixed by the rigger or animator. I suppose the more general implementation of "Baking Sets" are normal bone collections which should replace Armature Layers anyways.

Luciano Muñoz Sessarego commented

2021-03-03 01:10:27 +01:00

Im not against the idea I'm not sure I understand it though.
I was thinking more a levels where you'd have a little number slider that could go "0" only keep the keys from the current selected baked controls, "1" this and whatever bones have direct influence over this will transfer its keys, you get the idea.
Maybe -1 to get keyframes from every thing in the armature ? (i don't know how useful would that be)

What do you think, i feel this way is simple and requires 0 set up for the user just chose what they need on a case by case basis.

Im not against the idea I'm not sure I understand it though. I was thinking more a levels where you'd have a little number slider that could go "0" only keep the keys from the current selected baked controls, "1" this and whatever bones have direct influence over this will transfer its keys, you get the idea. Maybe -1 to get keyframes from every thing in the armature ? (i don't know how useful would that be) What do you think, i feel this way is simple and requires 0 set up for the user just chose what they need on a case by case basis.

Wayde Moss commented

2021-03-03 02:21:33 +01:00

The problem with levels is that the rig can have many levels of indirection. For Pierrick Picaut's rigs, he creates intermediate bones all the time. For a Head bone that optionally follows the neck, there are intermediate bones which may never be seen or keyed by an animator. I imagine Rigify rigs are similar (I'm not familiar with Rigify).

What if we used level 2? But that's the same problem. If you are given a rig, then you don't know the proper amount of indirection (levels) to bake. And the number of levels changes on a per-bone basis too.

What if we used a really big number? That effectively creates a key where any keyframe exists on the rig.

The problem with levels is that the rig can have many levels of indirection. For Pierrick Picaut's rigs, he creates intermediate bones all the time. For a Head bone that optionally follows the neck, there are intermediate bones which may never be seen or keyed by an animator. I imagine Rigify rigs are similar (I'm not familiar with Rigify). What if we used level 2? But that's the same problem. If you are given a rig, then you don't know the proper amount of indirection (levels) to bake. And the number of levels changes on a per-bone basis too. What if we used a really big number? That effectively creates a key where any keyframe exists on the rig.

Luciano Muñoz Sessarego commented

2021-03-03 02:57:02 +01:00

That's why I think I'd work if there is an intermediate bone that doesn't have a key good then its not considered and only consider the ones that do.

The levels will give you an explicit way of troubleshooting when you don't get the exact result you expect and be able to control it.

And yes a really big number will effectively give you a key wherever it exist in the rig, expected.

To add to this the default should be 1. Normally its the control / object and whatever directly connects to it that we'll pick up keys from (whether direct parent or constrain)

That's why I think I'd work if there is an intermediate bone that doesn't have a key good then its not considered and only consider the ones that do. The levels will give you an explicit way of troubleshooting when you don't get the exact result you expect and be able to control it. And yes a really big number will effectively give you a key wherever it exist in the rig, expected. To add to this the default should be 1. Normally its the control / object and whatever directly connects to it that we'll pick up keys from (whether direct parent or constrain)

Wayde Moss commented

2021-03-03 23:28:43 +01:00

I'll make test patch for the levels idea.

Include "custom properties" in the result of the bake, currently custom properties lose their keys. (and anything that can be stored stored in the action)

option to "merge actions" that will bake the animation data from all the available actions and put it in the main "non pushed" action and delete the other actions (without needing to go into the nla and get rid of them manually)

Can you give use cases for these two? I'm only aware of one example: using an NLA layer to switch to IK arms and completely replace a segment of FK animation. Then bake with the expectation that the IK switch is transferred too. In this case, 5 and 6 are the same thing and can probably be better named: Merge all NLA. What are the cases for (5) that is independent of (6) and vice versa?

I'll make test patch for the levels idea. ___ >5. Include "custom properties" in the result of the bake, currently custom properties lose their keys. (and anything that can be stored stored in the action) >6. option to "merge actions" that will bake the animation data from all the available actions and put it in the main "non pushed" action and delete the other actions (without needing to go into the nla and get rid of them manually) Can you give use cases for these two? I'm only aware of one example: using an NLA layer to switch to IK arms and completely replace a segment of FK animation. Then bake with the expectation that the IK switch is transferred too. In this case, 5 and 6 are the same thing and can probably be better named: `Merge all NLA`. What are the cases for (5) that is independent of (6) and vice versa?

Luciano Muñoz Sessarego commented

2021-03-04 00:11:33 +01:00

I'm not sure how they are the same?, 6 does involve the improvement from 5 though.

As it is now, if you use the bake action tool even in just one action (not pushed) custom properties data gets lost. It needs to be considered as well.
is being able to merge several nla pushed actions to one:
Example I created an action for walking and one for running y put them both in the nla mix them etc, now I just want all the data merged to the original animation so I can easily modify it.

I'm not sure how they are the same?, 6 does involve the improvement from 5 though. 5. As it is now, if you use the bake action tool even in just one action (not pushed) custom properties data gets lost. It needs to be considered as well. 6. is being able to merge several nla pushed actions to one: Example I created an action for walking and one for running y put them both in the nla mix them etc, now I just want all the data merged to the original animation so I can easily modify it.

Wayde Moss commented

2021-03-04 00:26:30 +01:00

Oh so baking to a new action should keep the nontransform animated channels? Can do.

5) Oh so baking to a new action should keep the nontransform animated channels? Can do.

Luciano Muñoz Sessarego commented

2021-03-04 00:31:07 +01:00

yes!

Sarah Laufer commented

2021-08-26 09:45:02 +02:00

Added subscriber: @feldlaufer-4

Sarah Laufer commented

2021-08-26 09:47:38 +02:00

being able to bake custom properties is urgeeeeent !!! cause atm there is simply no way to do it? why would we animate properties and not want them baked after? do we know when the new features could be available?

Wayde Moss was unassigned by Sybren A. Stüvel

2022-01-03 12:09:33 +01:00

Philipp Oeser removed the

Download

What's New

Blender Studio

Manual

Developers Blog

Documentation

Benchmark

Blender Conference

Development Fund

One-time Donations

Improvements to "Bake Action..." Operator #82168