Hi Folks,
I’ve been looking to optimise my scenes, and one thing I realised is that I have quite a few meshes that are of similar “types” (my scenes are race tracks where I have lots of curbs, fences, barriers, etc.). So I thought I’d try combining all of the meshes of the same type, that all share the same materials.
Here’s before combining them:
And here’s after combining them:
As you can see I reduce the number of meshes from 232 to 81, and the number of draw calls from 207 to 67. The docs (Babylon.js docs) say reducing draw calls is good, but I don’t see much of a change in performance on the device I’m running this on. Should I just trust that reducing draw calls and the number of meshes might help on other devices, or is there some potential downside to having a smaller number of meshes, but the same overall number of vertices?
Thanks, Tom
1 Like
Combining meshes is not always a good thing,
here’s a few ways it can go wrong,
- you no longer get frustum culling benefits from babylon, if 1 fence is in view, all the fences are sent to the gpu to render. so that 1 draw call is huge / slow.
- you might choke the pcie bus if you have a single mesh with large amount of vertex data, which means you’ll be stuck doing nothing while the data transfer completes.
- if you have LoDs (a good thing to have for perf), they won’t work as intended as well.
- if you’re sub-500 draw calls, you probably shouldn’t worry about the number of draw calls
The ideal way to optimise, is to profile, figure out the pain points and then tackle the biggest problem first.
for cpu, you can use your browser’s profiler.
for rough estimates on the gpu time you can use babylon’s instrumentation
in general your app can be slow on the cpu but fine on the gpu, vice versa or both
if you’re bottlenecked at, say, managing game physics, reducing draw calls aren’t gonna do you any good 
3 Likes
Additionally to what @Heaust-ops said, merging meshes increases code complexity (assuming meshes are concrete, indvidual game objects) and makes dynamically adding/removing meshes way more difficult. **
Anyway, with regards to the two screenshots. I assume the red line is plotted against y=fps 0 - 60 and x=time in seconds.
Other than the big drop in the 2nd screenshot, I would say there is an improvement. The variance in the 1st screenshot is crazy. Again disregarding the big drop in 2, fps steadily hover at like 50.
As for the lag spike in 2. I would investigate this in any case. You might have surfaced something else there. I would repeat the measurement several times and look over a bigger time frame and see if the lag spike is reproducible.
And to re-iterate: do check the Inspector stats: where do you spend time.
**If I want to destroy a level object, this goes through several classes, I need to edit vertices, merge the descrution debris into a new mesh, edit a palette texture… With instances I would just need a dispose() and a createInstance() call 
2 Likes
