Reply to thread

Message: [QUOTE="Bombastus, post: 91929, member: 2178"] Launchpad must sit at the top of the ReShade shader load order for current RTGI Diffuse and Specular to function properly. Put it lower, and RTGI can lose the supporting data it expects before its own pass begins. Launchpad is not another lighting effect competing for attention. It prepares motion vectors, depth-related data, and improved surface normals that RTGI can reuse for temporal reprojection, accumulation, filtering, and denoising. Much of what looks like an RTGI stability problem can therefore begin one stage earlier. The [B][URL='https://goldmidi.com/community/threads/marty-mcfly-revamped-the-rtgi-shader-with-next-gen-sampling-and-fog.32346/']RTGI shader rebuild and fog update[/URL][/B] introduced newer Launchpad optimization work, but the current setup has moved further. Launchpad now serves as a data provider for several iMMERSE effects rather than something you tune only because RTGI refuses to start. [HEADING=2]Launchpad feeds RTGI cleaner scene data[/HEADING] ReShade can access normals supplied through the graphics pipeline, but those raw normals can look blocky or overly tied to visible polygons. Launchpad processes them into smoothed normals, then can layer higher-frequency texture detail back onto the result. RTGI gets a surface description that reacts more naturally to bounced light and reflections. Textured normals need restraint. Launchpad lets you control the sampling radius, intensity, and quality because a setting that suits rough stone can soften another game's fine material detail into mush. Lower radii preserve sharper detail, while larger values can calm noise at the cost of fine relief. Motion data solves a different problem. RTGI combines information across frames, so it needs some idea of where individual pixels moved between one frame and the next. The core constraint in [B][URL='https://doi.org/10.1016/0004-3702%2881%2990024-2']dense optical flow estimation[/URL][/B] is that motion cannot be recovered from a single image point without extra assumptions about neighboring information. Launchpad estimates per-pixel movement from depth, normals, and color. RTGI can then reproject useful history instead of treating every frame as completely unrelated. Cleaner history makes accumulated lighting steadier, while wrong motion vectors can drag stale lighting into places where it no longer belongs. Flicker around moving characters, thin fences, foliage, or rapidly changing edges can point toward motion estimation rather than the lighting intensity itself. Launchpad currently offers Newton and Sophia optimizers because the fastest solution is not always the most reliable across different kinds of movement. Newton favors speed and works best when motion is smooth and predictable. Fine or irregular geometry can trip it up. Sophia converges more slowly but is aimed at higher-quality motion estimates in difficult scenes, so switching optimizers can change temporal stability without touching RTGI's lighting controls. Flow quality adds another trade-off. Raising it gives Launchpad more room to produce precise motion vectors, with some performance cost. Dropping the setting can make sense on a tight GPU budget, but shaving milliseconds there may show up later as unstable accumulated lighting rather than an obvious Launchpad artifact. The July 2026 update changed the performance picture again. Launchpad's optical flow and normal processing were reworked for better speed, and the iMMERSE shaders gained an internal communication system that tells Launchpad which data they currently need. In a simple Launchpad and RTGI setup, disabling RTGI can now push Launchpad's own consumption close to zero instead of leaving every supporting pass running. [HEADING=2]Debug views expose broken inputs before tuning begins[/HEADING] Launchpad includes debug outputs for normals, optical flow, motion-vector direction, depth, and the original image. Use them before changing bounce intensity or reflection settings when RTGI looks unstable. A broken input should look broken in the diagnostic view, which narrows the problem before random slider changes make the preset harder to untangle. The optical-flow view is useful when moving objects leave trails or lighting seems to swim across edges. The normals view catches surfaces that look faceted, unnaturally smooth, or stripped of texture relief. The depth view can reveal a bad buffer before RTGI turns the same mistake into lighting artifacts. RTGI's own validation layer goes one step further by exposing the inputs it receives, including depth, normal vectors, optical flow, and lighting data. A black screen after enabling RTGI can also come from Launchpad being absent or placed below dependent shaders, while missing or outdated iMMERSE files can create separate failures that resemble a bad preset. Load order is therefore not housekeeping. Launchpad belongs first because later shaders consume what it produces, and current RTGI documentation treats that placement as a requirement rather than a recommendation. Once the inputs are visibly correct, RTGI tuning becomes about the scene instead of compensating for broken motion or surface data. [/QUOTE]

Name