ModelInstance::step ramps the weights of animations fading in and out in tenths
over 10 ticks; between ticks, the posing hook sets them partway to the next
tick's weight, and puts them back with the times. Only if ModelInstance::step
counts the fades where expected (checked when installing); otherwise
crossfades stay at the client's rate.
Co-Authored-By: Claude Opus 5.5 <[email protected]>
The particle library moves particles by their velocity times a tick's time at
each tick; between ticks, the adapter (ModelInstance::render's call to
ParticleSystem::render, redirected after checking it) draws them moved on by
their velocity times the time since, then moves each back by its own velocity:
ParticleSystem::render sorts them by distance, reordering them in memory, so
restoring saved positions in order scrambled them. Like ParticleSystem::render,
it only reads particles when there's a group (the library throws without one,
which crashed the client).
Co-Authored-By: Claude Opus 5.5 <[email protected]>
The point the camera looks at is its position plus an offset (setCameraFocus,
at each tick), so between ticks it now moves with the eased position: panning
moves the target the position eases to, and was still at 30 per second.
Between ticks, an animation is moved on at the rate it moved at the last step
(per tick: the client steps several ticks at once when it falls behind), not
only when it moved exactly a frame: animations played at other speeds were
posed at the tick, between smooth ones.
The engine's stats also log the longest time between frames.
Co-Authored-By: Claude Opus 5.5 <[email protected]>
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]>
ModelInstance::render poses its model (updateCalSkeleton) before drawing it;
the adapter redirects that one call (after checking it) to ours, which between
ticks moves each playing animation that went on a frame at the last tick ahead
by the fraction of a frame since, has IMVU's code pose the skeleton (Cal3D
poses between keyframes), and puts the animations back, marking the skeleton
to be posed again. Held, looping and starting animations are posed as they
are. The frame lengths come from zero.dll's millisecondsPerFrame and
secondsPerFrame.
Co-Authored-By: Claude Opus 5.5 <[email protected]>
The renderer process now takes each view's chunks on a thread of its own as
they come, and draws the newest frame on its main thread: the client no longer
waits for the previous frame to be drawn (on a VM, 22 of a frame's 25 ms).
The adapter records the client's steps (SceneViewer::step, by replacing its
entry in the exported IFrameListener vtable, after checking it), and the frame
pacer doesn't ask for a frame that wouldn't end before the next step is due: a
late step made the client catch up two at once, which showed as hitches. While
the renderer process covers the view, the client's renderer doesn't begin or
present frames, which could wait for the display.
The engine's stats now include the time in the client renderer's methods.
Co-Authored-By: Claude Opus 5.5 <[email protected]>
dhkatzandClaude Opus 5.5