🔒 Locked

Procedural heightmap for terrain

Started by mancubit Mar 27, 2011 at 9:19 PM 9 replies 7.7k views

Original Post

Mar 27, 2011 at 9:19 PM

I am currently trying to render a planet to simulate atmospheric scattering. As for the planet body i am using the exposed cube method with chunked size lod (implemented as a quad-tree). Currently i am using a static heightmap on all six cube faces, which looks ok from distance but lacks proper details when the camera is near the surface.
Therefore i am searching for a way to generate heightmaps proceduraly. What i need is some algorithm that lets me generate reasonably realistic heightmaps and lets me adjust the degree of details added. I have already read some articles but feel kind of lost as i am new to procedural content generation.

What is a good (and not to complicated!) method to achive good lod-terrain rendering? I would be glad if someone can push me in the right direction.

Thanks!

Postie

Mar 27, 2011 at 11:12 PM

The project I'm currently working on makes use of procedural terrain and in my research I found this post:

http://www.float4x4....in-height-maps/

That, and the reference paper he mentions were a very good base for what I needed.

I also went out and bought the book, "Texturing and Modeling, Third Edition: A Procedural Approach". It's a little old now (published in 2002), but I found it still had a lot of relevant information in it.

mancubit

Author

mancubit

Mar 28, 2011 at 1:23 AM

thx, the link is very useful!

The only thing that makes me worry is, if the CPU is fast enough to create the heightmaps in realtime. As this is what i want to achieve when the camera moves/zoomes on the planet surface.

matt3d

Mar 28, 2011 at 2:40 AM

thx, the link is very useful!

The only thing that makes me worry is, if the CPU is fast enough to create the heightmaps in realtime. As this is what i want to achieve when the camera moves/zoomes on the planet surface.

You could look into off loading this onto the GPU with a vertex shader, I am doing the same thing right now.

Postie

Mar 28, 2011 at 8:18 AM

thx, the link is very useful!

The only thing that makes me worry is, if the CPU is fast enough to create the heightmaps in realtime. As this is what i want to achieve when the camera moves/zoomes on the planet surface.

The only way to find out is to try it and see if the performance is acceptable to you. I doubt it's a new problem, so I'm sure there are resources out there on optimising the process, or offloading to the GPU as suggested by lotusf1.

Actually, I remember reading somewhere that the guy behind the independent mmo Infinity uses a technique like that, but I can't for the life of me remember where I read it to confirm it for you.

Edit: After trying again, I found these:
http://archive.gamedev.net/community/forums/mod/journal/journal.asp?jn=263350&cmonth=10&cyear=2008
http://archive.gamedev.net/community/forums/mod/journal/journal.asp?jn=263350&cmonth=11&cyear=2008
http://archive.gamedev.net/community/forums/mod/journal/journal.asp?jn=263350&cmonth=1&cyear=2009

though he actually mentions in the last one that he's moving the geometry generation back from the gpu to the cpu because of precision problems.

GregMichael

Mar 28, 2011 at 8:23 AM

When I did something like this I did it all on GPU - very fast. Only problem I found was that generating the height map on GPU, was getting data back for collision detection. Not an impossible problem to solve though....but I've stopped working on it for now.

matt3d

Mar 28, 2011 at 11:39 AM

When I did something like this I did it all on GPU - very fast. Only problem I found was that generating the height map on GPU, was getting data back for collision detection. Not an impossible problem to solve though....but I've stopped working on it for now.

Not to hijack the original posters thread but as I recommended GPU as well, do you have any advice for how to get the height data back from the gpu? It is a part I actually do not quite understand yet. I would think you would need it back both for collision and error metrics (calculating which terrain patches are closer to user)

In my implementation I am only using Shader Model 3.0 (restrictions of engine I am using).

mancubit

Author

mancubit

Mar 28, 2011 at 4:25 PM

thx all for your answers

i have managed to implement perlin noise using the gpu - i am currently not rendering a heightmap - instead i am using the noise directly to manipulate height in the vertex shader.

here is a link to an perlin implementation on glsl - i ported it over to hlsl (although for some reason simplex noise doesn't work yet - so i am using improved perlin noise instead)
http://staffwww.itn.liu.se/~stegu/simplexnoise/

currently i am modulating finer noise as the camera - surface distance decreases. Its not really realistic in any way but it looks ok for now - guess i need to take care of the resulting terrain cracks first before going on

GregMichael

Mar 28, 2011 at 10:07 PM

Why do you get terrain cracks ?

Even with different LOD's next to each other if you are careful about your triangulation / indexing this can be avoided since it's all procedurally generated. What I mean is you can generate (calculate) the height at each vertex on GPU and this should always be the same no matter what LOD you are rendering if the input to the noise generation is the vertex position (on the planet).

mancubit

Author

mancubit

Mar 29, 2011 at 3:16 AM

good point..

the problem is, that i am modulating higher octaves on the previous-lod noise in more detailed chunks, but i guess lerping the height between these two lod stages depending on camera-distance will do the trick. Unfortunately i haven't had any time yet to take care of the terrain cracks - maybe tomorrow

spacerat

Jan 10, 2014 at 8:46 AM

If you want to create nice terrains that look similar to complex eroded ones, use Diffusion-limited aggregation.

I explain the computation in my recent blog post.It might be hard to generate it on the GPU in real-time however.

Topic Locked

This topic has been locked by a moderator. New replies are not allowed.