Any way to apply a generated terrain mask to plane object?

[WAS]

Displacement to Scalar needs the terrain fed into the shader.

[sboerner]

/* Bangs head against wall. */

Oh, good lord. Don't know how many times I read right over that in the wiki. Thanks for pointing it out. As you can tell, I've never used this node before.

This works and apparently outputs a scalar value equal to the altitude. See attached displacementToScalar.jpg. Same result as I was getting before with the Get Altitude shader. It also allows me to transfer the mask to the plane object, though there is a mismatch (also attached).

Also, feeding the displacement through a Compute Terrain seems to break it. Patch size doesn't matter.

Still figuring this out . . .

[WAS]

The Displacement to Scalar will be the actual Bump Map of your terrain, so it is correlated to altitude in that the highest scalar value will represent the highest peaks/areas in your terrain. This means when you define an area of the map, it will have data from the terrain so it won't be just a hard mask of 1 and a fuzzy zone, it will be whatever the terrain is. So you can clamp in the Black Point like shown in my image to make the map a harder 1 (When low/high colour is clamped).

The compute terrain does indeed mess with the map, so it's best to take the line right before the compute terrain/normal shader. You don't need the texture coordinates and stuff anyway, and it may add negatively to computation time.

In my example we are stepping back -3 which is just over halfway to the bottom of the river (at -5 displacement), and then I step back the black point (white point I mean) to harden the mask so it's not so soft. So my colour adjust is sampling a slice of the terrain at -3 to -2.5 (altitude) giving me nice mask that isn't totally hard at the boundaries. Naturally, when this is applied to the water surface which is just under altitude 0, this gives us the ice stretching out into the water.

[sboerner]

The Displacement to Scalar will be the actual Bump Map of your terrain, so it is correlated to altitude in that the highest scalar value will represent the highest peaks/areas in your terrain. This means when you define an area of the map, it will have data from the terrain so it won't be just a hard mask of 1 and a fuzzy zone, it will be whatever the terrain is.

My understanding is this: if the highest point is 1254.5 meters, the output of the D2S shader at the xy coordinates of that point is 1254.5. And anywhere the elevation is 654.73m, the output is 654.73. And so forth for each point, producing (in effect) a continuous-tone height map. (I think maybe we are saying the same thing.)


The color adjustment shader in my network has a gamma of 0 to give an absolute hard edge, so the white point can be adjusted to set the mask at any elevation. Setting the black point instead inverts the mask.

Thanks for confirming the effect of adding a compute terrain node.

I don't understand, though, why in my example the mask on the planet surface doesn't match the mask on the plane. AFAIK it's the same data, just applied to different surfaces.

[WAS]

The Displacement to Scalar will be the actual Bump Map of your terrain, so it is correlated to altitude in that the highest scalar value will represent the highest peaks/areas in your terrain. This means when you define an area of the map, it will have data from the terrain so it won't be just a hard mask of 1 and a fuzzy zone, it will be whatever the terrain is.

My understanding is this: if the highest point is 1254.5 meters, the output of the D2S shader at the xy coordinates of that point is 1254.5. And anywhere the elevation is 654.73m, the output is 654.73. And so forth for each point, producing (in effect) a continuous-tone height map. (I think maybe we are saying the same thing.)


The color adjustment shader in my network has a gamma of 0 to give an absolute hard edge, so the white point can be adjusted to set the mask at any elevation. Setting the black point instead inverts the mask.

Thanks for confirming the effect of adding a compute terrain node.

I don't understand, though, why in my example the mask on the planet surface doesn't match the mask on the plane. AFAIK it's the same data, just applied to different surfaces.

May need to final position the mask to lock it into world space so plane altitude doesn't offset anything. 

And yeah. That is basically how it works. It's drawing the heightmap of all the displacement you used based on 0 = altitude 0. Handy for a lot of stuff exporting the heightmap to 32bit exr for other software.

[sboerner]

May need to final position the mask to lock it into world space so plane altitude doesn't offset anything.

Seems that it's not so much offset by altitude as distorted in x and y (in some places it undercuts the planetary mask, in others it extends it). I'll play around with it.


Even though I have no problems visualizing data flow in all the other node-based software I use, Terragen continues to trip me up even after many years of constant use. It's just complex. Data flows in both directions, up and down the network several times in the course of creating the final render state. And instead of conveying discrete pieces of information (like roughness, or translation, or color), everything is bundled together. Probably not possible to explain in simple terms, and guaranteed to keep me humble.

[WAS]

Would that not just be the Y intensities we talked about? You use gamma 0 which will I believe will bring anything below 0.5 or even higher to 0, which may be areas you want to harden with backing up WP close to BP or vise versa depending on altitude direction from 0.

Additionally, steeper the terrain the smaller a fuzzy area you can obtain of it.

[Dune]

When water level is off zero, you get 'distortion' when a line is drawn to a water plane. Hence my method to stretch the initial terrain fractal over Y. Or use an offset (color adjust, or add scalar).

[sboerner]

When water level is off zero, you get 'distortion' when a line is drawn to a water plane.

Not just level, but also horizontal distance from origin in x and z. Appears to be the familiar rounding issue, in a different guise. With everything set to 0, 0, 0, the procedural mask matches perfectly.

[Dune]

Strange. Can you post that tgd?

[WAS]

I still don't see a transform input shader which should be set to world space / final position.

This means the scalar can be modulated by other stuff. Such as moving plane around and it picking a new slice of the scalar

[sboerner]

I added a transform input set to worldspace, but it didn't seem to make any difference. At least not here.

TG file attached. There are three cameras, with one near the world origin and the others near x = 20,000 and x = 60,000. Tested various water surfaces including a world-size sphere, a single lake at 0, 0, 0, and individual lakes and planes at x = 0, x = 20,000, and x = 60,000. You can turn them on and off to test the various combinations.

The attached image shows the results from the three cameras using the sphere and individual lake objects. Using a single lake at 0, 0, 0 for all three cameras gives the same result as the sphere. Using individual planes at the three locations gives the same result as the individual lakes.

This is all consistent with the other types of distortion we typically see with positions and displacements far away from the world origin.

The lesson I take from this is to use a sphere for water surfaces, at least for large scenes or for those distant from the origin. (There are reasons why I need to use a plane for my current scene.)

Didn't test different y values yet for the surfaces. May get to that later.

[Dune]

I don't see any problem really. I've tested a few settings at 244,000k east, and I only get a little offset when very close (image spans 18m). Also when raising water level (offset in surface shader) and adjusting the color adjust to 50/50 gives me exact fits.

[sboerner]

Which surface are you using, Ulco? I had no problems with the sphere, or lake object centered on world origin.

[Dune]

I always use the sphere, never the lake object. I thought you still mentioned problems, even with sphere. If not, great! This the perfect way to get waves at shore and such.