Move the camera between ticks

CameraController::step eases the camera's position, orbit angles and zoom a
share k (0.4) of the way to their targets at each tick; between ticks, the
adapter's getCameraTransform (its entry in CameraController's exported vtable,
replaced after checking it) sets them 1 - (1 - k)^fraction of the way for IMVU's
code to make the transform from, then puts them back. k is read from the
constant CameraController::step uses, checked to be referenced there.

Co-Authored-By: Claude Opus 5.5 <[email protected]>

docs/architecture.md

@@ -90,8 +90,14 @@ While the renderer process covers the view, the client's renderer doesn't begin
 wait for the display). The renderer process takes each view's chunks on a thread of its own as they come, so the
 client never waits for drawing; it draws the newest frame. On a PC with a graphics card a room frame takes the client
 about 2.5 ms (the client's own work: posing avatars, which it does every frame, and walking the scene), and the
-renderer process about 0.5 ms. The extra frames show the same scene until animations, the camera and particles are
-drawn at the time between steps.
+renderer process about 0.5 ms.
+
+Between steps, the frames show the scene at the time between them (`adapter/scene_hooks.cpp`): avatars posed with
+their animations a fraction of a frame on (ModelInstance::render's call to updateCalSkeleton, redirected; Cal3D poses
+between keyframes; animations held, looping or starting are posed as they are), and the camera where its easing (a
+share 0.4 of the way to its target per step) has brought it, `1 - 0.6^fraction` of the way (CameraController's
+getCameraTransform, in its exported vtable). Nothing is predicted: both are what the next step would give, at the
+fraction. Still at 30 per second: particles, crossfades between animations, gaze.
 
 Next: sharing pipelines between views (each view's scene compiles its own).