Sign in to follow this  

Texturing my procedural terrain.

This topic is 396 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!

 

I´ve been working on a procedural-infinite-chunk-based terrain system  :huh: , last week I started to work a bit on the terrain shader. Right now I just have 2 textures, and I weight them depending on the normal of the surface:

 

   
// Get slope    
float slope = pow(dot(float3(0.0f,1.0f,0.0f),normalize(pin.NormalW)),5.0f);
float4 albedo = lerp(albedo1,albedo2,slope);

I use "pow" as an intensity for the second texture, so it will show up sooner. This gives quite boring results:

 

JSHC6lR.png

 

 

I would like to achieve something similar to this:

maxresdefault.jpg

 

I´m not sure if I have to work on the terrain generation ifself or maybe tweak the shader (or both).

 

See you!

Edited by piluve

Share this post


Link to post
Share on other sites

Some topics you might want to look into:

- normal and/or displacement mapping

- triplanar mapping

- sampling your textures at multiple UV frequencies to hide repetition

- detail textures up close

- procedural geometry details (example)

- better blending (example)

- better initial procedural geometry/texture generation (good book about it)

Share this post


Link to post
Share on other sites

You're going to want to use something more like conventional fractal noise to achieve the rugged mountainous appearance, because right now you're working with just smooth rolling hills. Secondly, I'd incorporate the use of normal maps to provide more detail to underlying rock along with calculating the blend of the textures using the normal mapped triangles, to give a more detailed transition, instead of low-frequency per-vertex blending.

 

You could get into displacement mapping, but I'm more inclined to just throw more triangles at the GPU. My reasoning is that whether you're drawing lots of little triangles or a few big ones, it's going to be performing the same amount of rasterization on the screen. Many texture accesses for a single fragment when displacement mapping means slower rasterization for a given screen area taken up by the geometry's projection, whereas producing equal amount of detail that is always using only 3 accesses (normal map, and the two textures being blended together) per fragment would be faster. GPUs are happy to take on a fat chunk of vertex data and fly through it these days, so all the hacks and tricks to extract more detail from low-poly meshes are inevitably going to become obsolete.

 

The key here is a good LOD system. I am personally fond of tessellation shaders, because the detail is entirely figured in screen-space, as opposed to having different levels to transition between. It will always render almost exactly the same number of triangles on the screen, regardless of how close or far the terrain is for a given perspective, which means consistent rendering time.

 

Basically, your existing shader will work just fine if you just throw more detailed geometry at it, and as I said above, get some fractal noise going on in there and you'll be able to create terrain with much more character. You'll probably also want to try fractal-application of your textures, where you blend multiple scalings of them together to produce more variety and less repeating pattern appearances.

Share this post


Link to post
Share on other sites

Some topics you might want to look into:

- normal and/or displacement mapping

- triplanar mapping

- sampling your textures at multiple UV frequencies to hide repetition

- detail textures up close

- procedural geometry details (example)

- better blending (example)

- better initial procedural geometry/texture generation (good book about it)

 

Thanks for those links! 

 

You're going to want to use something more like conventional fractal noise to achieve the rugged mountainous appearance, because right now you're working with just smooth rolling hills. Secondly, I'd incorporate the use of normal maps to provide more detail to underlying rock along with calculating the blend of the textures using the normal mapped triangles, to give a more detailed transition, instead of low-frequency per-vertex blending.

 

You could get into displacement mapping, but I'm more inclined to just throw more triangles at the GPU. My reasoning is that whether you're drawing lots of little triangles or a few big ones, it's going to be performing the same amount of rasterization on the screen. Many texture accesses for a single fragment when displacement mapping means slower rasterization for a given screen area taken up by the geometry's projection, whereas producing equal amount of detail that is always using only 3 accesses (normal map, and the two textures being blended together) per fragment would be faster. GPUs are happy to take on a fat chunk of vertex data and fly through it these days, so all the hacks and tricks to extract more detail from low-poly meshes are inevitably going to become obsolete.

 

The key here is a good LOD system. I am personally fond of tessellation shaders, because the detail is entirely figured in screen-space, as opposed to having different levels to transition between. It will always render almost exactly the same number of triangles on the screen, regardless of how close or far the terrain is for a given perspective, which means consistent rendering time.

 

Basically, your existing shader will work just fine if you just throw more detailed geometry at it, and as I said above, get some fractal noise going on in there and you'll be able to create terrain with much more character. You'll probably also want to try fractal-application of your textures, where you blend multiple scalings of them together to produce more variety and less repeating pattern appearances.

 

I´m using fractals :D, but if I increase the "roughness" it just starts to go really crazy (too much small details) I will try to tweak the params and see what I can get!

Share this post


Link to post
Share on other sites

Boring terrain results in boring texturing :)

 

Look up 'Erosion' to generate natural interesting terrain like in the second screenshot, e.g.: http://ranmantaru.com/blog/2011/10/08/water-erosion-on-heightmap-terrain/

 

Anyone knows other resources on erosion? Star Citizen seems to use it as well and it really stands out.

Share this post


Link to post
Share on other sites

Boring terrain results in boring texturing :)

 

Look up 'Erosion' to generate natural interesting terrain like in the second screenshot, e.g.: http://ranmantaru.com/blog/2011/10/08/water-erosion-on-heightmap-terrain/

 

Anyone knows other resources on erosion? Star Citizen seems to use it as well and it really stands out.

 

Yep, I guess that I must improve the terrain first and then the texturing will come up nicely, I will research on erosion for sure! Thanks!

 

 

EDIT: On that article, it says that erosion can not be applied to infinite terrains :C

Edited by piluve

Share this post


Link to post
Share on other sites

EDIT: On that article, it says that erosion can not be applied to infinite terrains :C

 

True - Erosion is a simulation thing, not procedural.

But you can generate procedural terrain around the camera and apply / refine erosion only for the new tiles and levels of detail that come in. That's surely possible but serious amounts of work.

Also you could precompute a set of erosion patterns and blend them to procedural terrain with similar topology (probably even more work with worse results).

 

Why do you want infinite terrain?

When i grew up the dream of a infinite game was big, but now i know what i really wanted was: Keep discovering something NEW after some time. And that's exactly what procedural generation can't deliver.

Procedural generation is usefull mainly to fill some gaps or to blend / modify handmade content.

 

Why 1000 mountains when they all look similar? And more important: A single Mountain might be interesting and fun to climb up.

But if there are 1000 similar mountains - which one should i choose and what interesting things can i expect to find? Probably none, so i loose interest in climbing up even a single mountain.

 

Plus - i'm bored to death by looking at the same procedural generated landscapes for decades. Everyone (including me) has done this more often than enough.

Erosion and similar techniques really can improve this and bring up something new, so should be worth working on it.

Share this post


Link to post
Share on other sites

 

EDIT: On that article, it says that erosion can not be applied to infinite terrains :C

 

True - Erosion is a simulation thing, not procedural.

But you can generate procedural terrain around the camera and apply / refine erosion only for the new tiles and levels of detail that come in. That's surely possible but serious amounts of work.

Also you could precompute a set of erosion patterns and blend them to procedural terrain with similar topology (probably even more work with worse results).

 

Why do you want infinite terrain?

When i grew up the dream of a infinite game was big, but now i know what i really wanted was: Keep discovering something NEW after some time. And that's exactly what procedural generation can't deliver.

Procedural generation is usefull mainly to fill some gaps or to blend / modify handmade content.

 

Why 1000 mountains when they all look similar? And more important: A single Mountain might be interesting and fun to climb up.

But if there are 1000 similar mountains - which one should i choose and what interesting things can i expect to find? Probably none, so i loose interest in climbing up even a single mountain.

 

Plus - i'm bored to death by looking at the same procedural generated landscapes for decades. Everyone (including me) has done this more often than enough.

Erosion and similar techniques really can improve this and bring up something new, so should be worth working on it.

 

 

I guess its more the fact of doing it on a new tec (like dx12) as I have never worked with it. Making the thing infinite means I can add like multithreading and so on. Now that I think it, I guess that I could have it multithreaded on just a static terrain :s .

Share this post


Link to post
Share on other sites
Oh man, I tackled this problem back in 2010 for a graduate level game programming class (UNT LaRC represent!) and my results were quite impressive. I was fixated on finding a real time implementation that would create results comparable to something outputted by terragen.

What you are looking for is a natural way to jitter the alpha/boundary areas, and like you my first instinct was to go down the actual route of studying erosion for realistic results. However, the solution turned out to much simpler.

Perlin noise. For my terrain, I used two per line noise textures (created in gimp, I don't remember if it was plasma/desat or cloud, but I'm inclined to think it was plasma noise plus desat). On big and one small/tiled and overlaying the two (https://pdfs.semanticscholar.org/1448/5c2238c23b6f83a7e870c547f0b20ba8dd34.pdf) to provide me the jitter factor for my slope (the y component of the normal).

You may also want to look into smoothstep/smootherstep or a piece wise solution (which I ultimately settled for) to make the alpha transitions crisper.

Share this post


Link to post
Share on other sites

Oh man, I tackled this problem back in 2010 for a graduate level game programming class (UNT LaRC represent!) and my results were quite impressive. I was fixated on finding a real time implementation that would create results comparable to something outputted by terragen.

What you are looking for is a natural way to jitter the alpha/boundary areas, and like you my first instinct was to go down the actual route of studying erosion for realistic results. However, the solution turned out to much simpler.

Perlin noise. For my terrain, I used two per line noise textures (created in gimp, I don't remember if it was plasma/desat or cloud, but I'm inclined to think it was plasma noise plus desat). On big and one small/tiled and overlaying the two (https://pdfs.semanticscholar.org/1448/5c2238c23b6f83a7e870c547f0b20ba8dd34.pdf) to provide me the jitter factor for my slope (the y component of the normal).

You may also want to look into smoothstep/smootherstep or a piece wise solution (which I ultimately settled for) to make the alpha transitions crisper.

Thanks for the comment and the paper! I just made a quick read through it and it looks really interesting!
Thanks.

Share this post


Link to post
Share on other sites

This topic is 396 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.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this