Blender Quiz: Use The Timeline And Dope Sheet To Adjust Keyframe Timing Intro

10 questions · exam conditions

0:00

Use The Timeline And Dope Sheet To Adjust Keyframe Timing IntroQuestion 1 of 10

Two selected keyframes are at frames $10$ and $22$ . The animator presses Shift+D, moves the duplicates $15$ frames to the right, and confirms.

Which set of keyframes will exist after the operation?

Only frames

25

and

37

, because duplication replaces the selected source keyframes.

Frames

10

22

, and

37

, because only the last selected key is duplicated.

Frames

10

15

22

, and

27

, because

15

is treated as a destination.

Frames

10

22

25

, and

37

, because the originals and shifted copies remain.

← Back to quizzes

Blender Quiz

Blender Quiz: Use The Timeline And Dope Sheet To Adjust Keyframe Timing Intro

Practice Use The Timeline And Dope Sheet To Adjust Keyframe Timing 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 The Timeline And Dope Sheet To Adjust Keyframe Timing 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

Two selected keyframes are at frames $10$ and $22$ . The animator presses Shift+D, moves the duplicates $15$ frames to the right, and confirms.

Which set of keyframes will exist after the operation?

Only frames $25$ and $37$ , because duplication replaces the selected source keyframes.
Frames $10$ , $22$ , and $37$ , because only the last selected key is duplicated.
Frames $10$ , $15$ , $22$ , and $27$ , because $15$ is treated as a destination.
Frames $10$ , $22$ , $25$ , and $37$ , because the originals and shifted copies remain. (correct answer)

Explanation: Whenever you see a question about duplicating keyframes in Blender's timeline or Graph Editor, the critical concept to keep in mind is that Shift+D duplicates non-destructively — it creates copies while leaving the originals completely intact, exactly like duplicating objects in the 3D viewport. Here's the logic: you start with keyframes at frames

10

and

22

. Pressing Shift+D creates two new keyframes that are initially sitting on top of the originals. Moving them

15

frames to the right shifts those copies to

10 + 15 = 25

and

22 + 15 = 37

. The originals at

10

and

22

were never touched, so the final result is four keyframes:

10

22

25

, and

37

— making D the correct answer. Choice A confuses duplication with a move operation. If you had pressed G instead of Shift+D, the originals would relocate, but Shift+D explicitly preserves them. Choice B reflects a misunderstanding that only one keyframe gets duplicated — Shift+D always duplicates the entire selection, both keyframes in this case. Choice C misreads the

15

-frame offset as an absolute destination frame rather than a relative displacement;

15

is how far you move, not where you land. A useful memory trick: think of Shift+D in Blender as "Shift = Stay" — the originals stay, and the duplicates move. Any time a question mentions Shift+D followed by movement, expect the original keyframes to survive unchanged alongside the newly placed copies.

Question 2

A scene's playback range ends at frame $120$ . In the Dope Sheet, a selected keyframe at frame $110$ is moved $20$ frames later.

What should the animator expect after confirming the move?

The key is clamped to frame $120$ because keyframes cannot exist beyond the playback range.
The key remains at frame $130$ , but normal playback stops before reaching it unless the end frame changes. (correct answer)
The key moves to frame $130$ , and Blender automatically changes the scene end to frame $130$ .
The key is removed from the action because its new time is outside the playback range.

Explanation: Whenever you see a question about keyframe placement in Blender, remember the key distinction: the playback range and the Action/timeline data are independent systems. The playback range (set by your scene's start and end frames) controls what Blender previews, not where keyframes are allowed to exist. In Blender's Dope Sheet, moving a keyframe at frame

110

+20

frames places it at frame

130

. Blender does not restrict or clamp keyframe placement to your scene's playback range — keyframes can exist freely at any frame number, including beyond frame

120

. The move completes exactly as specified, landing at frame

130

. However, since the scene end is still frame

120

, normal playback will stop there and never reach the keyframe. The data is intact; it's simply outside the previewed window. This makes B correct. A is wrong because Blender does not clamp keyframes to the playback range. There is no such restriction — keyframes are timeline data, not bound by playback boundaries. C is wrong because Blender does not automatically adjust the scene end frame when you move a keyframe beyond it. That would require manual intervention in the Output Properties or timeline header. D is wrong because keyframes are never deleted for being outside the playback range. They remain part of the action and will animate the object if playback ever reaches that frame. A useful rule of thumb: think of the playback range as a viewing window, not a container. Keyframes exist on an infinite timeline; your end frame just determines how far the window opens.

Question 3

The current frame is $50$ . Selected keyframes are at frames $42$ , $47$ , and $55$ . The animator uses Key > Mirror > By Times over Current Frame.

Where will the mirrored keyframes be located?

Frames $38$ , $43$ , and $55$ , because each selected frame is shifted by the earliest offset.
Frames $42$ , $53$ , and $58$ , because only keyframes before the current frame are mirrored.
Frames $45$ , $53$ , and $58$ , because every time is reflected across frame $50$ . (correct answer)
Frames $42$ , $47$ , and $55$ , because mirroring changes values but not keyframe times.

Explanation: When you see Mirror > By Times over Current Frame in Blender's Graph Editor or Dopesheet, think of it as a pure geometric reflection: every selected keyframe's time is flipped across the current frame, exactly like reflecting a point across a number line. The formula is simple:

t_{\text{new}} = 2 \times t_{\text{current}} - t_{\text{original}}

. With the current frame at

50

Frame $42$ : $2(50) - 42 = 58$
Frame $47$ : $2(50) - 47 = 53$
Frame $55$ : $2(50) - 55 = 45$

So the mirrored keyframes land at

45

53

, and

58

— confirming C is correct. A is wrong because it invents a rule about shifting by the "earliest offset," which has nothing to do with how mirroring works. Mirroring is reflection, not uniform shifting. B describes a selective mirror that only affects keyframes before the current frame — Blender mirrors all selected keyframes regardless of which side of the current frame they sit on, so frame

42

and

47

both get reflected, not left alone. D confuses value mirroring (which flips the keyframe's data value, such as a rotation amount) with time mirroring — "By Times" explicitly operates on the temporal position, not the stored value. A useful memory trick: "By Times" = reflect when the keyframe happens; "By Values" = reflect what value it holds. Keep those two axes distinct, and mirror questions in Blender become straightforward arithmetic.

Question 4

After temporal scaling, selected keyframes lie at frames $12.2$ , $12.8$ , and $20.4$ . The animator chooses Key > Snap > Nearest Frame in the Dope Sheet.

What timing results from the snap operation?

The keys move to frames $12$ , $12$ , and $20$ because all fractional values are truncated.
The keys move to frames $12$ , $13$ , and $20$ because each time is rounded independently. (correct answer)
The keys move to frames $13$ , $13$ , and $21$ because every fractional value rounds upward.
The keys move to frames $12$ , $13$ , and $21$ because the entire selection shifts together.

Explanation: Whenever you see a question about snapping keyframes in Blender's Dope Sheet, focus on what "nearest frame" actually means mathematically: each keyframe is rounded independently to whichever whole frame number it sits closest to — standard rounding rules apply (

\geq 0.5

rounds up,

< 0.5

rounds down). Walking through the three keyframes:

12.2

is closer to

12

than to

13

(distance of

0.2

0.8

), so it snaps to

12

. Next,

12.8

is closer to

13

than to

12

(distance of

0.2

0.8

), so it snaps to

13

. Finally,

20.4

is closer to

20

than to

21

, landing at

20

. The result is frames

12

13

, and

20

— confirming B is correct. Choice A is wrong because it describes truncation (always dropping the decimal), not rounding. Truncation would incorrectly place

12.8

12

. Choice C is wrong because it describes ceiling behavior (always rounding up), which would incorrectly move

12.2

and

20.4

upward when they're clearly closer to the lower frame. Choice D describes a group-shift behavior that doesn't exist in this operation — "Nearest Frame" never moves the entire selection as a unit; it processes each keyframe independently. A useful tip: on Blender exam questions, distinguish between the three snapping behaviors — truncate, round (nearest), and ceiling — by testing a value like

0.2

in your head. If it goes down, it's nearest or truncate; if it goes up, it's ceiling. That quick check will eliminate two distractors instantly.

Question 5

In the Dope Sheet, three selected keyframes are at frames $12$ , $24$ , and $36$ . They must all occur exactly $8$ frames later without changing the spacing between them.

Which operation produces the required timing?

Press G, enter $8$ , and confirm, producing frames $20$ , $32$ , and $44$ . (correct answer)
Press G, enter $-8$ , and confirm, producing frames $4$ , $16$ , and $28$ .
Press S, enter $8$ , and confirm, greatly expanding the spacing around the pivot.
Press G, enter $20$ , and confirm, placing the first keyframe at frame $32$ .

Explanation: When working in Blender's Dope Sheet, it helps to think of keyframe manipulation in terms of two distinct operations: translation (shifting timing) and scaling (changing spacing). The question asks you to move all selected keyframes by a fixed offset while preserving the gaps between them — that's a pure translation. Pressing G activates the Grab/Move tool, which shifts keyframes by a typed offset without altering their relative spacing. If your keyframes sit at frames

12

24

, and

36

, adding

+8

to each produces

12+8=20

24+8=32

, and

36+8=44

. The spacing remains

12

frames apart throughout. That's exactly what A does — making it the correct answer. B is wrong because entering

-8

moves the keyframes earlier in time, landing at frames

4

16

, and

28

— the opposite direction of what's required. C is wrong because pressing S activates the Scale tool, which stretches or compresses keyframe timing around a pivot point. Entering

8

would multiply the spacing by

8

, dramatically expanding the gaps rather than shifting uniformly. D is wrong because entering

20

with G offsets every keyframe by

20

frames, placing them at

32

44

, and

56

— not the

8

-frame shift the question demands. A useful rule of thumb: whenever you see "shift everything by X frames," reach for G + the offset value. Reserve S for questions about stretching or compressing timing. Mixing these two up is one of the most common Dope Sheet mistakes.

Question 6

Selected keyframes occur at frames $20$ , $30$ , and $40$ . The Dope Sheet pivot is set to Median Point. The animator presses S, enters $0.5$ , and confirms.

At which frames will the selected keyframes be located?

Frames $10$ , $15$ , and $20$ , because every frame number is multiplied by $0.5$ .
Frames $20$ , $25$ , and $30$ , because scaling is anchored at the first selected key.
Frames $25$ , $30$ , and $35$ , because their offsets from the median are halved. (correct answer)
Frames $15$ , $25$ , and $35$ , because scaling subtracts an equal frame offset.

Explanation: Whenever you see a scaling operation in Blender's Dope Sheet, the critical question to ask is: what is the pivot point, and where does it sit? Scaling always contracts or expands keyframe positions relative to the pivot — it does not simply multiply raw frame numbers. With Median Point selected, Blender first finds the average (median) of the selected keyframes:

(20 + 30 + 40) / 3 = 30

. That frame — 30 — becomes the fixed anchor. Each keyframe's offset from frame 30 is then multiplied by the scale factor of

0.5

. Frame 20 is

-10

away, so its new offset is

-5

, landing at frame

25

. Frame 30 is

0

away, so it stays at

30

. Frame 40 is

+10

away, so its new offset is

+5

, landing at frame

35

. That gives you frames 25, 30, and 35 — confirming C is correct. A is wrong because it multiplies raw frame numbers by

0.5

, ignoring the pivot entirely — scaling never works that way. B incorrectly anchors the scale to the first selected keyframe (frame 20) rather than the median; if frame 20 were the pivot, you'd get frames 20, 25, and 30, which matches B's output but uses the wrong pivot logic. D imagines scaling as a flat subtraction of equal offsets, which is not how multiplicative scaling works. The key study tip: always identify the pivot before calculating. Different pivot choices (Individual Origins, Cursor, Median) produce completely different results for the same scale value.

Question 7

An object has X Location and Y Location keyframes at frames $5$ and $15$ . In the Dope Sheet, only the two X Location keyframes are box-selected. The animator presses G, enters $10$ , and confirms.

What is the resulting keyframe arrangement?

X Location moves to frames $15$ and $25$ , while Y Location remains at frames $5$ and $15$ . (correct answer)
Both channels move to frames $15$ and $25$ because their original keyframe times matched.
X Location moves to frames $10$ and $20$ , while Y Location remains at frames $5$ and $15$ .
X Location remains at frames $5$ and $15$ , while the playhead moves forward by $10$ frames.

Explanation: When working with the Dope Sheet, the critical concept to understand is selection-based editing: transform operations like G (grab/move) only affect the keyframes you have explicitly selected, regardless of what other keyframes exist on other channels. Here's the logic: you have X Location and Y Location keyframes at frames

5

and

15

. Only the two X Location keyframes are box-selected. Pressing G, typing

10

, and confirming translates those selected keyframes forward by

10

frames — so X Location moves from

5 \to 15

and

15 \to 25

. The Y Location keyframes were never selected, so Blender leaves them completely untouched at frames

5

and

15

. That makes A the correct answer. B is wrong because Blender doesn't compare channel values or check whether keyframe times "matched" across channels — it simply moves what is selected and ignores everything else. The fact that Y Location originally shared the same frame numbers is irrelevant. C describes a relative offset of

10

applied starting from frame

1

(landing at

10

and

20

), which misreads how the G transform works. Entering

10

after G means move by

10

frames, not move to frame

10

. The keyframes start at

5

and

15

, so adding

10

gives

15

and

25

, not

10

and

20

. D confuses Dope Sheet keyframe editing with moving the playhead — pressing G on selected keyframes moves those keyframes, not the current frame indicator. Study tip: Always check what is selected before applying any transform in the Dope Sheet. Selection scope is everything — unselected channels are completely immune to edits.

Question 8

The current frame is $30$ , and selected keyframes are at frames $10$ , $20$ , $40$ , and $50$ . The mouse pointer is to the right of the current frame. The animator invokes Time Extend and drags exactly $8$ frames to the right.

What is the resulting timing?

The keys become $18$ , $28$ , $48$ , and $58$ because all selected keys move together.
The keys become $10$ , $20$ , $40$ , and $50$ because Time Extend affects only unselected keys.
The keys become $2$ , $12$ , $40$ , and $50$ because the opposite side moves left.
The keys become $10$ , $20$ , $48$ , and $58$ because only the pointer side is extended. (correct answer)

Explanation: When working with Time Extend in Blender, the key concept to understand is that this tool splits keyframes into two groups based on the current frame and which side the mouse pointer is on — it only moves keys on the pointer's side of the current frame, leaving the other side untouched. Here, the current frame is

30

, and the mouse is to the right. This means Time Extend affects only keyframes that are to the right of frame

30

. Looking at the selected keys —

10

20

40

, and

50

— only frames

40

and

50

qualify. Dragging

8

frames to the right shifts each of those by

+8

, giving you

48

and

58

. The keys at

10

and

20

sit on the left side of the current frame, so they stay exactly where they are. That confirms D. A is wrong because it assumes all selected keys move together uniformly, ignoring the directional split that Time Extend enforces around the current frame. B incorrectly claims Time Extend only affects unselected keys — the tool doesn't care about selection state; it cares about which side of the current frame a key lives on. C describes a mirror-like behavior where the opposite side moves left, which isn't how Time Extend works at all — it only extends (pushes) keys on the active side. A useful mental model: think of Time Extend as a one-sided stretch. The current frame acts as an anchor, and you're pulling one side of the timeline outward. Always ask yourself — which side of the current frame is the mouse on? Only those keys move.

Question 9

A character reaches a pose at frame $20$ , has an identical hold key at frame $50$ , and begins the next change at frame $70$ . The hold must be shortened by $20$ frames, while the spacing from the hold key through all later keys must remain unchanged.

Which Dope Sheet edit best satisfies the requirement?

Select the keys at frame $50$ and later, then move them left by $20$ frames, preserving all relative spacing. (correct answer)
Delete the hold key at frame $50$ , leaving the later keys at frames $70$ and beyond unchanged.
Select only the hold key at frame $50$ , then move it left by $20$ frames to frame $30$ .
Select every key in the action and scale the complete sequence by a factor of $0.5$ around frame $0$ .

Explanation: When editing timing in Blender's Dope Sheet, always clarify what must move versus what must stay fixed. Here, the hold between frames

20

and

50

needs to shrink by

20

frames, but every key after the hold must keep its relative spacing intact — only their absolute position should shift left. That logic points directly to answer A. By selecting the key at frame

50

and every key beyond it, then sliding the entire group left by

20

frames, the hold key lands at frame

30

(giving you a

10

-frame hold instead of

30

), and the key at frame

70

moves to

50

— all while the gaps between subsequent keys remain perfectly preserved. The "spacing from the hold key through all later keys" is unchanged because the keys move as a rigid block. Answer B fails because deleting the frame

50

hold key leaves the next change still starting at frame

70

, which shortens the hold but doesn't reposition the later action — the downstream timing is now misaligned rather than preserved. Answer C moves only the hold key to frame

30

, which does shorten the hold, but leaves frame

70

and all later keys untouched, meaning the gap between the hold key and the next key grows from

20

frames to

40

— the opposite of preserving spacing. Answer D scales the entire action by

0.5

, which compresses every interval globally and shifts all keys, completely changing the timing of the pose at frame

20

and everything else. A reliable strategy: before touching keys in the Dope Sheet, mentally label which keys are anchors (stay put) and which are movers, then select only the movers as a group.

Question 10

Several visible, editable animation channels have keyframes at frame $24$ , and those keys must all move to frame $30$ . Other keyframes before and after frame $24$ must remain unchanged. The playhead is already at frame $24$ .

Which workflow most reliably performs the edit?

Choose Select > Before Current Frame, then press G and enter $6$ .
Select one channel row, then press G and enter $6$ for that channel only.
Choose Select > Column > Current Frame, then press G and enter $6$ . (correct answer)
Move the playhead to frame $30$ , leaving the keyframe column at frame $24$ .

Explanation: When working in Blender's Dopesheet or Graph Editor, selecting the right keyframes before transforming them is everything. The key question here is: which selection method grabs all keys at exactly frame $24$ — and nothing else? Select > Column > Current Frame does precisely this. It selects every keyframe sitting on the current frame across all visible, editable channels simultaneously. Once selected, pressing G and entering

6

slides that entire column forward by six frames, landing it cleanly at frame

30

. Keyframes before and after frame

24

are untouched. This is option C, the reliable, purpose-built solution. Option A fails because Select > Before Current Frame selects all keyframes prior to the playhead — the opposite of what you need. You'd be moving keys you want to leave alone while missing the ones at frame $$24$. Option B is tedious and error-prone. Selecting and moving one channel at a time risks missing a channel, and repeated manual transformations can introduce inconsistency across channels. Option D doesn't actually accomplish anything useful. Moving the playhead to frame

30

changes your time position, but the keyframes at frame

24

stay exactly where they are — nothing gets moved unless you select and transform the keys themselves. Study tip: Blender's Select > Column submenu is your precision tool whenever you need to grab a full vertical "slice" of keyframes at a specific frame. Memorize it as the go-to for column-based keyframe edits — it appears on exams exactly like this.