t5de-renderer/docs/architecture.md

Architecture

The renderer is two programs:

• The adapter, t5deRenderEngine.dll (32-bit, adapter/): a renderer plugin IMVU Classic loads in place of its OpenGL renderer (selected by the t5de-renderer patch in the t5de repository). It implements IMVU's PiRenderEngine interface (include/t5de/imvu/, docs/interface.md) and passes what the client draws to the renderer process. It stays thin: IMVU's process is 32-bit (4 GB of address space shared with Python, Gecko and IMVU's own code) and tied to Visual C++ 2010's ABI.
• The renderer process, t5de-renderer.exe (64-bit, renderer/): draws, with Diligent Engine (Apache-2.0). Being 64-bit and separate, it can use any modern API and library, isn't limited by the client's address space, and can crash without taking the client down.

Why Diligent: one API over Direct3D 11 (every Windows PC, and software rendering on machines without a graphics driver), Direct3D 12 and Vulkan (ray tracing, mesh shaders), and WebGPU (browsers, for a possible future client). It's built with CMake and fetched by FetchContent, pinned to a commit (renderer/CMakeLists.txt); only the Direct3D 11 backend is built for now.

How they talk

include/t5de/protocol/ is shared by both builds, so it uses fixed-size fields only. For each engine the client creates (each 3D view, and again on room changes), the adapter:

1. creates a shared memory channel (Local\t5de-renderer-<pid>-<n>) holding IMVU's window handle and a frame count, and an event set after each frame;
2. starts t5de-renderer.exe --channel <name> --parent <pid> from its own folder;
3. sets the event at each endRendering, and sets closing when the engine is destroyed.

The renderer process draws into a child window it creates inside the client's window: window handles are valid in every process, and Windows allows child windows across processes (Chrome's GPU process works this way). The child is disabled so mouse input goes to the client's window under it, and the adapter gives the client's window WS_CLIPCHILDREN so the client's own drawing stays out of it. The process exits when the engine is destroyed or the client exits.

Status

A spike: the adapter still has IMVU's Direct3D 9 engine draw the scene (the pass-through), and the renderer process only draws a box in the 3D view's corner, pulsing with the client's frames. It proves the risky parts: drawing into the client's window from another process, keeping in step with the client's frames, and mouse input still reaching the client. Next: the protocol carrying the frame's calls and resources, and the renderer process drawing the scene.

Building

Two presets, one per architecture: cmake --workflow --preset adapter (32-bit, with the tests) and cmake --workflow --preset renderer (64-bit; the first configure fetches and builds Diligent). Both programs go in the client's folder.