The user grabs the controls mid-flight
Console only. No pointer is simulated: the code sends the start event OrbitControls sends for a press, then calls rotateLeft(0.8) as the drag. Each story runs 90 ticks of 1/60 s.
To move the camera between views, turn progress into a position: lerp the target, slerp the camera's direction and lerp its distance, shaped by an easing curve and measured in seconds. Stop when the user grabs the controls, and jump instead of flying when reduced motion is on.
Change the code and press Run (Ctrl+Enter). Predict what will happen first, then break it on purpose and read what changes. Your edits are saved and match the lesson page.
Ready for more? This phase has 3 hands-on exercises with automatic checks.
Practice questions
Write the code in the editor, run it, then open the model answer to compare.
Write easeOut(t) that starts fast and ends slowly, using 1 - (1 - t) ** 3, and print it at 0.25, 0.5 and 0.75.
Write goTo(view) that respects reduced motion: it should return 0 and move at once if the visitor asked for it, otherwise start a 1 s flight and return 1.
Explain it without notes
Why is lerping the camera's position between two views a bad path, and what is the better one?
What should happen to a camera flight when the visitor presses the mouse button on the canvas, and why?
Console
Nothing logged yet.Expected console output
flight ignores the user: camera ends at -0.20, 0.70, 0.75 (the drag is lost)
flight stops on 'start': camera ends at -1.48, 0.67, 1.63 (where the user left it)
the detail view is at -0.2, 0.7, 0.75