Reply to thread

Message: [QUOTE="Bombastus, post: 91926, member: 2178"] Marty’s current RTGI requires a working ReShade depth buffer and DirectX 10 or newer before it can calculate lighting or occlusion. The important requirement is usable scene data, not a game with native ray tracing switched on. RTGI runs after the game has rendered the frame. ReShade can inspect the finished image and the depth information exposed by the game. It then reconstructs enough visible geometry to estimate where surfaces sit and trace lighting through a screen-derived representation. A [B][URL='https://jcgt.org/published/0003/04/04/']screen-space ray-tracing method built around depth buffers[/URL][/B] describes the same broad technique, with rays tested against depth information already available on the GPU. Native DXR ray tracing works differently. A game can build acceleration structures from its geometry and trace rays through scene information the current camera does not directly show. [HEADING=2]RTGI traces what ReShade can already see[/HEADING] A depth buffer records distance from the camera for visible pixels. ReShade’s Generic Depth add-on exposes it to effects such as global illumination, ambient occlusion, and depth of field. It chooses buffer candidates using draw calls, aspect ratio, and buffer type, so a bad automatic pick can look like an RTGI defect. The useful compatibility check is whether ReShade can obtain clean depth and whether your GPU can run the shader at an acceptable frame rate. Native ray-tracing support inside the game is not required. An RTX badge cannot repair a depth buffer RTGI never received. Screen-space access also explains why RTGI can be added to older titles. The shader does not need the original developer to place ray-traced lights, author a BVH, or expose a DXR pipeline. You can apply [B][URL='https://goldmidi.com/community/threads/marty-mcfly-revamped-the-rtgi-shader-with-next-gen-sampling-and-fog.32346/']the RTGI sampling and reflection overhaul[/URL][/B] to older engines when ReShade can read the buffers it needs. [HEADING=2]The depth buffer creates hard visual limits[/HEADING] RTGI cannot directly observe every surface in the game world. Current documentation says the shader only sees surfaces facing the camera, so it must estimate how far an object continues behind the visible face. Object Thickness exists because a chair, wall, character, or column is not fully described by one front-facing depth sample. Push the estimate too low and light can leak through geometry or occlusion can weaken. Push it too high, and the shader can overstate thickness, producing halos or excessive blocking. More GPU power does not recover missing geometry because the limitation comes from the information supplied to ReShade. Off-screen information causes a similar problem. A native ray tracer can follow a ray into geometry outside the camera view when the engine includes it in an acceleration structure. Screen-space RTGI only has the rendered buffers, so reflections or bounced light can lose information near screen edges or behind foreground objects. Upscaling creates another failure mode that can look like a performance or shader problem. DLSS, FSR, XeSS, TAAU, and dynamic resolution can leave depth jittered, checkerboarded, or misaligned. Current RTGI provides a TAAU scaling definition for alignment, while ReShade’s depth tools let you inspect and correct the underlying buffer. [HEADING=2]RTX hardware solves a different problem[/HEADING] Dedicated RT cores accelerate workloads designed around a hardware ray-tracing pipeline. RTGI instead runs as a ReShade effect against screen-derived data. Its setup centers on depth access, shader order, Launchpad, and a supported graphics API rather than an RTX-class feature set. Ray tracing is an algorithmic technique, not an RTX-only feature. Programmable GPU shaders can perform ray intersection work without a dedicated RT block, which is why screen-space ray tracing predates consumer RTX cards. Non-RTX hardware isn't excluded just because it lacks RT cores, though practical speed still depends on the GPU doing the rest of the shader work. Launchpad matters because current RTGI depends on better normals and motion information for temporal work. Its optical-flow system estimates per-pixel motion between frames so dependent shaders can reproject, accumulate, denoise, and filter their results. Better motion data improves stability, but it still does not give ReShade complete access to the game’s scene geometry. A faster GPU can absolutely improve the experience. Higher RTGI quality means more ray work, filtering, and supporting processing, while higher resolutions increase the number of pixels involved. An RTX card may therefore run RTGI faster through shader throughput, but dedicated RT hardware isn't what makes the technique work. Compatibility still has practical limits. RTGI currently requires DirectX 10 or newer, and the documentation points DirectX 9 users toward translation layers such as DXVK or DGVoodoo2. With the API, depth buffer, and ReShade setup working correctly, performance comes down to workload and available GPU speed rather than an RTX badge. [/QUOTE]

Name