# Why does a bump/normal map change the look of a plane to which they're applied to, even if the plane only has 1 normal?

From my understanding, a normal map makes the existing normals on a mesh to change the direction they point in, to fake the illusion of grooves/depth/scratches,etc. So the more polygons you have = more normals = the better the effect from the normal map

A bump map from my understanding takes the normals on a mesh and scale them, unlike normal maps which can only change the direction the normals point in

Yet I noted that when I did the below to create a procedural bump map,

A bumpy effect is created. How is this possible? There is only one normal on this plane so how do I get a bumpy effect all throughout the plane? (I also noted that after removing the bump map node from Principled BSDF, the normal of the plane flipped directions

And when I tried the below to create a procedural normal map,

Sure, no longer is there a bump effect, but a pattern-like color effect is present somehow

My question is, how is that in both these cases, bump and normal maps, maps that only affect the scale/direction of your normal, create a drastic bumpy effect/pattern-color effect on a mesh with only one single normal?

• The shader operates within a texture space wherein each "pixel" is assigned a normal - thus a normal map (or bump map) can treat 1 face (with only 1 real normal as you say) as if it has 1 normal for each x/y coordinate on that face, and bend their "reflection and shadow influence" accordingly, without the need for extra faces. Apr 22, 2021 at 19:35
• Also, your "procedural normal map" looks different/ineffective, because unlike the Bump Node, the Normal Map node only accepts true normal maps (such as the blue/violet ones you're used to seeing) that contain 3 separate "RGB" values (Vector3 container) where procedural textures only provide a black and white range (Vector 1 container) Apr 22, 2021 at 19:38
• @ChristopherBennett Sorry I struggled to understand what you said exactly since I dont understand some of the words. Do you mean that in Blender, each pixel has its own 'normal' and the bump/normal maps thus act on a per-pixel basis rather than per normal-of-a-face basis? And is this specifically a Blender thing or how it works with normal/bump maps in general? And if each pixel has its own normal in this case, why is it that the normal map I created not generate any bumps, only color patterns?
– Hash
Apr 22, 2021 at 19:38
• Sorry, If you're unfamiliar with all of my terminology, don't pay it too much attention - some of the terms I used rather cheekily, and could get me in trouble ;) In more general terms, the whole point of bump and normal maps is that you don't need subdivisions to make them work, - they are designed to be able to give even a single plane added detail, without the need for extra geometry. Don't think of it as having to bend one normal per face, think of it as wrapping a magic sheet over the object that has infinite "normals" that can point in any direction. Apr 22, 2021 at 19:45
• Usually you UV unwrap your object, and then use the UV coordinate mapping for your textures. Therefore, the number of "pixels" (X/Y texture coordinates) is whatever is in the range of the UV space. It's a rather complicated subject, and I'm not sure I've had enough sleep at the current moment to outline it correctly. Apr 22, 2021 at 20:01

A normal can be thought of as the direction a face is pointing. The face (usually) has one normal, it's just a vector pointing into space going outwards from the face. For our purposes here, it defines the average angle of reflection of light rays.

When you modify it with a Normal Map, you're giving it additional instructions on how to handle light across the face. For every evaluated pixel, the light is taking the face normal and your Normal Map information into account.

So it's not that it is creating more normals. There is only one, with a little math being done for every pixel sampled. Very easy for your processor/gpu.

From Wikipedia

To calculate the Lambertian (diffuse) lighting of a surface, the unit vector from the shading point to the light source is dotted with the unit vector normal to that surface, and the result is the intensity of the light on that surface. Imagine a polygonal model of a sphere - you can only approximate the shape of the surface. By using a 3-channel bitmap textured across the model, more detailed normal vector information can be encoded. Each channel in the bitmap corresponds to a spatial dimension (X, Y and Z). This adds much more detail to the surface of a model, especially in conjunction with advanced lighting techniques.

• So normal maps takes into account 1) the normal of the face 2) a specific pixel X or whatever on the face 3) a pixel from the normal map texture mapped to X and computes them together to generate the final 'pixel' value or color?
– Hash
Apr 22, 2021 at 20:30
• Hey, thanks for explaining, I've wondered many times how does it actually work :). Apr 22, 2021 at 20:35
• @Hash you got it Apr 22, 2021 at 21:03
• I don't know why I didn't come back to this, I guess I didn't know how to phrase it, but that is exactly what a path tracer does - an insane amount of work to simulate the bouncing of light. Remember that your whole scene exists in 3d and your camera ray may bounce, for example, to the wall and then back to the non-camera-facing side of some object, but color and intensity data is calculated along the whole path. In eevee the whole process is massively simplified at the cost of accuracy, because as you say there is no ray tracing, it's a rasterization engine. Jun 16, 2021 at 1:05
• @Hash So it's that dot-product calculation at every contact with any surface that has a normal map applied. (I thought I'd tag you in this one just in case.) Jun 16, 2021 at 1:07