Little gpu terrain test

Thanks. I implemented a terrain in a different approach that probably wouldn’t work for my need long time ago. I was thinking to use quadtree to start from scratch again. But then I shifted my interests and didn’t revisit this topic. :smiling_face_with_tear:

1 Like

@imerso and @arcman7 reminded me a PoC I did long time ago. It is probably my first project with babylon.js and GLSL. I found a video I recorded for my terrain editor.

I followed a different approach to implement the LoD terrain above. I want to discuss some of my thoughts of this approach. And get some inputs on how a large open world could be built.

Features of this terrain:

  1. Terrain mesh has 3 LoD levels. Instancing is used so only 3 draw calls for these terrain tile meshes.
  2. Camera has fixed position and it can only rotates.
  3. When navigating with mouse/keyboard, camera doesn’t move. But uv offset is updated to the vertex shader. The vertex shader updates the height value in GPU.
  4. T-junction problem on the edge between two terrain tile meshes with different LoD levels is also fixed in the shader. Vertex shader sets the height value of the red vertex (see image in the T-junction link) to be the average of vertex above and below it.

Pros:

  • Because of 3, it doesn’t have much significant CPU computation. Not captured in the video, but I was use an extremely large heightmap image and split it into tiles. Then dynamically load / offload heightmap image tiles in the browser as a user moves the terrain. I think it would work for our whole planet’s elevation data.

Cons:

  • Since it updates height data instead of moving camera, I feel it might not work if there are other objects on the terrain. Since I will need to keep updating their positions even for all the static objects.
  • I didn’t know custom material at that time. So I implemented the shader outside babylon.js. So I had my own vertex normal calculation, surface brightness based on the normal and light direction, triplanar mapping, multi-terrain blending. It was some good learning experiences, but I realize it is probably going to take forever to have all the required features for the terrain.
  • Then I searched a bit more and found quadtree approach. I was too lazy to restart from scratch again. Then I fell in love with lowpoly style and would like to learn animation on GPU instances. So I stopped working on the terrain.

If I was going to build LoD terrain again, I guess I will use quadtree like @imerso did. But I don’t know if 1 big mesh would be sufficient? @imerso Is your planet a single mesh, or you also applied tiles that are dynamically loaded and destroyed?

4 Likes

I had no idea you can navigate the map/environment quickly using only the gpu to do UV transforms. If that can can be made for general use that would be awesome.

Also I made a script that automates a lot of what you’re doing when you split a model into a grid (including splitting the images and stitching them back together):

(sorry about the long load)

I could use some pointers in getting rid of the stitching artifacts (the seams are just barely visible).