Game dev in Rust, a year later – community

Well, here we are, a year after I wrote “Game dev in Rust, some notes on the mess.” Things haven’t changed much.

I’m still using the Rend3/WGPU/Vulkan graphics stack. It works reasonably well at this point.

Notes:

• Several major game projects abandoned Rust in 2024. Some found ownership too restrictive. Some complained about compile times.
• arewegameyet.rs stopped updating last July.
• Rend3 was abandoned. Now I have to maintain that myself, which I do as rend3-hp. I now have it up to current Wgpu, Winit, Egui, etc. versions, and finally found and fixed the race condition which kept causing crashes. I’ve been able to run for over 40 hours without a panic. Things are looking up. If you want to try it, use branch “wgpu23safe”. I’d appreciate someone trying that on MacOS, which I don’t use. Build it and run rend3-examples. If anybody is really interested, I could release it to crates.io in a month or two. Right now, it still has patches to library crates, which crates.io does not allow.
• The graphics stack is still too slow if you put in enough content to keep the GPU busy. Runs out of CPU time at around 25% GPU load with a NVidia 3070. Needs Vulkan bindless. Needs multiple Vulkan queues. Might get those from Wgpu in 2025. If you don’t need max performance, this stack should work OK.
• There was some promising work with the Orbit rendering demo, but that seems to have been abandoned. That was some advanced thinking about how to make the GPU do more of the job.
• Renderling has some promise, but it’s not ready for use yet and it’s only one developer. They do have some EU funding.
• If you do 3D work in Rust, expect to expend half of your time maintaining the lower levels. Budget accordingly.
• Crate churn remains a problem. Winit, Wgpu, Egui, and their friends have to advance in lockstep as the APIs change. When one of them changes, it’s about 1-2 months before the others catch up. Then you get to fix your own code to deal with the breaking changes.
• Whenever there’s been a serious problem that was hard to find, it was always because somebody built their own allocation system instead of using safe Rust constructs. Putting everything in an array and passing around array indices in multi-threaded programs is usually trouble.

At a more fundamental level, Rust rendering lacks the spatial component. Most of these renderers compute shadows by brute force – every light vs every object. This is O(N * M) and too slow as scenes get large.

This is a consequence of where you cut apart the problem. Whether you can do an efficient renderer without becoming a whole game engine that has a full scene graph, like Bevy, is a big question. Either the renderer has to get its spacial info from the layer above, or it has to build its own spatial info. The renderer has to be able to calculate quickly which objects are in range of a light, for example.

The price Bevy pays for this is that it doesn’t really use Rust ownership. Bevy has its own run-time dynamic ECS system. You have to do everything Bevy’s way.

It’s possible to do serious 3D in Rust, but it’s a real grind.

“If it was easy, someone else would have done it” – Pepe’s Towing, LA.

Demo video here.

All the examples, except scene_viewer build and run fine on my mac. (scene_viewer builds, but the instructions written to the console when run do not work).

Not sure if you’re asking for someone to just build & run, or look out for anything looking out of order. There are some minor visual artifacts on the cube’s outer edges, but those could be intentional? (I haven’t run on any other platforms, so I don’t know if it’s mac-specific).

Intel-based mac, running macOS 15.2, using Rust 1.83.0.

Looking good!

Thanks.

Why such a tall and thin image? It’s usually square, but resizable. “cube” is supposed to be a full cube in a square window. Try “animation” – that’s a harder test.

The shadow artifacts are a known rendering bug. It’s a roundoff error problem that causes flat surfaces to shadow themselves.

scene_viewer doesn’t ship with the scene files, unfortunately. Licensing issues. It reads standard glTF files. The standard Khronos demo files should work. Now that Khronos put those on Github, I should make scene_viewer look there.

Good points, that need to be fixed before a release to crates.io.

Yeah, it wasn’t a brilliant move of me to attach that image without clearly spelling out that it was just a screenshot of a small area just to show the artifacts. The actual application shows the entire thing.

The animation demo works great; resizing the window works fine (animation keeps running; aspect ratio is preserved, and the client area is redrawn as expected).

Kudos for getting low-level GPU stuff to run well on a platform you couldn’t test it on.

Kudos for getting low-level GPU stuff to run well on a platform you couldn’t test it on.

That’s not me. That’s really the Winit and WGPU groups. They’re the ones who do the cross-platform stuff.