Vector Displacement Rock Tests

[RogueNZ]

Hi all,

I've never been great at creating nice surfaces, so I thought I'd sit down and learn as much as I could and improve my skills. One thing led to another and I got reading about Vector displacements. You'll have to bear with me, as I hadn't even touched vectors in Terragen until 3 days ago, and it's been a few years since I last worked with them at University.

In particular, this thread got me thinking: http://www.planetside.co.uk/forums/index.php/topic,9147.120.html

The way Terragen computes surface normals won't really support overhangs, and doesn't do lateral displacements very well either - someone describes it somewhere as being like draping a carpet over the surface.

I thought about different ways of calculating surface normal's, and came up with the idea to translate the function by a fixed distance in both the X and Z distances. You can evaluate these transformed functions and compare (subtract from the original function), and it gives you sort of normal map in that direction. From this I did a bit of maths (ruined my brain for 2 days straight) but finally think I worked it out. I essentially build a normalized surface normal of the original function and redirect a desired overlay function (smaller scale perlin) in that direction.

In my head I imagine I can repeat this layer by layer, and overcome some of the traditional limitations we have. But I am yet to test this and might not get to until next week.

You can see the node layout below:

[attach=1]

Quick test of scaling the displacement amplitude of the overlay function to show the direction of displacement (0, 20, 60, 100 and 140):

[attach=2]
[attach=3]
[attach=4]
[attach=5]
[attach=6]

So it appears to work, but at this stage won't do too much differently from the usual displace along normal (with a small compute terrain patch size). The real test will be if I repeat the process with additional functions.

I might be completely confused here, like I said I'm fairly new to this so any thoughts, opinions or advice on this would be appreciated 

And a few images of some cool displacements I built while trying to get it working:

[attach=7]
[attach=8]

Cheers

[Hannes]

That looks really interesting (and good!).
I'm always awestruck seeing people easily handle this blue stuff!

[Kadri]

Keep it up.Looks interesting.

[RogueNZ]

Thanks,

I think there must be something wrong with my maths, as it is a perlin ridges function I am applying over the top, but it looks billowy to me...

[AP]

That seems like the noise is inverted somehow? Other then that, this is interesting stuff.   

[mhaze]

Interesting work - keep on exploring   I for one look forward to the results.

[Dune]

Interesting venue, this saves a compute normal node, so might be faster. Have to try it.

[Clay]

Very cool!

[RogueNZ]

Thinking about this over the weekend I have realized that this will not work in the way I thought it would. Because both power fractals are sampled on the same plane (ie looking down), regardless of the normal, I am not truly map the overlaying fractal to non-horozontal areas. It explains why I can see the lateral displacement, but the displacement is not a true representation - it seems to grow larger/longer in areas of high steepness.

I am wondering if I can use the Warp Input Shader or similar to somehow bend the overlaid fractal, so that when looking top down it appears to shrink in areas of increasing steepness. I will have a play and see if I can achieve this.

[Tangled-Universe]

Thinking about this over the weekend I have realized that this will not work in the way I thought it would. Because both power fractals are sampled on the same plane (ie looking down), regardless of the normal, I am not truly map the overlaying fractal to non-horozontal areas. It explains why I can see the lateral displacement, but the displacement is not a true representation - it seems to grow larger/longer in areas of high steepness.

I am wondering if I can use the Warp Input Shader or similar to somehow bend the overlaid fractal, so that when looking top down it appears to shrink in areas of increasing steepness. I will have a play and see if I can achieve this.

This issue has been extensively discussed and cursed on in the very long "squared noise" thread some time ago.
Indeed, TG's shader's are "top-down projections" (for lack of better words) on the plane/object and not truly sampled in world-space and then applied to the surface. Which we desire.

[TheBadger]

Still its good. the more this comes up and the more people understand the problem, the better the potential solution may be. Or rather, the better an intermediate fix may be.

[mogn]

Thanks,

I think there must be something wrong with my maths, as it is a perlin ridges function I am applying over the top, but it looks billowy to me...

I think that the output from the cross product is:

[dy/dz, -1, dy/dx]

[RogueNZ]

I think that the output from the cross product is:

[dy/dz, -1, dy/dx]

You could be right, I'll have another look at this soon.

I've been playing with regular displacements, and have been learning loads. One quick question, in the image attached I tried to place a population in the scene but it doesn't like placing the objects on areas of high lateral displacements - you can see the transition from dense to sparse where the displacement begins. I'm not exactly surprised, but I thought using a compute terrain after the displacement would fix this?

[Hannes]

Just a quick shot without having tested it: does reducing the gradient patch size help?

Great displacement btw!!

[Dune]

It certainly does, Hannes. But sometimes the lateral displacement/roughness is too large for a very small patch size, so you need to play with it.