heightmap too harsh?

Support Materials and Textures
#1

hi folks.

i need heightmaps from my terrains. followed this tut:

but i have a problem: my black-to-white range is too harsh, only black a little, then suddenly bekomes white, not a soft variety like in the tutorial. what could that be?

i have the black-to-white range like here: (but i need the one right next to it)

errorverlauf.png749×750 47.3 KB

edit: i have the correct-looking range with alpha:0 in black side, if i remove it i have the wrong looking one, but the height map still is not that good, too less black and too much white, level ranges change too suddenly

#2

changed blending from linear to quadratic, made things better

#3

If you want a linear height change, choose linear blending. What you see is not what you get with non-color data and height is definitely not color.

#4

Or “de-gamma” (ehh?) correct it. Either gamma with 2.2 or gamma with 0.4545 (1/2.2) after the node. Linear blending fixes that? Intuitively I would think it’s just going from A to B linearly rather than some other smoothing, and that colorspace gamma still had influence. If not, then that is news to me :slight_smile:

#5

why not just bake a “displacement map” using “blender render” and NOT cycles ,that is what i do .
like this spherical mapped displacement map
( converted to 8 bit and normalized – was 32 bit float)

http://9.t.imgbox.com/yHZemjJK.jpg
from this
http://3.t.imgbox.com/AenVeJ7K.jpg

or start with a heightmap and use that as a displacement
http://6.t.imgbox.com/wXRXsjXN.jpg

http://4.t.imgbox.com/BHZqYaVW.jpg

#6

Internally everything is linear, not gamma-corrected, so a linear interpolation is just what it is, a linear interpolation (0.5 is middle between 0.0 and 1.0). Gamma correction is used in display transform, but not in a 100% consistent way (all UI elements that show color choices to user must also be corrected, but only for color data) . Is up to user to make the separation between color and non-color data. For example alpha values must not be gamma-corrected to avoid user overcompensating a seemingly wrong falloff: middle value for alpha is 0.5, but for grayscale color it is ~0.18. Gamma-corrected alpha will show falloff that seems wrong (although internally it is correct).

#7

Sorry, I didn’t realize he had already chosen “linear blend” in the ramp node. I thought you meant setting this from something else to linear would correct for gamma, which I found strange. I’m guessing you’re talking about a displacement setting (can’t check right now)?

#8

I’m talking about the interpolation/blend type in color ramp. If one wants a visually correct color gradient, linear is not the correct choice and must be gamma-ed by the user (to get middle value to 0.18, which is the middle gray for scene-linear color data instead of 0.5) but for non-color data (alpha, height, weight etc) linear is the correct choice if you need a literally linear ramp.

You don’t need to gamma-correct data that is not for viewing (not color), instead you want to make very sure you do NOT gamma correct it or you will get wrong result. The fact that it does not look correct in the UI is of little importance, as I said in one previous post. What you see is NOT what you get with non-color data.

A color ramp bursts out a bunch of numbers, which are up to user to use and interpret. The ramp itself can not decide if it expresses a color gradient or some arbitrary data, user must decide and if necessary, transform the values.

#9

Three displaced planes in side view, with linear, cardinal and ease blending types (left to right). Although the ramp with interpolation set to “ease” looks the most “linear” in UI, it is not a linear ramp and linear displacement at all:
[ATTACH=CONFIG]451498[/ATTACH]

#10

Attachment didn’t work, but we’re in full agreement. I misunderstood what you said in #3.