I am getting weird results from the Surface Shader when trying to shade by altitude. As you can see in the screen shot, My WhiteColour node is using a maximum value of 0, yet the cliff in the preview window clearly shows a vertical line of colour, instead of a horizontal one.
I know it's got something to do with the node Named Cracks, which is above it (this node displaces the geometry to form those canyons), for when I disable the Cracks node, the WhiteColour node shades the terrain by altitude correctly.
Note: that I tried putting the Cracks node before the Compute Terrain, and while it gave expected results, the canyons looked different to what I wanted.
So is this a bug? If not, what am I doing wrong? I have included the .tgd file if anyone would like to take a look :D
It doesn't seem like the attached .tgd quite duplicates your scene, but I'm guessing your camera was on a different part of the planet. You have "Use Y for Altitude" checked in your White surface layer and I am assuming then that your other camera perspective was on a part of the planet where this would produce a dividing line clearly not based on "altitude". "Use Y for Altitude" will use a Y "up" value based on the 0,0,0 coordinate on the surface of the planet, rather than on the actual distance from the planet surface, so relative to the planet this "altitude" changes the further you get from 0,0,0. If you turn off this setting it may work more as you expect.
Ops, I didn't set the camera :)
Ok, I tried to turn off "Use Y for Altitude", and I still have the same result. I attached another file with the camera set in a position that shows what I mean this time :)
It would appear it's actually working correctly, it's just at an odd angle there - you have a slightly sloped mountain surface right at the altitude constraint line which is then displaced downward by a surface layer just above the white layer. Since the downward displacement is into the mountain (along the normal) rather than precisely vertical it appears to be incorrect; your brain assumes it should be displacing vertically downward on a horizontal surface. The reality is that the surface is already at an angle, which I think explains it. If you zoom out it looks more correct.
Also when you're doing heavy displacement like this *after* the Terrain group, it helps to put in a Compute Normal just after your displacement so that any subsequent texturing will be applied correctly. In this case it doesn't seem to make a difference though.
ok, I was getting confused with the y value. I was automatically assuming that y was the centre of the planet. But I still think it's an error. Here, I created another planet (coloured green) which is completely flat in exactly the same position as the first one, and as you see, while the white colour follows the flat surface in the background, when it gets to the crack, it changes altitude and goes below the green planet.
If the surface shader was working properly by altitude, then it would never go below the completely flat green planet.
It's going below because your terrain goes below, and you're using "Limit maximum altitude" not "Limit minimum altitude". There's no min altitude constraint so it's naturally going to occupy *all* area below the max altitude limit. Or am I still misunderstanding? Hehe.
Maybe it's me and my explanation.
Ok, in the first image below, the green planet represents an altitude of '0'.
The grey planet has a shader (white) that is set to Shade by an altitude constraint. I have set it to 'Limit minimum altitude' and a value of '0' as you mentioned.
So what we should end up with is the white coloured part of the shader should not go below '0', because that would go below the minimum altitude value.
Now in the second image, when I lower the altitude of the green planet uniformally by '-20' We see that in the crack, the white coloured part of the shader doesn't stay at '0', but goes below '-20' (the shader is unchanged in both images). So how can I limit the shader by altitude properly so that the white part stays at '0'?
I hope this makes sense.
All that makes perfect sense. It's just that in the .tgd you attached it's "Limit maximum altitude" that's on, not "Limit minimum altitude". If I reverse the values and checked constraints in the white layer it works as you seem to want. One of us is missing something and I'm not sure it's you. ;)
THe fact that I change a setting here and there in each of my example images might lead my explanation to be a bit confusing, my fault.
Here is the tgd file from the image above. If you are able to make it so the white shader gets restricted to '0' altitude and not touch the green planet, then I would be most grateful :D
Oshyan, any luck in being able to constrain the white surface layer on the grey planet to not go below '0' in the file I posted above this post? I tried a few other things and I could'nt get it working properly, even though I have it constrained in the shader...
Is this what you're after?
Yes am am :) Are you able to do the same in my file?
Or was that in my file? If it was can you post it?
I did that with your file ;) The trick is to remove the compute terrain from it's current position in the nodetree and place it between your 'cracks' node and your 'whitecolour' node. Initially I tried to place a compute normals node there, but apparently it doesn't give quite the same result as the compute terrain.
Ahhh, but herein lies the problem. I knew about relocating the Compute Terrain node. But when that happens, the cracks change their shape, and this is what I don't want. I like the shape the cracks make on my terrain
All I want to do is constrain the shader by an altitude of '0', without changing the shape of the geometry.
Is this possible?
Ok, I didn't notice that. I did some more experimenting and I think this is the answer. Remove the altitude limits in the whitecolour layer and instead set the limits in the distribution shader. Setting the displacement offset in the white colour shader you can actually get thick snow I found out while experimenting, not sure if you want or need that for this one though ;).
That's it! Ahhh thank you very much. I never thought to use a Distribution Shader because they have the same constraints as in the Surface Shader.
Is this intended, Oshyan? Are the constraints in the Surface Shader supposed to work differently from the constraints in the Distribution Shader? No matter now that I know how to fix it, but it might confuse others who think they do the same thing.
Good work diagnosing this stuff together guys. I do believe there are some unintended inconsistencies between the Surface Layer constraints and Distribution Shader constraints. It also seems like some of the other issues and behavior described here are probably due to underlying bugs. I'll have Matt take a look at this stuff and make sure it's behaving as intended.