Varying number of meshes per LOD?

Questions
1

I want to implement a continuous LOD system where, say, a mesh at a given LOD can be replaced by more than one meshes at a higher LOD. This is very useful for large spatial extent objects (terrain and others) where you want parts of the object closer to the camera to be at a more detailed LOD than further away parts. Right now calling addLevel() with more than one mesh with the same distance param results in only the last added one rendering at that LOD. How can I achieve what I’m trying to do in an efficient way?

2

addLevel expects an Object3D, so you can add a Group containing as many child meshes as you like!

1 Like
3

Is it one draw call per mesh?

4

If you need to keep everything in a single draw call and have multiple objects (hundreds or more), you’ll need to use an InstancedMesh.

Using multiple Sprites is also a valid option, and if you have variable geometries with the same material, a BatchedMesh could also do the trick.

5

It’s generally true that one mesh is one draw call in three.js. There are certain exceptions, for example if you’re using geometry groups or multiple materials on a mesh, the draw calls will be higher.

The LOD system provided by three.js is pretty simple, it just swaps out THREE.Object3D objects, which (as @Fennec mentions) could have any number of meshes as descendants. Implementing a custom LOD system if you need to do something different would be entirely reasonable too.

1 Like
6

Sounds like adding BatchedMesh to the LOD levels covers my use case, thank you. I guess the only downside is that adding geometry to a batch is a linear time operation as it actually copies the vertex attributes from my quick look at the code

7

The added geometry is copied into the (larger) batch geometry, but that’s a prerequisite to batching the draw calls in any case. If you allocate enough space in the batch (that is, set a high enough maximum size on it that it doesn’t need to be reallocated every time you add a geometry) that’s probably OK.

Writing a version of a loader that puts vertex data directly into a shared BatchedMesh and/or Geometry — without the intermediate step through individual Meshes — would be a nice experiment.