8 replies to this topic

[Noddybear]

Hey guys,
This is my first post here, and I basically joined to post this because I'm having some issues with various different LOD algorithms.
I'm trying to create a dynamic real-time level of detail system to render a huge terrain. If rendered with brute force this would result in millions of
polygons, so it would obviously be prudent to use LOD.
I've attempted this in XNA several times to build a viable model, and so far i've used ROAM, Geomipmapping and of course Quadtrees, as well as a combination of the last two.
None of these were really optimal for what i'm trying to achieve, as in all cases they sucked up too many CPU resources (With geomipmapping being somewhat precomputed)
The question that i'm asking is what good algorithms (or combinations of algorithms) could I use to bring down by CPU usage? I'm switching over to C++ with DX11 so i'll have access to tesselation and the geometry shader on the graphics card, but my area of knowledge doesn't really include these... Should I attempt to implement some GPGPU calculation? Some way down the road i'd optimally like to use another algorithm like marching cubes as well for the high res LOD so it'd permit me to create overhangs in the terrain and such...
Thanks!

[web383]

I'm trying to create a dynamic real-time level of detail system to render a huge terrain

Does this mean you want your terrain to be dynamic? Or will it remain static? Can it all fit in memory or will you be streaming in data?

Usually if your CPU usage is too high, you can back off on the triangle culling and trying to find the 'optimal mesh' for the GPU to render and just do more brute force. ROAM is definitely out of the question... maybe look into Chunked LOD if you are using a static terrain, which will put more work on the GPU.

[Krohm]

so far i've used ROAM, Geomipmapping and of course Quadtrees, as well as a combination of the last two.
None of these were really optimal for what i'm trying to achieve, as in all cases they sucked up too many CPU resources (With geomipmapping being somewhat precomputed)

That's extremely suspicious. Geomipmapping, as all chunked LODs techniques can be extremely fast. When the required LOD is computed by quadtrees, I would expect it to go even faster (I used a linear scan).
I'm somewhat inclined to say your program has an issue outside the LODding systems. Considering ROAM is totally dynamic in nature... you're not uploading the data each frame are you? How big is your average batch in unique vertices and how many batches are you sending? Do you have evidence the LODding algorithm itself is bottlenecking?

Edited by Krohm, 17 May 2012 - 01:14 AM.

[Noddybear]

I can't really justify computing all vertices and then uploading them to the GPU in a buffer, because it tends to completely fill my video memory :/ It means i'll have to stream in data as i compute it, and then unload it when im done...I agree that roam is not really a good solution. The kernel of the problem is just the processing time it takes to calculate positions of large chunks of terrain (which is what i've been doing with geomipmapping) so what i'd really like is a method to somehow collect indexing chunks together so i could run geomipmapping with quadtrees using smaller chunks of vertices without incurring the costs of rendering to the screen each block individually At the moment each chunk has its own index and vertex buffer

[kauna]

Hello,

I use a quad tree terrain with a couple of 4096x4096 floating point textures. Each node in the quad tree uses a static 33x33 size mesh (which is actually computed in the vertex shader so no vertex buffer is used at the end). So each node is practically is just a transform matrix which is used to create the world xy position of the vertex. Using the world position the corresponding height is read from the floating point texture. Subdividing the quad tree doesn't really take much of CPU power since no geometry is processed.

The textures are updated in same fashion as used in the nested grid terrain. Look for toroidal updating of textures.

Why I don't use nested grid for the mesh? Well, I figured decals and nested grid terrain don't mix so well since the geometry changes all the time when the camera is moving.

Best regards!

[Noddybear]

Ah that sounds interesting! I'm using Simplex noise to generate my terrain so I could move it over to the vertex shader I guess... Although I have a feeling that it'd be a bit of a bitch to port to hlsl! Is the transform matrix stored in the textures? Btw, my current node size is about 65x65 because I was under the impression that rendering any number of triangles below about 4k would take the same time as 4k to render
-Thanks!

[kauna]

You may store your matrices as you wish, but as far as I know, the constant buffer storage is slightly preferred. I use constant buffer in this particular case.
Also, since most of the data (textures) is shared between the quad tree nodes, I can draw the whole terrain with few draw commands by using instancing.
You may test different grid sizes. Maybe 65x65 grid is faster / slower in some cases?

I think DICE is using tesselation in their terrain implementations. Search for FrostBite engine slides on the internet.

Cheers!

[Noddybear]

Ah so you just draw one of each size terrain chunk, instance them to fill everywhere else, and then use the vertex shader to change the heights? Thats very crafty! I never thought to do it that way... I guess that instancing wouldn't work if you were building planetary terrains because of the curvature would not be easy to instance Does your technique use any geomipmapping as well?
-Thanks

[kauna]

I have to admit that I haven't implemented morphing. At this moment I try to keep the mesh as dense as possible so that popping isn't that bad in the LOD changes.

For planetary scale things, if you are using square grids for drawing, then you'll need some extra math, but I assume that it isn't impossible to go with the same road. Well, there are lots of things to consider with a planetary scale renderer.

Cheers!