We already have a software resolver for computing the bones on the CPU (software skinning) so it should not be too complex to get the final matrices
I did not even think of the gpu processing to be removed. Due to single threading of the cpu, gpu in addition is probably not going to get the same % wallclock reduction.
@Ankit_Singh I have a lot going on, sorry. I also have my own pose & IK pose based animation system, which also supports root bone translation, so I would not really be able to take advantage. Pose based with interpolation is massively more compact, allows for the creation of animation more easily.
It is also time based, not frame based, so going from a 60 Hz monitor, 72 Hz Occulus Quest, and 90 hz Occulus Quest 2 will end up interpolating perfectly for each. The reduction you will be getting is just of doing business for me that I cannot avoid.
1 Like
I would but I am stacked right now, I gotta finish writing up documents and tutorials for my new features, thanks for the offer though!
If I can free up my plate ill peep some.
1 Like
Hey team! any news on that?
1 Like
So would we use the clients LocalStorage and check if the uniquid of that mesh with the animation has some sort of cache with that specific animations data. If its not there then the system would start recording each frame until the animations stops or is looped?
Then instead of each frame having its matrices calculated and bound we just lookup the values from our cache and set the appropriate ones.
Additionally then if any modifications are made to the animation we would have to clear that animations cache and record the results again.
What about root animation, hmmmm interesting. Kind of forgot about this thread⌠whatcha thinking DK?
the engine should not make assumption on where data is stored. Iâm more interested in the mechanism to record the data (in memory) and we can let the user decide where to store it
Is there a ticket/job request on the talent cloud I should be looking at, or do you just want me to whip up something in my freetime here?
I think, I have this figured out (in my mind) just have not had a chance to apply it yet.
Well this is not something we plan to invest in but happy to support the idea if someone wants to tackle it:)
1 Like
We are following the task here: Baked animation support ¡ Issue #8966 ¡ BabylonJS/Babylon.js (github.com)
Hey guys,
I came across this issue while exploring the âhelp wantedâ list. Is there any progress on it or the help actually wanted?
Nobody is actually working on it and we do not have planed time for it at the moment, so yup, help would be amazing 
So if I got it right, the idea is to record transform matrices values for every single frame for every single bone? This may produce huge amount of data. Isnât it better to record fewer frames and then interpolate those values somehow?
This is a pretty good question, maybe @Deltakosh or @PatrickRyan have more insights on the overall baking results ?
Yes @johnSamilin , interpolation between key frames is far superior from a space standpoint. I have a whole animation system based on the queuing of a succession of poses / key frames which are interpolated to from the state just prior. When combined with doing animation based on time not fixed frames, you can generate animation for any device frame rate on the fly. An Oculus Quest 2 has gone from 72 to 90 to 120 fps. I do not even care.
I have progressed to the point that I am actually manufacturing / compositing the poses from a fixed set of elemental poses like 5 poses per finger, as well as defining IK poses in my own editor scene (storing the controller positions not the bones). Instant infinite animation in a very small space.
This is the complete opposite of baking though. Think the goal here is to save cpu.
As it applies here, the more I think about it, this baking is ALREADY being done in the Blender, MAX, Maya exporters, and this is where almost all bone animation comes from unless you have built your own editor right in BJS.
In the Blender exporter, whether the action is baked or just key framed, I proceed through each pose at the scenes assigned frame rate, one frame at a time, taking a snapshot the matrices of each bone. I thought I was supplying armature origin bone matrices, but they could be bone local. Not checking.
I think that this baking is not going to be saving that much, because the result is still going to be a need to get final world matrices based on the location of the mesh at some point. Perhaps, if the there was a switch in a bone animation that these were already skeleton origin matrices, something might be saved.
2 Likes
Sorry guys, still hadnât had a chance to work on this issue
np and no rush