Jump to content
  • Advertisement
Sign in to follow this  
Cristian Decu

Terrain Rendering

This topic is 933 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Hello fellow game programmers,

 

After finally reading most of the forums and articles related to terrain rendering, i think i reached a conclusion.

I just wanted to share with you my ideas and leave this thread behind any other people looking for such a subject.

 

The first problem that i came into was, obviously, solving the cracks between different LODs. Not a trivial thing

to do, however, after proper documentation and experimentation i reached a final conclusion.

 

I will use a quadtree to split my terrain into multiple patches. I will have only 1 VBO containing 33 x 33 vertices,

and multiple IBOs(16 i think). Each IBO has one or more edges altered so that it fits the neighbouring patches.

Now i need to make sure that the LOD level difference is not higher than 1, but that shouldn't be a problem.

 

Now, why one single VBO?

Well, i see no reason to use multiple VBO since i can scale down my patch.

For instance, a level 0 patch of 33x33 vertices splits into 4 33x33 patches having 0.25 the size of the parent patch.

(33 x 33 vertices means a width and height of 32, i love numbers that are a power of 2, probably an OCD or something.)

 

One single VBO for the whole terrain, multiple IBO for solving the cracks.

The downside is that i will need multiple draw calls, but i don't see that being too big of an issue.

If it misbehaves, then i could probably optimize this a little bit by merging some of the patches into a bigger VBO, thus reducing

the number of draw calls. Moreover, frustum culling and horizon culling are going to significantly cut down the number of draw calls per frame.

 

One thing i can't get straight however is how can i implement geomorphing with this technique. I'm thinking i could use an attribute that would slowly

interpolate the position of my vertex, but that means that for a while, i will need to update the attribute buffer every frame, not sure my GPU is going to like it.

 

What do you people think?

Is it ok? Can i do it better?

Edited by Cristian D.

Share this post


Link to post
Share on other sites
Advertisement

Now, why one single VBO?

Well, i see no reason to use multiple VBO since i can scale down my patch.

For instance, a level 0 patch of 33x33 vertices splits into 4 33x33 patches having 0.25 the size of the parent patch.

(33 x 33 vertices means a width and height of 32, i love numbers that are a power of 2, probably an OCD or something.)

The question is why do you need a VBO at all?

With modern GPUs, you can compute the XZ position via gl_VertexID (gl_VertexID / verticesPerRow; gl_VertexID % verticesPerRow); and grab the Y component from the heightmap texture.

Share this post


Link to post
Share on other sites

Terrain via heightmap textures was one of the first big uses of programmable GPUs.

 

Incidentally, it also destroyed my masters thesis work where I was working on continuous level of detail for terrain at the time. People in my lab said "You need to see this announcement." It was a press release for the GeForce 3, and the demo video was about 100 square miles worth of terrain being processed with newfangled "shaders".  

 

With a single shader and a heightmap, the card does all the work to display all the ground geometry for an enormous area. No terrain mesh needed, just the height map that the shader uses to figure out all the heights.  You still need to throw on textures and modeled objects, but those are not that difficult.

Share this post


Link to post
Share on other sites

What you propose is a little old school. A step up from CPU based ROAM but a step down from modern geoclipmapping (a monolithic draw for all the terrain). At the newer end of the spectrum, you could have a single grid that uses tessellation based on distance and rockiness. Depends on if you want to support DX9.0, 10, 11.1 or 12.

Share this post


Link to post
Share on other sites

For now i'm thinking to stick around OpenGL 3.0 since 4.0 and earlier is not that widely adopted as far as i know.

 

 

 

With a single shader and a heightmap, the card does all the work to display all the ground geometry for an enormous area. 

 

Now this is interesting. You're saying that without sending any kind of geometry to the GPU, the GPU is capable of rendering a terrain

based on a heightmap? I'm thinking this would be really fast.

 

One disadvantage of this seems to me to be the collision detection. Even if i generate the mesh entirely on the GPU, then i'll have to somehow probe

some regions of it to test it for collisions. Nonetheless interesting.

 

I need an approach that could do well on OpenGL 3.0 so there's no tessellation shaders for me.

I'll still need to send some geometry to the GPU in order to make this work, it seems to me that the 1 VBO approach can be really slow.

(No frustum culling yet, but i expect a 20% - 25% frame rate increase).

 

I need something that could easily be adapted for spherical terrains.

 

 

 

modern geoclipmapping (a monolithic draw for all the terrain)

 

That means that i need to fetch the geometry out of my octree, test it against the frustum planes, weld it, stitch it, remove the cracks and then upload it to the GPU.

That seems a little complicated, but then i'll be able to render everything with one draw call, so it should be fast. Maybe the geometry fetching part could cost my CPU

a bunch, but when i think of it again, maybe not that much. And texturing could prove a pain in the neck since by sending everything at once, you'll need to texture everything

as a whole, leaving me to find a proper way of distributing different resolution textures across the tiles (we won't have anymore tiles after stitching everything up, isn't it?).

 

I love this, so many techniques that i can use, all with their pros and cons, i'm not going to get bored this summer folks!

 

Thank you for your support!

Edited by Cristian D.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!