Zylann
commented
10 months ago This instancing system was originally designed for VoxelLodTerrain, and is also designed to re-use the meshes of the terrain. It only works on VoxelTerrain because it was requested, and it wasnt too much work. But indeed, that results in it not benefiting at all from chunk LOD since there is no chunk LOD. And draw calls are high as well, unless maybe you use chunk size 32.
Making this terrain-independent isn't as easy as having a heightmap to decouple all these things. Here it's much harder because this system needs the meshes to spawn things, and they have to match instancing chunks to minimize overhead from fetching triangles and updating multimeshes. If meshes have no LOD, then it will be impacted regardless. Trying to changing it to somehow have LOD when the terrain doesn't only makes it harder to maintain because it still is primarily meant for VoxelLodTerrain. Creating a whole other system only creates more work to maintain multiple systems... so unless there is a way to have a system generic enough and simple enough working in both terrains, I don't know what will be doable here. Also if there was a terrain-independent way to do this, then it wouldnt even have to be in this module. Maybe only need a few hooks, but we'd have to know which ones. At the moment I haven't got the bandwidth to either work or even discuss medium/large design changes, I have other things in progress. But I'll eventually get working in this area in the future during a next iteration of the demo project that uses it (Solar System).
There is however a secondary LOD system which you might have overlooked: each multimesh item can have up to 4 LODs, which are distance-based within a given "chunk LOD". Distance ratios are hardcoded (0.0, 0.1, 0.25, 0.5, 1.0) but it seems to be running too with VoxelTerrain. This secondary LOD is applied per chunk, and just changes the mesh of all instances in the chunk based on distance. It doesn't use Godot's LOD system because it pre-dates it (also not sure if there is an API to control it?). It will not prevent instances from being added all the way, but at least that could help decimate vertex count in the distance, as I see each of your grass instances have many vertices. Later on perhaps it could allow setting "no mesh" for one of these LODs or have more levels.
As for Godot's LOD system not doing anything... it's a bit weird because I thought something would work per-multimesh (not per model instance). If nothing happens at all, maybe that's a bug? Unless I'm missing something I should toggle? Perhaps that should be reported to the Godot repo if you can't get it working manually with a MultiMeshInstance3D.
AimiIsFat
Is your feature request related to a problem? Please describe. I recently had to switch from LOD terrain to non-LOD terrain as I'm developing a multiplayer game and LOD terrain currently does not support multiplayer and I doubt I have the skills (or time, as I am very close to the early access release deadline) to develop a custom solution for that.
The switch went fairly well, except one thing: Rendering all the grass kills your frame rate, even after optimization.
This was an issue I had with LOD terrain as well but to a lesser degree since you can at least limit it to only the first LOD, which was still too much in my opinion, especially for a small mesh that is repeated tens of thousands* of times and only needs maybe ~10 meters at most for the first LOD. However, with normal terrain, it is not possible to limit it at all, and it makes it impossible to increase render distance without either getting rid of the grass or decreasing density, which has already been decreased by a lot.
*To be specific, there are 53,203 grass meshes in the scene below. My computer could handle several times the render distance of that scene if this issue were to be solved, as that grass will kill my frame rate otherwise.
Here is the scene fairly optimized. I haven't further optimized the grass mesh yet but that will probably not get many more frames as the main issue here is the distance at which grass generates and the fact that I cannot implement proper LOD.
(Grass is made by me, though the trees are not mine.)
Describe the solution you'd like I would like a way to use configurable distance-based LOD rather than the current chunk's LOD level. LOD distance shouldn't be uniform for every single object, as small-but-numerous objects such as grass and small rocks require very short distances between LOD levels, as well as a cull distance, while large and rare objects often need large distances between LOD levels.
Perhaps make a separate version of the VoxelInstanceLibraryMultiMeshItem (that is a rather long name) that is instead based on distance, as there is no LOD system for non-LOD terrain.
At the very least, I need a way to cull grass meshes past a certain distance. A simple "cull distance" option would be fine in this case.
Adding multiplayer support to LOD terrain would fix a good portion of the issue but it still wouldn't allow for the level of LOD control that should be a requirement for any game with large amounts of grass.
Describe alternatives you've considered I tried optimizing the grass voxel instance and shader which did bring frames up a fair amount but the issue here is the sheer number of triangles rendering on the screen at the same time. There is no real way to fix this except an LOD system, which is not supported on non-LOD terrain.
I have also tried removing grass altogether, but the scene looks very bad without it. It isn't quite an option to just remove it completely.
Godot's built-in LOD system also seems to have zero effect on anything. Only thing I could get working was distance fade using a standard material but that would not work for this specific scenario, as the grass requires a special shader.