I am trying to figure out the best way to boost performance. I have several terrains made in Blender that I've imported. Most of them have a high amount of faces/vertices and I want to decimate them as I get far enough away. I tried using the built in LOD but it seems to be inconsistent as it takes resolution and other factors into consideration.

I have 2 other things I have thought about doing. One would be to create 2 scenes for each terrain chunk. One would be the hi-res model and the other would be decimated. The I can add and delete them from the main tree as the character gets to the establish range.

The other option is to just have two MeshInstance3Ds in one scene and use the Visibility Range in the inspector to swap between which mesh is drawn.

I don't really know the pros and cons of each or if there's a better way.

Any input would be great. Thanks.

Lethn I'm wondering how this is different than Godot already supporting frustum culling. My understanding is Godot already stops drawing objects that are not on the viewport. I tried setting up several of my landscapes using this

func _process(delta: float) -> void:
	if $"../VisibleOnScreenNotifier3D".is_on_screen():
		visible = true
	else:
		visible = false

It doesn't seem to make any difference to the data values listed in the Monitors box while in Debug. Does changing visibility do something different than frustum culling I'm not seeing?

      jfirestorm44 I don't have enough knowledge on the engine to answer that, but the best thing you could do is just test it out and see.

        Objects are automatically culled for 3D rendering. The visibility notifier is more useful for stopping scripts and/or deleting objects (for example in a runner or scroller type of game).

        Afaik this has no easy solution in the engine.

        For larger terrain one would have to make an extension (in C++) that modifies the terrain surface, performs dynamic loading and unloading of terrain, collisions etc. This would be too slow to do in GDscript.

        2 LOD levels are not enough, something that keeps the number of triangles per screen area roughly equal, and moves with the camera, and loads and unloads parts of the terrain as the player moves. Also, it shouldn't copy terrain data for LOD levels (like for example mip maps) but work with and adapt the highest detail level on the flight. Memory is the limiting element here, even with just 16bit per point of terrain on the map we're talking about many gigabytes for large terrains.

        There are several well thought through terrain LOD systems, I am a fan of cdlod. I do have the core of such an LOD system. But I am unsure if I can integrate it in the engine's scene tree, which I may tackle once 4.0 is done.

        I appreciate everyone's answers. I'll continue to try to get something working to improve the performance. I'll look into some other LOD systems to see if I can implement something similar.

        imo the performance bottlenecks with terrain is the sheer num of triangles that make up the terrain mesh, I think it's probably easier to reduce number of vertices or clipping in modelling software, since godot's LOD is more friendly to individual model like a spaceship or car or tank etc, but it's not intended for optimizing terrain trigs.
        Though that's just my 2 cents.