Ken Kawashima on Bump,Displacement & Normal Maps



  • Some of you may know him as ken1171. With his permission, I am linking to his post at his DeviantArt Journal, which talks about the differences among Bump, Displacement and Normal Maps, and when each can be used effectively.

    http://ken1171.deviantart.com/journal/Bump-Displacement-and-Normal-maps-649534234



  • @ibr_remote Thanks for the link. I know Ken from the HiveWire Forums, and he's always posting needed information. This will definitely be useful.


  • Poser Ambassadors

    Somewhat useful but I have to say not entirely accurate in some respects. There is no requirement for bump maps to be 8 bit, for example. Bump & displacement are different uses of height maps rather than types of maps themselves. Normal maps don't offer significant performance gains over bump in Poser; I haven't seen evidence that they are more detailed either (& I've made & used both kinds). MikkT is the tangent basis used for encoding & decoding a tangent-space normal map, not a new type of normal map.

    I'd recommend the Polycount Wiki as a good source of info for anyone wanting to do more research.


  • Poser Ambassadors

    Eh, I'm geeking out :D

    This is in the interest of information & based on my experience it's correct (in other words, if you see a mistake, please point it out!).

    Tangent-space normal maps come in two flavours, OpenGL & DirectX.

    • OpenGL = X+Y+Z+
    • DirectX = X+Y-Z+ = the Y or green channel is flipped/inverted compared to the OpenGL map.

    BOTH can be used in Poser Firefly & Superfly. The difference is that the high points in one will be the low points in the other; the relief is inverted.

    I can dig out an example render if anyone's interested ;)

    The above has nothing to do with the tangent basis, which is how the tangent-space normal map is encoded when it is created & how it is decoded by the render engine. It's a set of instructions. If a tangent-space map is created with a different tangent basis to the render engine it can result in shading errors. In realtime games this is obviously massively important & using the same tangent basis to create the normal map as the render engine which will decode it is called having a synched workflow.

    MikkT is becoming a standard for tangent basis & a lot of apps now use it because the source code was freely provided by Morten S. Mikkelsen. Superfly uses MikkT; Firefly though uses it's own tangent basis as does the OpenGL preview. Therefore there is the potential for shading discrepancies between the render engines.

    Normal maps are computer code; they are unlike any other texture map. For use in an offline render engine like Poser there doesn't seem to be any particular advantage to using them compared to a 16 bit height map plugged into bump, end result is pretty much the same.


  • Poser Ambassadors

    End user friendly is often forgotten.

    When Normal maps are baked, you are done. No way end users can "adapt" them any more.
    Bump and Displacement maps are more end user friendly because being "grey-maps" they can be changed at will by the creators or the customers/end users.

    Normal maps are good for games only, where no change is ever required.
    Bump and displacement are better for Poser style apps.

    In brief:
    Poser's FireFly has the "inverted green issue".
    SuperFly can not do "micro-displacement" (it needs geometry to do displacement)

    Bump maps work in both FireFly and in SuperFly.

    best regards, Tony



  • In favour of grey scale bump maps - they are easier to use as the input to a node set-up, meaning they can be subverted to do other stuff.

    I had seen a comment to the effect that normal maps had a fixed strength, but the PoserSurface node in Posers 10 and 11 features a value dial so I guess that's no longer a problem.

    Also, normal maps may be effectively 24 bit (8 bits per channel of R, G, B) but since that's used to encode three vectors I can't convince myself that they necessarily have better resolution than an 8 bit bump map. I'd be happy to be set straight on that question.

    Bottom line, I'd use normal or bump mapping depending on individual circumstances.



  • @vilters said in Ken Kawashima on Bump,Displacement & Normal Maps:

    I found this post fascinating, and have never played with normal simply as a means for achieving bump or displacement. Surely the primary purpose for normals is to create depth in more than just two axes?

    SuperFly can not do "micro-displacement" (it needs geometry to do displacement)

    I'm confused by this statement. If you change the skinning method to Unimesh and switch on subdivision to at least level 2, Superfly is perfectly happy to do micro-displacement via displacement maps BUT only if you render using the CPU not the GPU.



  • @englishbob said in Ken Kawashima on Bump,Displacement & Normal Maps:

    Also, normal maps may be effectively 24 bit (8 bits per channel of R, G, B) but since that's used to encode three vectors I can't convince myself that they necessarily have better resolution than an 8 bit bump map. I'd be happy to be set straight on that question.

    Well surely, 8 bits per channel gives an identical displacement range in any individual axis (256 values) as a single channel grey scale bitmap, BUT it is tri-axis displacement as opposed to mono, so is better for realism because you can detail every axis without merely stretching in the X and Y planes?


  • Poser Ambassadors

    Bit depth is referred to per channel.

    8 bit = 256 levels from black (0) to white (255).
    16 bit = 65,536 levels from black (0) to white (255).
    32 bit = a silly number.

    More details on bit depth here.

    A height map is a grayscale image, therefore a single channel. Each pixel value represents a step from lowest (black) to highest (white). They are often created using 50% grey (127, or 128 if you prefer) as a mid-point which means no height change on the mesh. Values below this (darker) will push into the surface; values above this (lighter) will push out from the surface.

    Height maps can be plugged into bump which will affect lighting calculations but will not alter the silhouette of the mesh, or plugged into displacement which will alter the silhouette of the mesh as it affects the geometry.

    Normal maps affect lighting calculations but don't alter geometry, so will not affect the silhouette of the mesh.

    More details on normal maps here.

    Firefly uses micropolygon displacement which dices the geometry of a mesh into much smaller pieces - it does this on the fly at rendertime. This is not the same as subdivision surfaces, & is something Reyes render engines are good at. Firefly can also use 32 bit displacement and load/unload textures as it needs them.

    Superfly uses vertex displacement which moves the vertex positions of the geometry. The quality of displacement therefore depends on how fine or coarse the geometry is; subdividing the surface can help to achieve more detail but each level of subD creates 4 times more geo & therefore costs more memory. Superfly cannot do on the fly stuff like Firefly as it is a pathtracer & has to hold everything in memory; nor AFAIK can it use 32 bit displacement maps. Advantages though are easier & better lighting, faster rendering of reflections etc etc.

    So a number of observations from my POV. If you use 8 bit height maps you risk stair-stepping artefacts - only 256 steps, vs. 16 bit height with up to 65,536 steps. With normal maps, the fact that they are supposed to be used at the same strength they were created with is a bonus to me - I set the value at 1 & forget it as if I made it right it doesn't need adjusting. With height maps I have to fiddle around with values to match the look of the high poly model.

    Best strategy I've used with Firefly is relatively simple meshes with 32 bit exr displacement - can get crazy levels of detail, but doesn't work in Superfly. There I've had good results using more geometry (enough to get the silhouette I want) & normal or bump for fine detail. Still experimenting when it comes to Superfly though.

    Finally, image to demo OpenGL & DirectX tangent-space normal maps in both Firefly & Superfly - both types will work but relief is inverted, so it entirely depends on how they have been created.

    0_1481138295251_render results.jpg



  • @caisson Great info - thanks for posting this!