Blender Quiz: Use Normal Maps And Bump Maps Correctly Intro
10 questions · exam conditions
0:00
Use Normal Maps And Bump Maps Correctly IntroQuestion 1 of 10

A tangent-space normal texture is connected from an Image Texture node to a Normal Map node and then to the Normal input of a Principled BSDF. The relief looks overly harsh and changes noticeably when the image's color-management setting is adjusted.

Which configuration most directly corrects the underlying data interpretation while preserving the intended node workflow?

Set the Image Texture to Non-Color, keep the Normal Map node in Tangent space, and connect its output to the shader's Normal input.
Set the Image Texture to Linear, bypass the Normal Map node, and connect the image color directly to the shader's Normal input.
Keep the Image Texture set to sRGB, change the Normal Map node to Object space, and reduce the node's Strength.
Keep the Image Texture set to sRGB, connect its alpha output to the Normal Map node, and increase the shader's roughness.
← Back to quizzes

Blender Quiz

Blender Quiz: Use Normal Maps And Bump Maps Correctly Intro

Practice Use Normal Maps And Bump Maps Correctly Intro in Blender with focused quiz questions that help you check what you know, review explanations, and build confidence with test-style prompts.

What this quiz covers

This quiz focuses on Use Normal Maps And Bump Maps Correctly Intro, giving you a quick way to practice the rules, question types, and explanations that matter most for Blender.

How to use this quiz

Try each quiz question before looking at the correct answer. Use the explanations to review missed ideas, then come back to similar questions until the pattern feels familiar.

All questions

Question 1

A tangent-space normal texture is connected from an Image Texture node to a Normal Map node and then to the Normal input of a Principled BSDF. The relief looks overly harsh and changes noticeably when the image's color-management setting is adjusted.

Which configuration most directly corrects the underlying data interpretation while preserving the intended node workflow?

  1. Set the Image Texture to Non-Color, keep the Normal Map node in Tangent space, and connect its output to the shader's Normal input. (correct answer)
  2. Set the Image Texture to Linear, bypass the Normal Map node, and connect the image color directly to the shader's Normal input.
  3. Keep the Image Texture set to sRGB, change the Normal Map node to Object space, and reduce the node's Strength.
  4. Keep the Image Texture set to sRGB, connect its alpha output to the Normal Map node, and increase the shader's roughness.
Explanation: Whenever you see a question about normal maps in Blender, the key concept to focus on is color space interpretation. Normal map textures store directional data (XYZ vectors encoded as RGB values), not visual color. This means Blender must treat them as raw numerical data — not as perceptually-encoded sRGB images. The problem in the passage is that the Image Texture node is left on sRGB, which causes Blender to apply gamma correction to what is actually linear vector data. This distorts the normal directions, producing harsh, incorrect shading that also shifts when color management settings change. The fix is straightforward: set the Image Texture color space to Non-Color so no gamma correction is applied. The Normal Map node should stay in Tangent space because tangent-space normals are the standard format for most baked normal textures — they store directions relative to the surface, allowing them to work correctly across deforming or UV-mapped geometry. That's exactly what option A does, making it the correct answer. Option B is tempting but wrong on two counts: "Linear" is not the correct setting for non-color data in Blender's color management system, and bypassing the Normal Map node means the raw RGB values go directly into the Normal socket unnormalized and unprocessed, producing garbage output. Option C keeps sRGB, which is the root problem — reducing Strength just masks the symptom without fixing the data error. Option D is entirely off-track: the alpha channel of a color image carries no normal information, and increasing roughness addresses surface reflectivity, not normal interpretation. Your study tip: any texture that stores data rather than visible color — normals, roughness, metalness, displacement — should be set to Non-Color.

Question 2

An artist is baking surface detail for a skinned character whose limbs will bend substantially during animation. The normal texture must remain aligned with the deformed surface and its UV layout.

Which normal-map space is the best choice for this use, and why?

  1. Tangent space, because its vectors are interpreted relative to the UV-derived surface basis that follows the deformed mesh. (correct answer)
  2. Object space, because its vectors remain fixed to each polygon independently of skinning and vertex-normal changes.
  3. World space, because its vectors rotate automatically with each bone while remaining independent of the object's transform.
  4. Generated space, because its vectors are recalculated from the character's bounding box after every armature deformation.
Explanation: When baking normals for animated characters, the central question is: relative to what coordinate frame are the normal vectors stored? The answer determines whether the map stays valid as the mesh deforms under an armature. Tangent space is the right choice here, making A correct. In tangent space, each normal vector is stored relative to a local basis built from the surface's UV coordinates — specifically the tangent, bitangent, and surface normal at each point. Because this basis is derived from the UV layout and travels with the mesh as it deforms, the stored vectors remain meaningful even when limbs bend dramatically. The renderer reconstructs the correct world-space normal at runtime by transforming the tangent-space vector through the current deformed surface basis. This is precisely why tangent-space normal maps are the industry standard for skinned characters. B is wrong because object-space normals are fixed relative to the object's local axes, not to individual surface patches. When a limb rotates, the polygons rotate with it but the object-space vectors do not reorient to match — causing visible shading errors at bent joints. C is doubly wrong: world-space normals are tied to a global frame, so any rotation of either the object or its bones invalidates the map entirely. Bones do not automatically update world-space baked data. D describes no real Blender feature — there is no normal-map space that recalculates vectors from a bounding box after armature deformation. A useful rule of thumb: if the mesh deforms (skinning, shape keys), always bake in tangent space. Reserve object or world space only for rigid, static objects where the geometry never changes shape.

Question 3

A brick wall uses a high-resolution bump map. It looks convincing from the front, but at a grazing camera angle the outer silhouette remains perfectly straight and the bricks cast no individual geometric shadows.

Which revision is required if the silhouette and cast shadows must follow the brick relief?

  1. Increase Bump Strength, because sufficiently strong perturbed normals eventually modify the mesh's silhouette and shadow rays.
  2. Use actual displacement on sufficiently subdivided geometry, because bump mapping changes shading normals but not surface positions. (correct answer)
  3. Convert the bump image to a tangent-space normal map, because normal maps move the rendered surface along encoded vectors.
  4. Change the height texture to sRGB, because display-referred contrast is required to produce geometric shadow depth.
Explanation: When a question asks why a shading technique fails at silhouettes or cast shadows, you need to think about what actually changes in the scene's geometry versus what only changes in its shading calculations. That distinction is the core of this question. Bump mapping works by perturbing surface normals at render time, tricking the lighting model into shading as if small bumps exist. The mesh underneath remains completely untouched — every vertex stays exactly where it was. Because silhouettes are defined by where geometry actually ends, and because shadow rays test intersections against real geometry, no amount of bump mapping can produce a curved brick silhouette or make one brick cast a shadow onto another. This is exactly why B is correct: only genuine displacement — moving vertices along the surface normal based on the height map — changes actual surface positions, which then affects both silhouettes and shadow casting. The geometry must also be sufficiently subdivided so displaced vertices can represent fine detail. A is simply false. Normal perturbation has no effect whatsoever on mesh positions regardless of strength; cranking Bump Strength higher only makes the shading look more extreme, not more geometrically accurate. C confuses two related but distinct techniques: a tangent-space normal map still only influences shading normals, not vertex positions, so it shares the same fundamental limitation as bump mapping. D is a red herring involving color space; switching a height texture to sRGB affects how Blender interprets its gamma curve, which does not produce geometric depth or move any surface point in 3D space. A useful rule of thumb: if the question mentions silhouettes or inter-object shadows, the answer almost always involves real geometry, not a shading trick.

Question 4

A tangent-space normal map was baked and verified on a prop. The mesh is later given a substantially different UV unwrap while the same image remains connected. The image has not been rebaked, and the material now shows directional errors and seams.

What is the best explanation and corrective action?

  1. The new UV layout changes the tangent basis; rebake the tangent-space normal map for the final UVs and mesh configuration. (correct answer)
  2. The new UV layout changes object-space axes; switch the existing image to World space without rebaking it.
  3. The new UV layout alters color management; change the existing image from Non-Color to sRGB and reload it.
  4. The new UV layout lowers polygon resolution; increase the Normal Map Strength until the seams become visually hidden.
Explanation: Whenever you see a question about normal maps and UV changes in Blender, you need to think about what a tangent-space normal map actually encodes: surface detail relative to each polygon's local tangent basis, which is constructed directly from the UV layout. This is the core concept being tested here. A tangent-space normal map stores directional data (red, green, blue channels representing X, Y, Z offsets) relative to the surface tangents derived from how UVs are oriented on the mesh. When you rewrap a mesh with a substantially different UV layout, those tangent frames change — every polygon's local coordinate system shifts. The baked map was computed for the old tangents, so applying it to new UVs produces mismatched lighting directions and visible seams at UV boundaries. The only correct fix, as A states, is to rebake the normal map using the final UV layout so the encoded tangent-space data matches the new tangent basis. B is wrong because object-space normal maps encode directions relative to the object's local axes, not UVs — switching to "World space" is not a valid option in this context and wouldn't fix a tangent mismatch anyway. C confuses color management with coordinate encoding; color space (Non-Color vs. sRGB) affects how pixel values are interpreted numerically, not the underlying tangent-space mismatch — that setting should already be Non-Color for normal maps and changing it won't fix seams. D misunderstands what Normal Map Strength does; it scales the perceived intensity of the effect but cannot geometrically correct directionally incorrect or seam-broken data. Your study takeaway: any time UVs change on a baked asset, treat the normal map as invalidated and rebake — UV layout and tangent-space bakes are permanently coupled.

Question 5

A tangent-space normal map is baked onto a low-poly asset. Afterward, the artist changes the mesh's smooth-shading boundaries and custom split normals but keeps the original bake. New seams appear even though the UVs and image settings are unchanged.

Which workflow is most likely to eliminate the mismatch correctly?

  1. Keep the original bake and increase Bump Distance so that the stored vectors override the new shading normals.
  2. Keep the original bake and convert the image to sRGB so that split-normal seams receive smoother interpolation.
  3. Finalize the low-poly shading normals first, then rebake the normal map against that final vertex-normal configuration. (correct answer)
  4. Finalize the high-poly material roughness first, then rebake only the grayscale height information onto the asset.
Explanation: Whenever you see a question about normal map baking in Blender, think about the fundamental dependency: a tangent-space normal map encodes surface direction relative to the vertex normals that existed at bake time. If those normals change afterward, the stored vectors no longer align with the new shading geometry, and visible seams appear — even if UVs and the image itself are untouched. This is exactly why C is correct. The normal map must be baked against the exact vertex-normal configuration the mesh will use at render time. By finalizing smooth-shading boundaries and custom split normals first, then rebaking, you ensure the tangent space matches the shading basis. The result is a consistent, seam-free map that correctly interprets the stored RGB vectors. A is wrong because Bump Distance controls the intensity of a procedural bump effect, not how tangent-space vectors are decoded. Increasing it doesn't reconcile a mismatch between stored normals and new vertex normals — it just amplifies whatever data is already misaligned. B is wrong because color space affects how pixel values are interpreted numerically (linear vs. gamma-corrected), not how split-normal boundaries are blended. Converting to sRGB would actually corrupt the normal map data, since normal maps must remain in linear color space to decode correctly. D is wrong because it addresses roughness and height information from the high-poly mesh — neither of which is relevant to a tangent-space seam caused by changed vertex normals on the low-poly asset. The key study tip: always treat vertex normals as a prerequisite, not an afterthought. Lock down your low-poly shading before you bake — rebaking is the only true fix.

Question 6

A texture was explicitly baked as an object-space normal map for a rigid, nondeforming prop. When it is interpreted as a tangent-space map, the shading directions are incorrect even though the texture is set to Non-Color.

Which setup correctly interprets this texture for the prop?

  1. Send the image into a Bump node's Height input and set the Bump node's Distance to match object scale.
  2. Set the Normal Map node to Tangent space and reverse the image's green channel before decoding.
  3. Connect the image directly to the shader's Normal input and use Generated coordinates for vector conversion.
  4. Set the Normal Map node to Object space and connect its output to the shader's Normal input. (correct answer)
Explanation: When working with pre-baked normal maps in Blender, the critical question is always: what space was the map baked in, and does your decoding node match that space? Normal maps encode surface direction vectors, and the coordinate space used during baking must be preserved during playback — a mismatch produces visually wrong lighting even when color space is correctly set to Non-Color. Since the texture was baked in object space, the Normal Map node must also be set to Object space. This tells Blender to interpret the RGB values as directions relative to the object's local axes, which is exactly what was stored. The node then converts those directions into world space for the shader to use correctly. That makes D the right answer. A is wrong because a Bump node reads a grayscale height value and derives normals via finite differences — it cannot decode a pre-baked normal map (which encodes XYZ directions, not height). Plugging a normal map into Bump's Height input produces meaningless results regardless of Distance settings. B compounds two errors: keeping the node in Tangent space ignores the baking mismatch entirely, and flipping the green channel (a Y-axis convention fix for DirectX vs. OpenGL) is a separate, unrelated problem that doesn't fix a space mismatch. C is wrong because connecting raw image data directly to the Normal input bypasses all decoding. Normal inputs expect vectors in a specific range and format; raw pixel values in 0–1 range will produce badly distorted shading. Generated coordinates don't fix this. Study tip: Whenever you see a normal map, ask yourself two things: Is Non-Color enabled? And does the Normal Map node's space setting match how the map was baked? Those two checks resolve most normal map problems in Blender.

Question 7

A normal map authored for a DirectX-style pipeline is used in Blender. Horizontal details shade correctly, but vertical slopes appear reversed: grooves look raised from one direction and recessed from the opposite direction. The map is already set to Non-Color.

What is the most appropriate correction before the texture is interpreted by the Normal Map node?

  1. Invert the red channel because Blender reverses the tangent vector associated with horizontal texture coordinates.
  2. Invert the green channel because the map's vertical tangent-axis convention is opposite Blender's expected convention. (correct answer)
  3. Invert the blue channel because Blender expects surface-facing normals to use negative depth values.
  4. Invert all three channels because DirectX normal vectors use the opposite coordinate system in every axis.
Explanation: When working with normal maps in Blender, the key concept to understand is the difference between DirectX and OpenGL normal map conventions. These two pipelines disagree on which direction the green channel points along the vertical (tangent Y) axis. DirectX treats the green channel as pointing downward in tangent space, while Blender (following the OpenGL convention) expects it to point upward. When these conventions are mismatched, vertical surface details — slopes, grooves, ridges running horizontally — appear flipped: what should look recessed appears raised, and vice versa. Horizontal details remain unaffected because the red channel (tangent X) is consistent between both conventions. The fix is to invert the green channel before the data reaches the Normal Map node, typically done with an RGB Curves node or a Separate/Combine RGB setup with an Invert on the G channel. This is exactly what B describes, making it the correct answer. A is wrong because the red channel encodes the horizontal tangent axis (X), which agrees between DirectX and OpenGL conventions — inverting it would actually break your horizontal details, not fix them. C is wrong because the blue channel encodes the surface normal's depth (Z), pointing outward from the surface. Both conventions share the same expectation here, so inverting blue would incorrectly flatten or invert surface-facing normals. D is wrong because it overstates the difference. Only the green channel differs between DirectX and OpenGL; inverting all three channels would introduce errors across every axis unnecessarily. A reliable memory aid: "DirectX = flip green." Whenever you import a normal map and only vertical details look reversed, invert the green channel first.

Question 8

A grayscale image is connected to the Height input of a Bump node. It produces the desired detail locations, but an engraved logo appears raised while the surrounding surface appears recessed. The artist wants to preserve the existing texture mapping and contrast.

Which change most directly reverses the relief without altering the texture placement?

  1. Enable Invert on the Bump node so that the height gradient perturbs normals in the opposite direction. (correct answer)
  2. Change the image from Non-Color to sRGB so that dark height values are interpreted as deeper geometry.
  3. Connect the grayscale image to the Bump node's Normal input so that its luminance becomes a vector direction.
  4. Change the shader normal from smooth to flat so that dark portions of the image face inward.
Explanation: When working with Bump nodes in Blender, it helps to think of the grayscale image as a height map: bright pixels = raised, dark pixels = recessed. The Bump node converts those luminance differences into normal perturbations that simulate surface depth. If your relief is inverted — logo looks raised when it should be engraved — you simply need to flip the direction those normals are perturbed, without touching the image itself or its mapping. That's exactly what the Invert checkbox on the Bump node does. It negates the height gradient internally, so bright areas now push normals inward (recessed) and dark areas push outward (raised). The texture coordinates, contrast, and image data remain completely untouched — making A the most direct, non-destructive fix. B is wrong because switching the color space from Non-Color to sRGB doesn't invert the height relationship — it applies a gamma curve to the luminance values, which distorts the contrast and brightness of the height map rather than cleanly reversing it. C is a fundamental misuse of the node: the Normal input expects a vector (typically from a Normal Map node), not a grayscale height value. Plugging raw luminance there produces unpredictable, broken results. D confuses shading interpolation (smooth vs. flat) with height-map direction — flat shading affects how polygon face normals are blended across a mesh, not how a bump map's light/dark values are interpreted. As a study habit, remember that Blender's Bump node has two levers for controlling relief: Strength (intensity) and Invert (direction). When relief is backwards, reach for Invert first — it's a single checkbox with zero side effects.

Question 9

A smooth plaster material uses an 8-bit grayscale image as a subtle Bump Height source. Broad gradients in the image produce visible stepping in specular highlights. The texture already has sufficient pixel resolution, uses Non-Color data, and is not being enlarged.

Which change most directly addresses the likely cause of the stepping while retaining a height-based bump workflow?

  1. Connect the grayscale source to the Normal input instead, so that Blender reinterprets the scalar values as a three-component direction vector.
  2. Convert the grayscale source to sRGB so that gamma encoding redistributes existing values and generates smoother physical height transitions.
  3. Increase the Bump Strength so that the perceptual differences between adjacent 8-bit height levels are amplified into smoother-looking steps.
  4. Replace the source with a higher-bit-depth height image so that the subtle gradient has more distinct numerical levels and finer height increments. (correct answer)
Explanation: When working with bump mapping in Blender, the key concept to understand is bit depth and quantization. An 8-bit grayscale image contains exactly 256 distinct numerical values (0–255). When a subtle gradient spans, say, 50 of those values across a large surface area, each "step" between adjacent values becomes a visible discontinuity — especially in specular highlights, which are extremely sensitive to surface normal changes. This is classic banding, caused by insufficient numerical precision in the source data, not by resolution, colorspace, or strength settings. Replacing the source with a 16-bit or 32-bit height image — answer D — dramatically increases the number of available levels (65,536 or ~4 billion, respectively), giving the gradient far finer increments. The bump node then sees smooth, nearly continuous height transitions, eliminating the stepping at its root cause. A is wrong because connecting a scalar grayscale value directly to the Normal input doesn't produce valid direction vectors — you'd get unpredictable shading artifacts, not smoother bumps. The height-based workflow would also be abandoned entirely, violating the question's constraint. B is a misconception. Converting Non-Color data to sRGB doesn't generate new height values — it remaps the same 256 levels with a gamma curve. You're redistributing existing steps, not adding finer ones. Banding persists. C is a trap. Increasing Bump Strength amplifies the difference between steps, making the banding more noticeable, not less. Higher strength is the opposite of what you want. Remember: banding problems are always a precision problem — reach for more bits, not more strength.

Question 10

A material must use a baked tangent-space normal map for large scratches and a procedural Noise Texture as a grayscale height source for fine pores. Both effects must contribute to the final shading normal.

Which node connection order combines the two effects correctly?

  1. Connect the normal map to Bump Height, the noise to Bump Normal, and the Bump output to Principled Normal.
  2. Connect the noise to Normal Map Color, the normal texture to Bump Height, and the Bump output to Principled Normal.
  3. Connect the Normal Map output to Bump Normal, the noise to Bump Height, and the Bump output to Principled Normal. (correct answer)
  4. Connect both textures through a Mix Color node, then send the mixed color directly to the Principled Normal input.
Explanation: When combining a baked normal map with a procedural height source in Blender, you need to understand how the Bump and Normal Map nodes handle different data types. The Normal Map node converts tangent-space RGB data (from a baked texture) into a proper normal vector. The Bump node, separately, converts a grayscale height/displacement value into a normal vector — and critically, it has a Normal input that lets you chain an existing normal into it, layering the effects. This chaining behavior is exactly what makes C correct. You plug the Normal Map node's output into the Bump node's Normal socket, then plug the Noise Texture into the Bump node's Height socket. The Bump node takes both into account — it starts from the already-decoded normal and perturbs it further using the height data. The final Bump output then goes to the Principled BSDF's Normal input, delivering both contributions to shading. Answer A fails because it reverses the roles: normal map data is not a grayscale height value and cannot be meaningfully plugged into the Bump Height input. Answer B makes the same type-mismatch mistake in reverse — noise is a grayscale float, not encoded tangent-space color data, so feeding it into the Normal Map's Color input produces incorrect results. Answer D is a common-looking shortcut that doesn't work: mixing the two textures as colors before decoding them destroys the encoded normal information, and raw color data sent directly to the Principled Normal input is meaningless without a Normal Map or Bump node interpreting it. A reliable rule of thumb: baked normals always need a Normal Map node first; grayscale heights always go into Bump Height. Chain them by connecting Normal Map → Bump Normal, never the reverse.