Thomas ten Cate's latest devlog for Around The World is, on its surface, about making clouds look right. Underneath, it's a case study in how a single developer with physics intuition and a willingness to write throwaway tools can outperform off-the-shelf solutions through sheer bloody-mindedness. The post covers five distinct rendering problems — cloud light scattering, indirect sky lighting, atmospheric horizon color, planet-scale curvature mismatches, and HDR tone mapping — and solves each with a different flavor of pragmatic hack. The standout move is writing a custom Monte Carlo ray tracer in Rust just to confirm that Povray doesn't simulate multiple scattering. Most developers would have accepted the lookup table and moved on. Ten Cate built a specialized tool, validated his suspicion, generated a better LUT, and threw the tool away. The resulting clouds lose their "metallic" look and gain the diffuse brightness that real multiple scattering produces. It's the kind of investment that only makes sense if you care about understanding why something looks wrong, not just patching that it looks wrong. The normal-flipping trick for indirect sky light is the post's cleverest moment. Cloud bottoms point downward, so Godot samples dark ground-facing irradiance for them. By flipping normals upward, the shader samples sky-colored light instead, approximating the scattering that would happen through the cloud volume. The result: blue-tinted cloud bases during the day and pink clouds at sunset — the red of direct sunlight mixing with blue indirect sky light. It's physically wrong in letter but right in spirit, and the screenshots prove it. The atmospheric scattering fix — reversing inscattering and outscattering order in the ray march — is the most intellectually honest moment. Ten Cate admits this shouldn't matter with enough integration steps, suspects there's still a bug, and ships it anyway because the result looks correct. This is real engineering: knowing when a solution works well enough to move on, even if you can't fully explain why. The horizon-bending hack addresses a problem unique to Around The World's 75×-smaller planet: Earth-realistic atmospheric parameters produce a sky horizon above the geometric horizon, creating a visible dark band. The fix — offsetting the view vector's vertical component — is trivially simple and exactly the kind of trick that only becomes obvious once you understand the root cause. Same with the tone mapping section, where Filmic with a white point of 2.0 (well below Godot's recommended 6.0) produces the soft, distant-cloud look the game needs. The orrery is a quiet flex. Rather than deriving the math for sun and moon positions at arbitrary latitudes and seasons, ten Cate models the actual orbital mechanics in-engine and lets the renderer compute inverse transformations. It's a brute-force solution that's easier to debug, harder to get subtly wrong, and produces a beautiful visualization as a side effect. What makes this devlog worth reading isn't any single technique — it's the demonstration of a problem-solving style. Every section follows the same pattern: notice something wrong, hypothesize a cause, build the minimum tool to test the hypothesis, implement the cheapest fix that's physically plausible, and move on. The post is a 15-minute education in real-time rendering pragmatism from someone who clearly knows the physics but refuses to let perfection block progress.
