Joy Engine owns HDR scene attachments, multiscale bloom, and display processing. rendering::PostProcessSettings is the complete set of values the renderer applies (DEFAULT for the engine look, NEUTRAL for linear color straight to the display), and rendering::post_process::POST_PROCESS_CONTROLS is the one table of keys, ranges, defaults, and descriptions that validation, authoring schemas, and the development editor share. Levels author the look as entity components, so the appearance travels with content.
The display chain applies exposure, bloom, the display transform, vignette, and the output encoding in one resolve pass after the bloom pyramid. Exposure is the authored value times a one-texel exposure texture that adaptive exposure writes (and that holds one otherwise). Bloom thresholds exposed light with a soft knee and suppresses fireflies with a Karis average, downsamples with a 13-tap filter (Jimenez 2014), and upsamples with a tent filter; bloomRadius sets its reach (and so the pyramid's depth), bloomScatter how much each wider level blends into the next, and bloomQuality the filters. Display transforms are filmic (the default: a parametric toe, linear section, and shoulder after Uchimura), AgX with its default or punchy look, or none. HDR presentation maps into the display's headroom, and 8-bit outputs are dithered. Intermediate HDR uses Rgba16Float where rendering, filtering, and blending permit it, with a capability-dependent fallback.
Colors enter the scene in linear space. Radius and viewport conventions belong to each control's documented contract; frame time is seconds. Validate a complete update before replacing accepted settings. Resources and temporal history belong to the renderer, and resizing rebuilds dependent targets.
A postProcess component on any level entity is a post-process volume: its setting keys (validated PostProcessOverrides) apply on top of the engine defaults, and its volume fields say where. An unbounded volume applies everywhere and sets a level's overall look; otherwise the volume covers its box (halfExtents) or sphere (radius) shape in the entity's space, scaled by the entity's scale (the largest axis for spheres), and fades in over blendDistance meters inside the surface. priority orders application (higher applies later; ties keep authored order), and weight scales the strength at full coverage. Numbers blend linearly except exposure, which blends in stops; choices switch at half strength. Records are read strictly, so a misspelled key or out-of-range value fails instead of silently doing nothing.
rendering::PostProcessVolumes reads a level's volumes (from_level, or sync for runtime entity state) and resolves the settings at a world-space view point, usually the camera eye; games pass the result to Renderer::set_post_process each frame, and an unchanged resolution is reused. Resolution is presentation only and never touches simulation or gameplay randomness. The shape lives on the component rather than borrowing a physics collider, so a volume never creates a body or changes collision. Levels from before volumes fail to parse with a message pointing to the postProcess component; move a top-level postProcessing profile's overrides into an unbounded volume.
development::PostProcessEditor edits one volume (by default the level's global, unbounded volume) with draft editing, comparison against the saved settings, bypass, reset, and history. While it exists, games resolve through PostProcessEditor::resolve, which previews the draft in place of the edited volume's settings. Native development builds given the level path save into that entity's postProcess component (leaving its volume fields and the rest of the document untouched) and reload outside edits; static browser builds export instead. Joy Editor's level viewport resolves the edited level's volumes at the editor camera. See live tuning and public rustdoc for save behavior and units.
Scene effects (temporal antialiasing, motion blur, adaptive exposure, and volumetric fog) operate before display processing and have their own motion and capability requirements. See scene effects. Frame cadence and CPU submission diagnostics are not GPU execution measurements.