I have a heightfield with hills and a creek, with some additional displacements to adjust the level of the creek bed. Now I'd like to make a procedural mask that extends into the creek bed and use it to make an ice shelf along the margins of the creek.
No problems making the mask. But there doesn't seem to be any way to apply it to the water surface, which is a plane. Is this even possible? I'm guessing the answer is no.
I know I've seen examples of coastal water foam on this forum that might offer some clues, but can't seem to find them now.
In the meantime maybe I'll apply the mask to the base terrain, capture it with a camera and apply it as a texture map to the plane. :P
I'd imagine World Space / Final Position would work fine, but maybe I am wrong.
I'll give that a test.
Seems to work in my tests, but I don't have a river/stream heightmap to test and was too lazy to make one.
However, to simulate depth better, unless you have an extruded imported plane, you may have better results just merging between offsetted ice, and water with a merge shader on the water surface plane.
Edit: Yeah, a merge is a much better result. No issues with rays and stuff due to opacity.
Thanks, Jordan. I see what you did here. This is a good solution for procedural rivers and I'll file it away for future reference. Using a merge shader to apply the ice shelf works really well, so I'll definitely borrow that.
What I'm really looking for, though, is building an ice shelf over a heightfield generated from a DEM. So the creek is not procedural. I'd like the ice shelf to be defined by the water depth, so the shallow areas are frozen. Most of these areas will be along the shore, but there should also be ice around sandbars and rocks in the middle of the stream.
Burning a mask texture map with an orthogonal camera seems to work. Running a test now and will post shortly.
Needs work, obviously. But you get the idea.
Oh ok. Well you could probably do use the foam trick, that is using the displacement to scalar and a colour adjust or two to define your area.
Why don't you use the greys from the heightfield, either directly (if it's grey tif), or through a displacement to scalar (blue) and a color adjust?
That's what I ended up doing, though the displacement to scalar was giving me trouble. It could see the additional displacements fine but not the underlying heightfield, which is generated from a loaded .ter file. Maybe I was doing something wrong. I used a get altitude with a color adjust instead, and that worked perfectly.
Couldn't find a way to apply the live mask to the plane object, though, which is why I ended up capturing a grayscale mask with an orthogonal camera and then applying it with an image map shader. It's a simple process and works fine.
Not even sure how a get altitude with a colour adjust works as it should have no data regarding the terrain. Just the altitude value. That's a new one.,
the heightfield shader can shade by height. Giving a colour map output.
You mean I stumbled upon something new? :D
The Get Altitude outputs a scalar value, correct?
Quotethe heightfield shader can shade by height. Giving a colour map output.
That might work as well.
Yeah, I mean if it works like that, all you need is the surface layer, as that's what it's using, get altitude or get altitude in texture. So you should be able to derive the ice area from the water height. Otherwise, I don't understand how this is working. xD
Yep, I assume it's getting its altitude data from the surface layer. It took me awhile (as a longtime Maya modeler who's used to *directional* graphs) to understand that TG nodes transmit data both ways.
I tested this with landmark shaders set at various altitudes. Setting the white point of the color adjust shader to the desired altitude nails it every time.
But get altitude only works when a compute terrain is used (I think), and only in the line it's in. The only way I can think of to get an altitude of a terrain to another line is to use the blue node displacement to scalar.
Here is what I am getting. The two networks are identical except one uses Get Altitude, and the other Displacement to Scalar. No Compute Terrain. According to the documentation, both shaders output scalar values. But apparently the scalar values they produce are very different.
Get Altitude gives me the result I would expect. Displacement to Scalar gives me . . . nothing. What am I missing here?
Either way I can't find a way to transfer the live mask to another line. Whenever the displaced state (here generated by a PF) isn't available, the mask goes away. Which makes sense.
Displacement to Scalar needs the terrain fed into the shader.
/* 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 . . .
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.
QuoteThe 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.
Quote from: sboerner on November 10, 2021, 03:20:28 PMQuote from: undefinedThe 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.
QuoteMay 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.
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.
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).
QuoteWhen 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.
Strange. Can you post that tgd?
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
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.
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.
Which surface are you using, Ulco? I had no problems with the sphere, or lake object centered on world origin.
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.
Yes, the sphere works just fine. I ran across this problem because I needed to use a water surface plane for a scene I'm working on. It includes a stream bed that falls half a meter across the width of the scene, about 150m, enough to be noticeable if the water surface doesn't follow. Using a slightly inclined water plane seemed to be the quickest solution. It is also a little over 1km from the scene origin. So in this very specific instance the mask distortion was noticeable. I just wanted to determine the cause. Now I know!
You can also use disp to scalar to add displacement to your water sphere, and then offset it (with a surface layer offset) down, than use a hard mask to raise your streams from that sphere back up where they need to be, creating water that hugs the terrain
Good to know, thanks. I'll give that a try. Not sure how/why I've managed to avoid this shader all these years. Looks like I've been missing out.
I sometimes use just simple shapes to raise or lower certain sections of water, say a lake up a hill with sea down there. One watersphere, a couple of surface shaders masked by simple shapes and using offset for each. Same for decreasing/increasing waves for each water section.
Here is a messy example for a terrain hugging river. The issue with this is it leans with the terrain. But if you properly prepare the area with larger masks similar to how the river surface is done it may help. Ulco's method is certainly much better for a simple hill where the simple shape slope is fine enough, I've done this merged with a smooth version of the terrain just to ever so slightly accent the slope (like 0.05 on the merge mix).