I have a pretty generic question about animations and performance. I am making a game where I have these different characters that cannot be instantiated; they need to have separate meshes, textures and animations. I also made a small stress test illustrating the situation, take a look: https://playground.babylonjs.com/#S7E00P#51
Now, the framerate drops quite significantly if there are tens of models in the screen at one time. I can of course see some obvious optimizations, like stopping the animations if they are not on screen and the amount of player characters on the screen at the same time is usually below 10 or so. But in some critical moments there might be a lot of players on the screen simultaneously and perhaps some enemies with their separate animations as well…
So the question is, what are the best ways to optimize these situations, where there just are a lot of animated objects on screen?
I guess the easiest one is to try to have less bones in the models… This example with alien head works a bit smoother and I assume it is because it has less bones: https://playground.babylonjs.com/#S7E00P#52
Yes, most of the time in your PG is spent in animation methods or in the TransformNode.computeWorldMatrix method. So, except by reducing the number of animated objects / the number of bones, I don’t see a way to improve the performance.
The number of bones will drag down performance. Especially with as many bones as you are using.
You can merge bone-weighted meshes as well as long as they share a skeleton. So if your meshes don’t change that often, you can merge all individual parts as well.
If you want to get creative with instances, @phaselock and I played with instanced skinning in the past: https://playground.babylonjs.com/#D2SWZ7#10
You can use attributes like the remaining color channels or UV2 to handle different textures for different instances, but I’m not quite sure this is what you’re after.
I’m not clear on your use case so just sharing some dev/testing and past experiences, if
a) you have 1 common skeleton and many separate meshes sharing the same skeleton/anims and each mesh is controlled by 1 client, ie, mmo setting, as long as your mesh is low poly with low bone count, it is technologically possible to have up to 50 on screen at 1 time in a low poly scene. This is warcraft/minecraft mmo tech, which is about 10+yrs old. The bottleneck here is syncing up N clients reliably which html5 alr caters to as far as 2d games are concerned. In wc mmo, the raid limit is typically less than 50 characters and they also impose zone limits to reduce instance server loads. So per client load is always limited to ensure realtime playability. This is something you have to do on your own end. Imho, based on past bjs low poly mmo demos submitted by other users, it should be possible to get <10 bjs clients synced and interacting. Feel free to browse our Demo and Projects section. As 5G standards evolve and systems getting buffer, I fully expect this ceiling to lift up.
b) you only need many npcs (think starcraft swarms) that animate separately and share the same base mesh but with different textures, you can consider using VATs (Vertex Animation Textures). We have an entire thread on it and bjs has proven itself here as it is possible to offload processes to gpu. Bottleneck here is how buff the client side system is and that is where you need to target client-side system.
c) last but not least, you can consider particle systems. We have excellent documentation on it. Feel free to refer to those.
Ultimately, good perf is a result of how you cast your limits and structure your scene so client-side gets best experience. Hope it helps.
