Optimizing cloned/instanced meshes playing separate animations

Hi all :slight_smile:

I was playing around with getting a group cloned/instanced meshes to play their animations separately, and in general trying to see if one approach works better than another in terms of performance. Are there any other tricks I could be using to squeeze out even more performance (fps, lower memory usage) in either case of using clones vs instances?

I wondered this a bit in the past as well. It is a bit complicated topic and I think depends on your use case…

Check out this thread:

Thanks for sharing!

This random variable that doesn’t get used is cracking me up right now :laughing:

const meshTask = assetsManager.addMeshTask(‘Very nice task’, ‘’, path, fileName)

This is definitely useful for exploring the curve of n-entities vs fps for both instances and clones as you scale up the number of entities with animations playing.

1 Like

Note that by default instantiateModelsToScene will always clone meshes if they have a skeleton, even if you set doNotInstantiate = false. If you want to force instanciation in this case, you should pass () => false for doNotInstantiate.

However, doing so will prevent you to use a different animation for each instance: all instances of a mesh share the same animation.

Since 5.0, we added Baked Texture Animation, if that can help:

2 Likes

That’s super interesting to learn. So it sounds like in the playground I set up, those birds are always cloned? Yet I thought I had seen a consistent difference in the fps as measured by the babylonjs inspector.

I tried it out as you said, opts = { doNotInstantiate: () => false } and observed all of the instances animations play as one.

A limitation of the current VAT implementation is that you cannot blend animations to play simultaneously. Also, the animations may not be as smooth as when not using BVA because there is no interpolation between frames. The “smoothness” will depend on the number of frames of the animation.

So it sounds like if I wanted to do a large flock of birds in the distance this could work but otherwise is too rigid to work in a game setting where birds close to the player need to be able dynamically stop and go… is it possible to use both baked animations and regular animations on the same model/instance?

1 Like

Yes indeed.

I think it should be possible, but not at the same time, as there’s a BakedVertexAnimationManager property on the mesh that you can disable by doing mesh.bakedVertexAnimationManager.isEnabled = false.

2 Likes

Wow, if that’s the case, that makes some really cool stuff possible. Say for example we have a flock of ducks, animated as flying and moving forward on a given axis at 3m/s:

d0 d2 d4 d6 d7 … d500 … dn-1
d1 d3 d5 … d300 … dn ~~~> 3 m/s

If the game allowed it, the player could click at random any duck in the flock, and that particular duck instance could then be switched over from a baked animation, to the regular more dynamic animation system and do something to display different behavior from the flock?

Yes, it seems it could be work, but you will really know once you test it :wink:

1 Like

Finishing up some code, and there’s a thread I need to respond on first, but very soon I think I can set up a cool pg to demo it. I’ll also have to learn about baking animations first, but that looks easy enough :slight_smile:

2 Likes

Really interested seeing your pg!

Also wondering if WebGPU could provide any help in this matter… :thinking:

1 Like

WebGPU will change the game completely :slight_smile:
drawcalls will no longer be such a huge limitation it is today,
and you’ll be able to just have 100’s of clones playing separate animations

I remember seeing @Deltakosh showing this in a video once,
this version was just what i found from a quick google :slight_smile:
i believe it’s 10000 static clones in each scene.

I wish it could be validated already… Trying to run my example from the other thread gives bazillion errors in google chrome canary with webgpu turned on :crazy_face:

This could be useful, too

Bone matrices are still calculated on the CPU though, so the only win is fewer drawcalls

1 Like

Pretty cool!

There is additional requirement at least in my case, since I need some specific trickery with lighting as well and that sorcery only works with clones…

Hypothetically would it make sense to have bone calculations done in a wasm module and it would just write the results to a shared buffer array that babylon.js would internally reading from?

1 Like

Really interested seeing your pg!

Yeah, getting around to it soon-ish, lol, I just keep getting side tracked by things that I need to do first.

1 Like

Feeling you :rofl: