Looking in the docs in the section “RenderingDevice” I found these mentions of tessellation shading but there is no information about how to use them. Any help would be appreciated, thanks.
I never directly dealt with the graphics APIs so take it with a grain of salt:
Godot does not offer hardware-accelerated tesselation without you gutting open the C++ side of its renderer backend.
There’s only the standard Vertex → Fragment → pixel output pipeline and the Buffer → Compute → Buffer output pipeline.
There’s a Pull Request for this, but it’s been 4 years already.
Most major game engines have ditched this and are looking into using meshlets on steroids (split each mesh into smaller parts and generate LODs for those) and visibility buffers instead.
Ah ok, i thought tessellation would enable some interesting LOD possibilities for Rocks and Rocky terrain - something like sculpting and extruding the rock surface using the heightmap of the rock material. This is not easy with the current tech, but can be done slowly in Blender.
I think I am going to use smaller high definition terrains and terrain meshes and simply swap levels a bit (i.e. the world cant be quickly traversed by foot anyway).
The terrain close up had jaggies on my PC as I was having to over scale 2k sized terrains to about 4× for overall scale of 8km x8km. The jaggy low detail rocks became a bit annoying. I will test Terrain3D anyway, but down scaling my map sizes isnt a great loss. Cheers.
This is correct. It is complicated by the growing number of graphics back-ends also. Vulkan would be a good first goal, but it won’t work on e.g. Direct3D or Metal without additional implementations. It also requires modification to the “Ubershaders” and the Godot shader language compiler to add the tesselation evaluation and control stages. Additionally, (IIRC) the shader language needs to be modified to support arrays built-ins.
For what its worth, in my current project I took a much less ambitious approach. You can go a long way by using a MultiMeshInstance3D with a subdivided QuadMesh. It’s not as efficient as tesselation (I presume), but it is not bad. I process my terrain into a quadtree structure and the same QuadMesh can be scaled/transformed for use at any LoD. I simply pass the extents which should be sampled from the heightmap texture as shader parameters. The quadtree is used for additional algorithms like frustum culling, selecting LoDs, and physics optimization. A fairly by-the-book implementation of the CDLOD technique.
That sounds like a good idea - instancing and using vertex displacement shaders.
I’m experimenting with terrain engines … Terrain 3D is seeming pretty good now that I’ve tested some larger terrain textures. The close up geometry can be quite high definition. When I tested before the frame rate was low, and not competitive with Chunk LOD, however now I’m finding Chunk LOD systems don’t run so fast on my computer when they are as highly tessellated near the camera.
I am also considering the wobble in Clipmap terrain when FSR 2.0 is active (something to do with the motion vectors being used by both) - is it worth dropping the FSR and using Bilinear filtering just to run Terrain 3D ?
There is a problem when a lot of addons do the same kind of processing like quad trees.
.