# Coloring Terrain By Steepness Issue

Also I am attempting to implement some simple coloring by "slope" onto my planet and to do this I take the normal mapped normal "y" component and subtract it from one. Yet I am getting some strange effects, using a small grid for example:

to get this image I had to use the following code:

float slope = 1.0 - normal.y;
if(slope < 0.89){
color = vec3(0.545,0.353,0.169);
}else{
color = vec3(0.237,0.457,0.137);
}


Which doesn't make much sense to me. Also, as you can see, only one side of the terrain is being colored in this way. Shouldn't lower values for slope being more level? Thanks for the help

EDIT: Here is the terrain colored according to the pixels normal:

• That should work fine, it's how I'm doing it... are you sure Y is your up axis? What happens if you change the first line to use normal.z? – Robert Rouhani Jul 29 '13 at 6:08
• Render your pixel color's according to the normals. Something like: vec4(vec3(0.5) + (normal * 0.5), 1.0) (off the top of my head). That will show you which direction your normals are pointing, which will make debugging this much easier. – Trevor Powell Jul 29 '13 at 7:46
• @RobertRouhani Yea "y" is definitely up. Using z gives some really interesting but incorrect results. – multifractal Jul 29 '13 at 8:16
• @TrevorPowell ok, I added that above – multifractal Jul 29 '13 at 8:17
• Since it's terrain data you're dealing with, you're interested in the magnitude of the projection of your normal onto the ground plane (that'd be the 2D vector (normal.x,normal.y)). Its magnitude is between [0,1], so you can use it to color code the terrain from.. let's say.. blue to red (temperature map) to highlight steep vs flat regions. Is this what you want? – teodron Jul 29 '13 at 8:41

Solved using teodron's suggestion. Slope is now set to float slope = length(vec2(normal.x, normal.y)); and it works perfectly.