Optimization : Freeze active meshes, Merging, Instances

Questions
1

Hello, I have ran into performance problems like I always do when I add something new to my game (seems like that I am spending 70% time on optimizations and 30% on actual development - but it is probably my bad).

I have three specific points to discuss

  1. I have discovered one pretty powerful opimization option - scene.freezeActiveMeshes()

But it behaves weirdly in combination with particleEmitter - when scene is “frozen”, then particle emitter attached to some mesh doesn work. I am not sure whether it is a bug or not, but I dont see any relevant reason why particle emitter shall be somewhat dependand on it ? That mesh is visible and thus active, but particles doesnt appear or move.

If this would seem like a bug rather than feature, I will try to replicate it on playground.

Overall this scene.freezeActiveMeshes() gave me really nice FPS boost, it would be really bad to lose it all because that partifcle problem.

  1. Another nice optimization is merging meshes together

But supposedly we can only merge meshes of the same material and I have one question - is there any possibility to have something like “texture sprite” that would behave like one single material but provide more than 1 texture ?

For example I have “barell” it is cylinder with caps - cylinder has different material than caps thus it must be two different meshes (even if they are always stick together so perfect candidate for merging).

I asked because I have seen years ago with 2D library PIXI.js that there were feature that offers this possibility - use texture sheet and then final sprites could be merged into one but each with its own texture (taken from that sheet).

  1. Instances vs Light includeOnlyMeshes array

In my game there are many pointlights with rather small range in corridors - to handle it well fps-wise I am manually controlling array of enlighted meshes for every light (because most of my scene is static).

So far it works pretty well - ever light only lit to lets say 10 - 15 meshes instead of 200+ but I have problem with instances here. I cannot add / remove instance to/ from enlighted array - it only works with parent (and then all instances are either in or out of it). I can understand that it is how instances behave and have to live with it but cany someone explain why there is such limitation ? And is it something that cannot be changed ?

If instances could not be managed this way - than I would need to know whether is there some overhead by light at all instances ? When they are “the same mesh”, then maybe I can just put that parent into enlight list and do not worry. Something like “if at least 1 instance shall be lit, then just lit the parent of them”.

Thanx in advance for some tips and insight guys. Have to say that Babylon is really cool, but that performance problems are tough nut to crack (which I mostly blame WebGL itself for).

1 Like
2

Hey that’s the life of any game / 3d developer :slight_smile: The perpetual fight against fps!
So to your questions
1- When the scene is frozen, everything is frozen: this means that if you attach a new emitter later on , you will have to call unfreezeActiveMeshes() then freeActiveMeshes again to update the list of particle emitters
2- We recently improved the mergeMeshes to support multimaterials. That is not quite what you describe though. In your case we would have to create a texture atlas for each texture of the merged materials (providing they are compatible). I would then recommend doing it on the offline side of the house as this would be something static
3- This is something that cannot be changed due to the way instances work. They are utlimately just an array of matrices used by the shaders to render not once but multiple time the same data (only world matrix will change) and thus this is why it is utterly fast. Regarding adding the parent when at least one is lit, this is something you will need to benchmark. Technically a single light is not a big deal when everything is running on the GPU (which is the case here). but it is worth testing it

I bet you already read that but just in case: Optimize your scene - Babylon.js Documentation

Optimizing a webgl rendering is a tough task, but even though this is not obvious, babylon.js is already doing the heavy lifting for you with all the shader optimizations, the caching system, the transparent support for webgl2, etc…

3

Thanx for your reply, I would have to swalow all that info :slight_smile:

Ad 1) Can you look there ? I have created emitter and freeze after its creration (one second later) and it still stopped to emit partciles. I tried to use alwaysSelectAsActiveMesh = true and it didnt work either :frowning:
It is clear that I have to unfreeze - change - freeze again, but it doesnt seem to help or am I missing something ?

This freezing is so huge improvement except this little (but important) thingy :slight_smile:

https://www.babylonjs-playground.com/#WBQ8EM#50

And once again - I am well aware that Babylon does LOT of hard work for us and that there are problems that you just cannot work around. But you have created really complex library and it is really difficult to embrace it all, but I am learning something new every day so far :slight_smile:

4

Oh sorry I forgot to mention one thing, the freeze is also freezing the particle system (from animation standpoint).

Quick fix: https://www.babylonjs-playground.com/#WBQ8EM#51

Regaring your last point: I did not want to seems rude, it was more informational :smiley: Bjs is really a large beast. I would love to make it as simpler as possible and that’s why I invest a lot of time on the doc :slight_smile: But please feel free to me if you think we can add more

1 Like
5

Thanx for this fix !! I would never figured that myself :slight_smile:

Particles aren´t “true meshes” right ? Thats why I would never guess that freezing active meshes would freeze particles too.

I understand that it is almost impossible to cover everything by documentation. I am working (in my job) 10 years on one single application and every attempt to “lets document this finally” failed utterly as it is just too complex, so only real complete documentation lives inside my brain :slight_smile:

You are doing very well !!

1 Like
6

Thanks I appreciate your kind words