Is there a way (or any benefit) to doing level of detail with the same mesh, but a cheaper material? I have 1000 meshes, most of them with different materials (actually the same material but different uniforms and a different albedo texture), but you can only see the nearest 30 meshes nearby at any time, the other meshes are just in the distance. I’m currently rendering those distant meshes with a simple white color, which looks good to show that there is geometry there, that blends into the fog.
What I would like to do, is to add a level of detail, so that at 64 meters away, I render the same mesh, but with a plain white material. Is there any benefit in doing this? Or is there no overhead in rendering each mesh with a different material?
Also - is there a way to reuse the material shader code so that it doesn’t have to be recompiled for each instance of the material? I’m using PBRCustomMaterial.
Example scene (not loading individual textures for each mesh yet):
hi.
yes you can take benefit from render distant meshes with same material for them all. each material is drawcall and if you have more than 350-400 drawcalls for desktop app you have problems)) but you dont take benefits from lods… you use same geometry and this dont have sense in lods. so maybe you need merge inactive meshes into one https://doc.babylonjs.com/how_to/how_to_merge_meshes? and use one material for merged mesh or multimaterial https://doc.babylonjs.com/api/classes/babylon.multimaterial if you need reuse your original materials but in more optimal way or simply create and use ONE material for all distant meshes and dont forget dispose inactive materials. it will help optimize your drawcalls zoo)) and if you can use multimaterials at start point… aaand welcome to autolods https://doc.babylonjs.com/how_to/in-browser_mesh_simplification but i dont try this feature and cant say something about this
For what I know
the minimal number of draw call is : (nb of standardMaterial per mesh) x nb of meshes
Using LOD just reduces the geometry size, not the draw call number.
The draw call number can be the bottlneck, but it’s not the only one : many many meshes can mean a big number of frustum checks or a big number of matrix computations.
So, knowing this, as there are usually far more meshes than materials, the some efficient ways to reduce the draw call number is first to act on the meshes :
if they don’t move/scale/rotate, then freeze their world matrices
if they don’t move, maybe use an octree to speed up the frustum mesh selection (or implement your own)
Well only if you are gpu bound (easy to test: does it go faster with lower resolution?). If youare gpu bound then simplifying the material will help (like turning light off).
Regarding shader compilation: it only happens if a new combination of parameters is found. This means that if you have a white material with light, a white material with no light and a PBRcustom material you will compile 3 times at the beginning.
If you are not GPU bound (which I think you are not:)) then the number of drawcalls is the “problem”. You have to use instances as soon as you can for instances. Or remove meshes earlier maybe
