benilla-octo/docs/GRAPHICS.md

Graphics: where the budget is, and where the picture is

This fork's renderer is its own (LIGHTING.md, WATER.md describe the lanes). This file is the plan: what the frame actually costs, what is already shipped and unspent, what is missing, and what each missing thing would cost on this engine rather than on someone else's.

The budget, measured

This client is main-thread CPU bound and the GPU is about two thirds idle. Measured with WOW_FLASH_TRACE=1 WOW_GPU_MS=1, in play and offline:

	fps	wall	main	gpu
live, Dun Morogh, out of combat	112	8.9	7.6	3.0
live, in combat	65–91	11.1–15.4	10.3–14.5	2.6–3.9
offline Elwynn vista, vsync-capped	60	16.6	4.2–8.4	0.8

gpu is flat at every framerate; main moves 1:1 with the drop. So the rule for anything in this file:

A change that spends GPU is nearly free. A change that adds main-thread work is not.

That single fact decides most of the ordering below, and it is why upscaling is near the bottom rather than the top.

The harness

Every claim here is checked the same way, offline, with no server and no account — about 60 s a run:

env WOW_DATA=/path/to/Data WOW_MAP=0 WOW_CAPTURE=vista \
    WOW_VISTA_AT=-9460,70,58 WOW_VISTA_FACE=180 WOW_VISTA_PITCH=-8 WOW_VISTA_MIN=720 \
    WOW_GPU_MS=1 WOW_FLASH_TRACE=1 WOW_CAPTURE_OUT=/tmp/shot.png \
    cargo run -q --release -p benilla

Render it twice, change one knob, and diff the PNGs (PIL.ImageChops.difference): mean and max absolute difference, and the count of pixels that moved by more than 2. WOW_CVAR=a=1;b=2 sets any registered row for the session; WOW_ANISO, WOW_FARCLIP, WOW_RENDER_SCALE, WOW_MSAA are direct levers. Validated eye positions live in benilla-app/src/capture/scenarios.rs.

Always run a starved control. A knob that forces the bad path, or an identical pair of renders, proves the harness is actually reaching the thing being measured. Five such pairs once matched byte for byte before anyone checked whether the view read the table at all.

Already shipped and worth spending

These need no code. They are the cheapest picture available today.

Knob	Shipped	Worth	Measured cost	Measured change
anisotropic	1 (off) at Classic/Low, 16 from High	16	+1.0 ms GPU, 0 main	34.1% of the frame, peaking at 66.5% across the band where the ground recedes
renderScale	1.0 (Render Scale slider in Options)	1.25–1.5	+1.5 ms GPU, 0 main	19.4% of the frame
farclip	777 at High, 1497 at Ultra	taste	streaming and draws, i.e. main thread — measure before raising	—

The anisotropic row is the one to take first: the reference ships it off, so ground texture at a grazing angle smears to mush a few yards out, which is most of an outdoor screen. It is a sampler state, so it is free on the CPU and costs a milligram of the GPU time we are not using. The sampler is baked into each texture at load, so a change lands on the next launch — the reference's own options window says the same ("enabled upon restart").

A player already on a Custom Graphics Preset is not seeded by the ladder and keeps their saved value; /console anisotropic 16 and a restart is the whole fix for them.

What the picture is missing

Ordered by (visual gain) ÷ (main-thread cost), not by how interesting they are.

1. Terrain horizon occlusion — buys main thread

The reference culls terrain against its own horizon (0x686000, 0x686180, 0x681b50), outdoors and per portal window inside a WMO, and parks hidden rigs and drops shadow casters below it. We have the portal/doorway half (exterior_cull.rs) and not this one. It is the rare item that makes the frame cheaper on the thread that is actually full, and cheaper frames are what let the view distance and the lanes below be afforded at all. Terrain chunk LOD (0x6c51b0, levels 2 and 3 stitched across cell and tile edges) is the same kind of win.

2. Auto-exposure

A screen-metered exposure, so interiors, night and a torchlit room read at their own level instead of at the sun's. One GPU pass over a downsampled frame plus a smoothed histogram; our HDR path and ffx_glow's combine already carry an exposure slot. Small, GPU-side, and it changes every dark scene in the game.

3. Planar water reflection

Our water has refraction, foam and a scene-depth copy (liquid/, water_fx/) but no mirror. The reference-era trick is a second scene render with an oblique near clip, armed only for visible water and thinned of small objects, under a screen-space trace. It is the single most recognisable item on the "original art, modern presentation" axis, and it is pure GPU — which is what we have.

4. Froxel volumetrics

We have near-field volumetric fog and light shafts as screen passes. The modern form solves the DBC fog into a participating medium in a 3D froxel volume with reprojected history, so fog lights correctly, moves with the camera without swimming, and costs a fixed compute dispatch instead of scaling with overdraw.

5. Screen-space indirect light (SSILVB)

An upgrade from classic SSAO to a visibility-bitmask trace that carries indirect colour, not only occlusion. GPU-side, and it is most of what makes a modern frame look lit rather than painted.

6. Runtime probe GI

A toroidal voxel clipmap of the static world plus cascaded probe grids traced in compute, order-1 SH with hysteresis. The biggest lighting change available and the most work; it belongs after the five above, not before.

7. Upscaling (FSR) — not now

Worth stating plainly, because it is the obvious thing to ask for. FSR renders fewer pixels and reconstructs the rest. We are not short of pixels — we are short of main thread, and the GPU is two thirds idle. Upscaling would hand back time we are not spending and charge main-thread work for it: a motion-vector prepass over terrain, static geometry and every skinned rig, plus the upscaler's own dispatch.

The plumbing, for when it is the right lever:

• Bevy 0.18 already carries MainPassResolutionOverride (honoured by every main 3D pass) and TemporalJitter, and ships a complete DLSS integration (bevy_anti_alias::dlss) built as a ViewNode — the same render-graph shape this tree uses, so it is a working template rather than a port.
• renderScale already decouples world resolution from the window (world_backdrop.rs), with its own Options slider. The resolution half of the problem is solved.
• The real work is motion vectors for our skinning: wow_model.wgsl runs its own wow_skin_model off our rig palette at vertex locations 10/11, not Bevy's SkinnedMesh path, so Bevy's prepass would draw every animated model unposed. A prepass variant needs the palette double-buffered to last frame's pose.
• RCAS sharpening is the separable piece: a single cheap post pass that improves perceived detail at any render scale, including above 1.0. It needs none of the above.
• Frame generation is not reachable here: it needs a winit AfterUpdate hook that Bevy does not expose, which is why the fork that has it vendors bevy_winit.

8. Field of view

The reference's lens is ~44.1° vertical at 16:9 and ours is 45°, so ~73° horizontal. A 90° Hor+ lens is a large perceptual change and nearly free to draw. It is deliberately not on this list as a default change: it alters how the game feels to play, and the existing FoV row is SuperWoW's camera ratio (crate::player::scoped_view::CameraFov), which is a different quantity. If it is wanted it should be its own registered row with the reference's value as the default.

What is not in scope

benilla-bourbon implements most of §2–§7 already, on Bevy 0.19.1 with a vendored wgpu 29 and a render graph expressed as systems. This tree is Bevy 0.18.1 with 14 files implementing render-graph Nodes. Those are incompatible architectures, and that fork is published as one squash commit with no history to pick from — docs/BOURBON_SYNC.md has the measurement. So everything above is costed as work on this engine, informed by what that fork proved is possible, not as a port.