t5de-renderer

27 Commits 1 Branch 5 Tags

3 Commits

Include renames

Author	SHA1	Message	Date
dhkatzandClaude Opus 5.5	d1437a3923	Move the camera between ticks CI / build (push) Successful in 1m38s Details 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]>	2026-10-28 21:44:56 -07:00
dhkatzandClaude Opus 5.5	2471b1fd4f	Pose avatars between ticks CI / build (push) Successful in 27s Details 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]>	2026-10-28 21:38:07 -07:00
dhkatzandClaude Opus 5.5	065c7e9300	Never make the client wait for drawing, or hold up its steps CI / build (push) Successful in 1m15s Details 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]>	2026-10-28 21:30:46 -07:00

Author

SHA1

Message

Date

dhkatzandClaude Opus 5.5

d1437a3923

Move the camera between ticks

CI / build (push) Successful in 1m38s

Details

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]>

2026-10-28 21:44:56 -07:00

dhkatzandClaude Opus 5.5

2471b1fd4f

Pose avatars between ticks

CI / build (push) Successful in 27s

Details

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]>

2026-10-28 21:38:07 -07:00

dhkatzandClaude Opus 5.5

065c7e9300

Never make the client wait for drawing, or hold up its steps

CI / build (push) Successful in 1m15s

Details

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]>

2026-10-28 21:30:46 -07:00