Wrap IMVU's Direct3D renderer in the pass-through

IMVU's OpenGL renderer needs a real graphics driver; Direct3D also runs on Windows' basic display driver and is what most players use. The log can now be read while the client runs. Verified in rooms: every call goes through.

Co-Authored-By: Claude Opus 5.5 <[email protected]>
This commit is contained in:
dhkatzandClaude Opus 5.5 committed 2026-10-28 04:28:26 -07:00
1 parent dc643d271b
commit 3c28a8794b
6 files changed
+52 -35

No files matched your search

+19 -3
View File
@@ -79,9 +79,25 @@ virtual methods, IMVU's code only uses an engine through helpers that call its v
ticks; `runApp` waits out `zero.dll`'s `millisecondsPerFrame`). Shorter ticks speed animations up. Smooth high
frame rates need in-between poses: hooks in `SceneWindow.dll`'s animation update.
## What the client draws
From the pass-through (Direct3D, client 554.8, a few rooms):
- A room frame: about 146 `drawTriangles`, each with its own `setModelSpace` (131) and `setTextures` (138), with
per-object alpha test, culling, normal inverting and blending, 252 texture-transform resets, 8 light updates; no
`drawLine`, `drawPointSprites` or `drawTrianglesFromMemory` in those rooms.
- Every frame creates index and vertex buffers (4 and 12 in a room, with nothing new loading): most likely avatars,
skinned on the CPU and uploaded again each frame.
- Each 3D window, and each room change, creates a new engine (`createRenderEngine`), so engines start and stop
often; frame buffers are resized freely (up to 3440x1272 here).
- IMVU's OpenGL engine needs a real graphics driver (`ARB_multitexture`); on Windows' basic display driver
(virtual machines) it throws and the client falls back. Its exceptions are `std::exception`s our code can
catch.
## Plan
1. Pass-through plugin (this repository's first version): wraps IMVU's OpenGL engine and logs what each frame
calls, proving our declarations.
1. Pass-through plugin (done, verified in rooms): wraps IMVU's Direct3D engine, made with `SceneWindow.dll`'s
exported `createRenderer`, and logs what each frame calls, proving our declarations.
2. Work out the layouts above.
3. A renderer reproducing the current look on Direct3D 11 or OpenGL 4, then the improvements.
3. A renderer reproducing the current look on Direct3D 11 (it also runs in software, on WARP, where OpenGL can't),
then the improvements.