Game dev in Rust, a year ago – community

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

I still use the Rend3/WGPU/Vulkan graphics stack. It works great at this point.

Note:

• Many big game projects left Rust in 2024. Others found ownership too restrictive. Some complain about compile times.
• arewegameyet.rs stopped updating last July.
• Rend3 abandoned. Now I have to continue that myself, which I do as broken 3-hp. I have it so far Wgpu, Winit, Grantedand other versions, and finally found and fixed the race condition that kept causing the crashes. I ran for over 40 hours without panic. Things are looking up. If you want to try, use the “wgpu23safe” branch. I’d appreciate someone testing that on MacOS, which I don’t use. Build it and run rend3-examples. If anyone is interested, I can release it crates.io in a month or two. Currently, it still has patches in library crates, which crates.io will not allow.
• Graphics stacks are still very slow if you put enough content to keep the GPU busy. Running out of CPU time at about 25% GPU load with NVidia 3070. Requires Vulkan without bind. Requires multiple Vulkan queues. Can be obtained from Wgpu in 2025. If you don’t need maximum performance, this stack should work OK.
• Have some good work with Orbit rendering demobut it seems to have been abandoned. That’s advanced thinking about how the GPU can do more work.
• Translate has some promise, but it’s not ready for use and it’s just a developer. They have some EU funding.
• If you do 3D work in Rust, expect to spend half your time on low-level maintenance. Budget accordingly.
• Crate churn remains a problem. Winit, Wgpu, Egui, and their friends must move forward in lockstep as APIs change. If one of them changes, it will be about 1-2 months before the others arrive. Then you fix your own code to deal with the breaking changes.
• Whenever there’s a serious problem that’s hard to find, it’s because someone built their own allocation system instead of using Rust’s safe builds. Putting everything in an array and passing array indices in multi-threaded programs is a common problem.

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

This is a consequence where you cut the problem. Whether you can make an efficient renderer that can’t be a full game engine with a full scene graph, like Bevy, is a big question. Either the interpreter must obtain its spatial information from the layer above, or it must construct its own spatial information. The interpreter must be able to quickly calculate which objects are in the range of a light, for example.

The price Bevy paid for this was that it never used 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’s easy, someone else will do it” – Dragging Pepe, LA.

Demo video here.

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

Not sure if you’re asking for someone to build and run, or looking for something really bad. There are some small visual artifacts on the outer edge of the cube, but could that be intentional? (I’m not running 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.

Looks great!

Thank you.

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

Shadow artifacts are a known rendering bug. This is a roundoff error problem that causes flat surfaces to shadow themselves.

scene_viewer not shipped with the scene files, unfortunately. Licensing issues. It reads standard glTF files. The pattern Khronos demo files must work. Now that Khronos has put those on Github, I have to do it scene_viewer look there.

Good points, which should be fixed before a release of crates.io.

Yes, it was a bad move on my part to include that image without clearly spelling out that it’s just a screenshot of a small area to show the artifacts. The actual application shows the whole thing.

The animation demo is pretty cool; The window resizing works very well (the animation continues to run; the 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 can’t even test it on.

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

That’s not me. Those are actually the Winit and WGPU groups. They do the cross-platform stuff.