# 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](https://github.com/DiligentGraphics/DiligentCore) (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. Checked in the client (Direct3D 11 in
software, on a machine without a graphics driver): the box draws over the scene from the 64-bit process, keeps in
step with the client's frames, clicks on it reach the scene, and each renderer process exits with its engine (room
changes) and with the client. The client keeps two engines alive in a room, so two processes (about 15 MB each);
one process serving all of a client's engines would be leaner.

Next: the protocol carrying each frame's calls and the resources (buffers, textures), and the renderer process
drawing the scene itself, with IMVU's Direct3D engine left as the fallback.

## 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.