Blender Quiz: Use Snapping And Transform Constraints Axis Locks Increments Intro

10 questions · exam conditions

0:00

Use Snapping And Transform Constraints Axis Locks Increments IntroQuestion 1 of 10

An object has been rotated so that its local X axis no longer matches the global X axis. The transform orientation is left at its default setting.

Which key sequence moves the object along its local X axis rather than the global X axis?

Press G, then press X once, and move the pointer.

Press G, then press X twice, and move the pointer.

Press G, then press Shift+X, and move the pointer.

Press G, then press Ctrl+X, and move the pointer.

← Back to quizzes

Blender Quiz

Blender Quiz: Use Snapping And Transform Constraints Axis Locks Increments Intro

Practice Use Snapping And Transform Constraints Axis Locks Increments 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 Snapping And Transform Constraints Axis Locks Increments 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

An object has been rotated so that its local X axis no longer matches the global X axis. The transform orientation is left at its default setting.

Which key sequence moves the object along its local X axis rather than the global X axis?

Press G, then press X once, and move the pointer.
Press G, then press X twice, and move the pointer. (correct answer)
Press G, then press Shift+X, and move the pointer.
Press G, then press Ctrl+X, and move the pointer.

Explanation: When working with object transforms in Blender, it's essential to understand the difference between global axes and local axes — especially after an object has been rotated, since its local axes will diverge from the world axes. Pressing G initiates a grab/move operation. From there, pressing an axis key like X once constrains movement to the global X axis — this is the default behavior regardless of transform orientation settings. The key insight is that pressing the same axis key a second time toggles the constraint to the object's local axis instead. So pressing G → X → X moves the object along its own local X axis, which is exactly what the passage describes needing. This makes B the correct answer. A is wrong because pressing X only once locks movement to the global X axis, not the local one. Since the object has been rotated, these are different directions, so this would produce the wrong result. C is a tempting distractor. Shift+X does exist in Blender, but it constrains movement to the global YZ plane (everything except global X), not the local axis — so this doesn't solve the problem either. D is incorrect because Ctrl+X has no special axis-switching function during a grab operation. Holding Ctrl during a transform snaps movement to grid increments, not local axes. A handy memory trick: double-tap the axis key to go local. Think of the first press as "global" and the second press as "drilling deeper" into the object's own orientation.

Question 2

An object begins with scale values $X=1, Y=1, Z=1$ . Its transform orientation is Global, and no other scale locks are enabled.

The user presses S, Shift+Z, types 2, and confirms. Which scale values result?

$X=2, Y=2, Z=1$ because the Z axis is excluded. (correct answer)
$X=1, Y=1, Z=2$ because scaling is constrained to Z.
$X=2, Y=2, Z=2$ because numeric scaling remains uniform.
$X=1, Y=2, Z=2$ because the X axis is excluded.

Explanation: When scaling in Blender, the Shift modifier inverts the axis constraint — instead of locking movement to an axis, it excludes that axis from the transformation. This is the core concept being tested here. When you press S, Shift+Z, you're telling Blender: "Scale everything except the Z axis." Typing 2 then applies a factor of 2 to the remaining axes — X and Y. Since the object starts at

X=1, Y=1, Z=1

, the result is

X=2, Y=2, Z=1

, which is answer A. Answer B (

X=1, Y=1, Z=2

) describes what would happen if you pressed S, Z, 2 — a direct Z-axis constraint, not an exclusion. This is the most common trap on axis-constraint questions. Answer C (

X=2, Y=2, Z=2

) would result from a plain S, 2 with no axis modifier at all — uniform scaling across all three axes. Answer D (

X=1, Y=2, Z=2

) doesn't correspond to any standard Blender shortcut in this context. It would require excluding the X axis, which would be Shift+X, not Shift+Z. A reliable memory trick: in Blender, Shift + axis key = scale the axes you didn't name. Think of it as "everything but Z." Whenever you see Shift combined with an axis key in a transform question, immediately flip your thinking — the named axis is the one being protected, not targeted.

Question 3

While moving an object, a user presses X to constrain the move, then presses Z because the intended movement should occur only along global Z.

What constraint is active after the second axis key is pressed, and what sequence would instead allow movement in the global XY plane?

X alone remains active; pressing G, then Shift+X, permits movement in XY.
The XZ plane is active; pressing G, then Z, permits movement in XY.
Z alone is active; pressing G, then Shift+Z, permits movement in XY. (correct answer)
All axes become active; pressing G, then X, then Y, permits movement in XY.

Explanation: When working with Blender's transform constraints, you need to understand two distinct behaviors: pressing an axis key once locks movement to that axis, while holding Shift and pressing an axis key locks movement to the plane perpendicular to that axis. Here's what happens in the scenario: the user presses G to grab, then X to constrain to the X axis — but then presses Z. That second keypress overrides the first, switching the constraint entirely to the global Z axis. Blender doesn't combine them into a plane; it simply replaces the active constraint. So after both keypresses, only Z-axis movement is active — making C the correct answer. To move freely within the global XY plane instead, you'd press G, then Shift+Z, because Shift+Z means "exclude Z," leaving you free to move in the XY plane. Answer A is wrong on both counts: pressing X then Z doesn't keep X active, and Shift+X constrains to the YZ plane, not XY. Answer B describes an "XZ plane" constraint, which isn't what sequential axis presses produce — and Z alone constrains to the Z axis, not a plane. Answer D incorrectly claims all axes become active after sequential presses, and chaining X then Y would just leave you constrained to Y alone, not a plane. A helpful memory trick: Shift + axis = plane constraint (you're excluding that axis). So Shift+Z = "everything but Z" = the XY plane. Keep this Shift-flips-the-logic rule in mind whenever plane movement comes up.

Question 4

In Edit Mode, two selected vertices lie at X coordinates $1$ and $3$ . Vertex snapping uses Closest as the snap base. The user moves the selection along X and snaps to a target vertex at X coordinate $10$ . The selected vertex at X coordinate $3$ is the one closest to the target.

What are the selected vertices' final X coordinates?

$7$ and $9$ because the target coordinate is treated as a movement amount.
$10$ and $12$ because the first selected vertex supplies the snap base.
$9$ and $11$ because the selection's midpoint supplies the snap base.
$8$ and $10$ because the closest selected vertex supplies the snap base. (correct answer)

Explanation: Whenever you see a question about vertex snapping in Blender, the key concept to nail down is the snap base — the reference point on your selection that aligns to the target. Different snap base modes use different reference points, and the offset applied to the entire selection is determined by that single reference point. With Closest as the snap base, Blender identifies whichever selected vertex is nearest to the snap target and uses that vertex as the anchor. The movement delta is calculated so that the closest vertex lands exactly on the target, and every other selected vertex shifts by that same delta. Here's the math for answer D: The closest vertex sits at

X = 3

, and the target is at

X = 10

. The delta is

10 - 3 = 7

. Applying that offset to both vertices:

1 + 7 = 8

and

3 + 7 = 10

. Final positions:

8

and

10

— confirming D is correct. Answer A misreads how snapping works entirely — the target coordinate is a position, not a movement amount. Treating

10

as a delta would be a fundamental misunderstanding of the snapping system. Answer B describes the Active Element snap base, where the active (first-selected) vertex at

X = 3

anchors the snap, giving

3 + 7 = 10

and

1 + 7 = 8

— wait, that's actually the same result here, but B claims the vertex at

X = 1

is first, yielding

10

and

12

, which reflects a misidentification of the active element. Answer C describes the Median Point snap base, where the midpoint

\frac{1+3}{2} = 2

anchors the snap, producing a delta of

8

, giving

9

and

11

. As a study tip, memorize all three snap base modes — Closest, Active, and Median — by pairing each with its reference point. Exam questions will swap these modes to test whether you truly understand which vertex drives the offset calculation.

Question 5

Three vertices are selected in Edit Mode. Their X coordinates are $2$ , $5$ , and $7$ , and the vertex at $2$ is active. Vertex snapping is configured to use Active as the snap base. The selection is moved along X and snapped to a target at X coordinate $10$ .

Which set of final X coordinates is expected?

$2, 5, 10$ because only the active vertex is moved to the target.
$7, 10, 12$ because the median vertex is aligned to the target.
$5, 8, 10$ because the closest vertex is aligned to the target.
$10, 13, 15$ because the active vertex is aligned to the target. (correct answer)

Explanation: When you move a selection with snapping enabled in Blender, the snap base determines which reference point on your selection aligns to the target. Understanding this is the key to this question. With the snap base set to Active, Blender calculates the offset needed to bring the active vertex to the snap target, then applies that same offset to every selected vertex. Think of the entire selection moving as a rigid group — no vertex is left behind, and no relative spacing changes. Here, the active vertex sits at

X = 2

, and the target is at

X = 10

. The required offset is

10 - 2 = 8

. Adding

8

to every selected vertex gives

2 + 8 = 10

5 + 8 = 13

, and

7 + 8 = 15

. That confirms D is correct. A is wrong because it assumes only the active vertex moves while the others stay fixed — snapping moves the entire selection together, not just one vertex. B describes the behavior of the Median snap base, where the geometric center of the selection aligns to the target. With a median of

\frac{2+5+7}{3} \approx 4.67

, that offset would produce different results entirely. C describes the Closest snap base, which aligns whichever selected vertex is nearest to the target — in this case,

7

— shifting everything by

3

. A useful tip: memorize what each snap base references — Active, Median, Closest, and Center — because Blender exam questions frequently swap these terms to test whether you know exactly which point drives the offset calculation.

Question 6

The snapping magnet is enabled, and Vertex is the selected snap target. While moving an object, the user wants to pass near several vertices without snapping, but does not want to change the persistent magnet setting.

What should the user do during the transform?

Hold Ctrl temporarily, then release it before confirming the move. (correct answer)
Hold Shift temporarily, then release it before confirming the move.
Press X temporarily, then press X again before confirming the move.
Hold Alt temporarily, then release it before confirming the move.

Explanation: When working with Blender's snapping system, it helps to distinguish between persistent settings (toggles you set in the header that stay active) and temporary overrides (modifier keys held during a transform that flip the behavior only while held). This question tests exactly that distinction. Blender's snapping system lets you temporarily invert the current snap state by holding Ctrl during a grab, rotate, or scale operation. If snapping is currently on, holding Ctrl turns it off for as long as you hold the key — and the moment you release it, snapping resumes. This is the answer to choice A: holding Ctrl lets you glide freely past vertices without committing to a snap, and releasing it restores normal behavior — all without touching the persistent magnet toggle in the header. Choice B is wrong because Shift during a transform activates precision mode (slower, finer movement), not a snap override. Choice C is wrong because X during a grab constrains the axis to the X axis — it has nothing to do with toggling snapping. Choice D is wrong because Alt during transforms typically relates to proportional editing or has no snapping function in this context; it does not serve as a snap inversion key. A useful memory device: think of Ctrl as the "snap negotiator" — it works both ways. If snapping is off and you want to snap temporarily, hold Ctrl. If snapping is on and you don't want to snap temporarily, hold Ctrl. The key is always Ctrl; the direction just flips based on your current state.

Question 7

An object already has a Z rotation of $12^\circ$ . The user begins another Z-axis rotation and holds Ctrl for ordinary rotation-increment snapping. The intended positive rotation delta is slightly more than the default coarse increment of $5^\circ$ but less than $7.5^\circ$ .

What final Z rotation should the user expect when the snapped transform is confirmed?

$18^\circ$ because the unsnapped pointer delta is added directly.
$15^\circ$ because the final orientation snaps to a global multiple.
$17^\circ$ because the rotation delta snaps to $+5^\circ$ . (correct answer)
$22^\circ$ because the rotation delta snaps to $+10^\circ$ .

Explanation: When working with Blender's Ctrl-snapping during rotation, it's crucial to understand what is being snapped: the delta (change) in rotation, not the final absolute angle. The default coarse increment is

5^\circ

, meaning your rotation input snaps to the nearest multiple of

5^\circ

relative to where you started — not relative to the world origin. In this scenario, the object starts at

12^\circ

Z rotation. The user intends a positive delta slightly above

5^\circ

but below

7.5^\circ

. With Ctrl held, Blender snaps that delta to the nearest

5^\circ

increment. Since the intended delta is closer to

5^\circ

than to

10^\circ

, it snaps down to

+5^\circ

. The final rotation becomes

12^\circ + 5^\circ = 17^\circ

, confirming C as correct. A is wrong because Ctrl snapping overrides the raw pointer delta — the whole point of holding Ctrl is to quantize the input, not pass it through unaltered. B reflects a common misconception: snapping does not align to global multiples of

5^\circ

(like

15^\circ

20^\circ

); it snaps the delta to

5^\circ

increments, which only coincidentally lands on a global multiple if your starting angle is itself a multiple. D would require the delta to snap to

+10^\circ

, but the intended input is less than

7.5^\circ

— the midpoint between

5^\circ

and

10^\circ

— so it rounds down, not up. A quick rule to remember: Ctrl snapping in Blender always quantizes the change, not the result. Keep your starting angle in mind when predicting where you'll land.

Question 8

Face snapping is enabled for an object being moved onto a sloped surface. Align Rotation to Target is also enabled, and the move has no axis constraint. The object's orientation does not initially match the surface.

What result should be expected when the object snaps to the sloped face?

Its position snaps to the face, and its rotation adjusts to the target face orientation. (correct answer)
Its position snaps to the face, but its original rotation is always preserved.
Its rotation adjusts to the face, but its position remains at the starting point.
Its scale adjusts to the face slope while its position and rotation remain unchanged.

Explanation: When working with snapping in Blender, it helps to think of each snap option as controlling a specific aspect of the transform operation. Face snapping controls where the object lands (position), while Align Rotation to Target is a secondary toggle that independently controls whether the object's rotation conforms to the snapped surface's normal. Understanding these as two separate, cooperative settings is the key to this question. With both face snapping and Align Rotation to Target enabled — and no axis constraint locking rotation — Blender applies both effects simultaneously. The object's origin snaps to the face (updating position), and its rotation is recalculated to match the face's normal direction. This is exactly what answer A describes, making it correct. Answer B is tempting if you think snapping only affects position, but that ignores what Align Rotation to Target explicitly does — it overrides the original rotation to match the target surface. Answer C describes a scenario where snapping somehow updates rotation but not position, which inverts the actual behavior; snapping's primary job is positional, with rotation alignment as a supplementary effect. Answer D introduces scale adjustment, which snapping in Blender never modifies — scale is entirely unrelated to face snapping behavior, so this is a fabricated distractor. A useful tip: on Blender exam questions involving snapping, always check which snap options are enabled. Face snapping and Align Rotation to Target are separate toggles that stack together. If both are on with no constraints, both position and rotation are affected — that combination is the signature of answer A.

Question 9

Grid spacing is $1$ Blender unit. An object's X location is initially $0.3$ . During an X-constrained move, the pointer indicates a displacement of approximately $+0.6$ , which increment snapping rounds to a displacement of $+1.0$ .

How does enabling Absolute Grid Snap change the likely final X location compared with ordinary relative increment snapping?

Relative snapping gives $1.3$ , while absolute snapping places it at $1.0$ . (correct answer)
Relative snapping gives $1.0$ , while absolute snapping places it at $1.3$ .
Both modes give $1.3$ because each rounds only the movement delta.
Both modes give $1.0$ because each aligns the final location to the grid.

Explanation: When working with snapping in Blender, the critical distinction to understand is what gets snapped — the movement delta, or the final world position. With ordinary relative increment snapping, Blender rounds the displacement to the nearest grid increment. Your pointer shows roughly

+0.6

, which rounds up to

+1.0

. That rounded delta is then added to your starting position:

0.3 + 1.0 = 1.3

. The object lands at

1.3

, which is not on any grid line. With Absolute Grid Snap, Blender ignores the delta entirely and instead snaps the object's final world coordinate to the nearest grid point. The nearest grid value to the pointer's indicated destination (roughly

0.3 + 0.6 = 0.9

) is

1.0

, so the object lands exactly at

1.0

. This is the behavior that makes option A correct: relative gives

1.3

, absolute gives

1.0

. Option B reverses the two results, which reflects a misunderstanding of which mode rounds the delta versus the position. Option C is wrong because relative snapping does not produce a grid-aligned result when your start position is off-grid —

1.3

is not a grid point. Option D is wrong because relative snapping specifically does not align the final location to the grid; only absolute snapping guarantees that. A useful memory aid: "Relative" = round the ride, "Absolute" = round the destination. Whenever a question gives you an off-grid starting position, that's your signal to check whether snapping applies to the delta or the final coordinate — the answer will hinge on exactly that difference.

Question 10

An object's snap base is its origin at $(1,2,0)$ . Vertex snapping is active. The user starts moving the object, constrains movement to global X, and snaps toward a target vertex at $(6,8,0)$ .

Assuming the snap is accepted, where will the object's origin be placed?

At $(6,8,0)$ because vertex snapping overrides the active axis constraint.
At $(6,2,0)$ because the target determines X while Y and Z remain constrained. (correct answer)
At $(1,8,0)$ because the X constraint prevents the X coordinate from changing.
At $(5,2,0)$ because snapping applies the target's X coordinate as a displacement.

Explanation: When Blender combines axis constraints with vertex snapping, the two systems work together rather than one overriding the other. The axis constraint defines which coordinate(s) can change, and the snap target provides the new value only along the permitted axis. Any axis not included in the constraint stays locked to its original value. Here, the object's origin starts at

(1, 2, 0)

and movement is constrained to global X. That means only the X coordinate is free to update — Y and Z are frozen. When you snap toward the target vertex at

(6, 8, 0)

, Blender adopts the target's X value of

6

for the moving object, while Y remains

2

and Z remains

0

. The result is

(6, 2, 0)

, confirming B. A is wrong because axis constraints are not overridden by vertex snapping. The snap finds the nearest point along the constrained axis that aligns with the target, not the target's full position. C reflects a backwards reading of the constraint — constraining to X means X is the axis that changes, not the one that's locked. It's Y and Z that stay fixed. D introduces a displacement interpretation that doesn't apply here; vertex snapping in Blender moves the snap base to the target's coordinate on the free axis, not by adding an offset derived from that coordinate. A quick mental rule: the axis constraint acts like a rail. Snapping slides you along that rail to the position that best aligns with your target — the locked axes never move.