So, as it turns out, you actually can have too much of a good thing. When we started our journey at Embark, we had a disproportionately high number of rendering engineers on our platform project. We quickly realized it would be a trap to lose ourselves in shiny pixels at the outset, particularly as we had more important things to take care of before rendering.
Luckily, we are also generalists, and huge fans of the Rust language (which turns a regular developer into a superhero). And so, we put off graphics for a while, and instead focused on gameplay, physics, audio, and all of the other bits and pieces that a new game engine needs. We rolled with vertex colors and blob shadows for almost two years, relying on the insensitivity (and affinity) of engineers to visual transgressions.
Eventually, our true ‘rendering’ selves emerged, and could not hold off any longer. After all, when artists start faking indirect lighting, fog and Fresnel equations with vertex colors, it’s a desperate cry for help.
It became clear to us that we needed some rendering tech.
Rust has an incredible open source community, so you never need to start completely from scratch. While we found plenty of great building blocks, we did not unearth any ready-made solutions that would fit all of our needs. It was time to pull up our sleeves and get to work.
The rendering engineers rejoiced!
… perhaps a bit too much. We made not one, but two renderers. Sort of — they are closely related, share a lot of code, and both have exciting modern features, such as ray tracing and real-time global illumination.
We also wanted to bring the benefits of the Rust language and ecosystem to the GPU; hence, the rust-gpu project was born. Our rendering engineers would no longer have to choose between using a great language and writing shaders!