5 Commits

Include renames

Author	SHA1	Message	Date
dhkatzandClaude Opus 5.5	db344b7b95	Crossfade animations between ticks ... 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]>	2026-10-28 22:41:23 -07:00
dhkatzandClaude Opus 5.5	9d0faecf4d	Move particles between ticks ... 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]>	2026-10-28 22:21:58 -07:00
dhkatzandClaude Opus 5.5	d1437a3923	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]>	2026-10-28 21:44:56 -07:00
dhkatzandClaude Opus 5.5	2471b1fd4f	Pose avatars between ticks ... 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 ... 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