Whipping Together A Little Ray Tracer Racer

The ray tracer racer

When you hear raytracing, you might think of complex dark algorithms that to stare too long at their source code invites the beginning of madness. And you’re technically not far off from the truth, but [h3r2tic] put a small open-source ray tracing game demo up on GitHub. The actual rust code powering the game is relatively short (just four files), with the longest file being the physics file. But, of course, there is a small mountain of code under this sample in the form of libraries.

Kajiya, physx-rs, and dolly are the three libraries that make this little demo possible. Kajiya, in particular, is what makes raytracing possible as it uses the newer RTX features (so only more recent Nvidia and AMD cards are supported) and Vulkan bindings. But, of course, it isn’t wholly ray-traced as we are still several years out from proper real-time raytracing. Nevertheless, the blend between raytracing and traditional rasterization looks incredible. The most important thing about this simple tiny sample isn’t the game itself but what it stands for. It shows how easy it is to create a sample like this. Even just five years, creating a demo like this required massive effort and expertise.

Visually, it is stunning to look at. While the reflections are most apparent, the takeaway from this is the ease that real-time global illumination brings. A quick look through the code shows that there are very few lights in the scene, despite looking well lit with soft shadows. Traditional video games spend a significant amount of development time lighting a scene, placing additional lights, and tweaking them to make up for all the shortcuts that lighting has to take in a rasterized environment. As more and more games are built with raytracing in mind rather than tacked on at the end, we can ditch the small crumbling mountain of hacks that we are forced to use in games today and just rely on the rays to accurately light a scene.

If using a library for your raytracing seems too easy, perhaps you’d like to take on the challenge of raytracing in excel. Video after the break.

11 thoughts on “Whipping Together A Little Ray Tracer Racer

  1. Hmm … but if the raytracing is outsourced to code on the GPUs, then this game (and thus the article) ain’t ‘xactly ’bout raytracing but ’bout glueing together a bunch’a libraries.
    Me thinks the introduction “raytracing is mind boggling” (paraphrased) therefore is kind of misplaced. After all, raytracing as such is pretty simple (start with a scanline approach and add a simplified Monte Carlo on top and you’re basically there – or look at various intros to path tracing etc.)

    I mean … there ARE “simple” raytracing code projects out there (going back to good ole’ Collins and Buck’s DKB) … this is, as the headline reads, actually more about “whipping together”.

  2. It’s impressive, but I’m not entirely sure how much value ray tracing adds to a fast racing game. Not to knock an impressive bit of work – this would be fantastic for CGI etc – but in terms of what it adds to a game, I’m unsure on the ROI.
    Give me more realistic trees which don’t turn into a mess when you’re up close.

    1. If you’re playing a fast racing game, you shouldn’t be looking at the trees, much less be close to them (unless rallying, in which case you REALLY shouldn’t be looking at them)!

      1. Actually, as soon as the UE5 demo was out, people did tests with old hardware. Nanite worked really well with an old pentium system and a bunch of extremely detailed meshes (held its 60 fps, which is pretty impressive considering the hardware and circumstances). If you’re looking for official sources, the fact that Nanite works well on a ps5 promises quite a good leeway for medium tier hardware.

Leave a Reply

Please be kind and respectful to help make the comments section excellent. (Comment Policy)

This site uses Akismet to reduce spam. Learn how your comment data is processed.