Our great sponsors
-
InfluxDB
Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.
-
WorkOS
The modern identity platform for B2B SaaS. The APIs are flexible and easy-to-use, supporting authentication, user identity, and complex enterprise features like SSO and SCIM provisioning.
Ambient is a very poor choice for OP if they're (rightfully) struggling with existing Rust render tech's immaturities. Not only is it poorly optimised at present (esp. for OP's use case), but it is also far from mature (see Ambient#6, Ambient#76, Ambient#150, ...).
render-bench -- scene update performance test fixture. This exercise rend3->wgpu->vulkan. It draws a city of identical buildings, then, from a second thread, periodically deletes half of them and re-creates them. If the stack is performing as intended, the updates from the second thread should not impact the frame rate from the main thread. But due to lock problems at the WGPU level, the frame time goes from 16ms to 700ms when the update happens.
Have you looked into what thirdroom or ambient have done in the space?
wgpu needs to iterate on storage locks, that has been known but wasn't prioritized yet. Connor wanted to fix this badly, and hopefully will find time to do so. Most of the effort was spent on chasing WebGPU spec, and good news is - it's pretty much final, with Chrome releasing its implementation any month now (and Firefox/Safari hopefully following). So naturally we should expect the focus to slowly shift into performance in this year.
Bevy currently does all gpu drawing/submits on a single thread (though it's now done concurrently with game logic!), so even if wgpu fixed their locking issues tomorrow Bevy still wouldn't really benefit from it. (and has relatively heavy per-drawcall cost, as well as no built-in batching or bindless to reduce the draw call load).
JPEG 2000 decoder crashes Trying to read files at reduced resolution crashes with memory access errors. This is jpeg2k (Rust) calling jpeg2000-sys (Rust glue to C foreign function interfaces) calling OpenJPEG (all C). The problem can now be reproduced at the C level alone, under Valgrind. The developers of the top two levels have been very helpful, but the trouble is down in the rather painful C code at the bottom. The OpenJPEG maintainers are way behind on fixes, despite being funded.
Rend3 crashes The library's internal memory allocator for GPU objects is losing objects and panicking. This seems to be a race condition that comes up once you get past displaying static scenes and start having moving objects. Rend3 has one overworked main developer. If you're qualified to work on GPU-level stuff, which I am not, that project could use help.
JPEG 2000 decoder test fixture. This exercises jpeg2k->jpeg2000-sys->OpenJPEG. The last one is in C, and valgrind shows it referencing un-initialized memory. It randomly segfaults. OpenJPEG has a long history of doing this, and has been the subject of several CERT security advisories. The author of jpeg2k has managed to contain the the problem by running OpenJPEG in a WASM sandbox. This keeps the program from crashing, but there is a 2.6x performance penalty. A bug report has been submitted to the OpenJPEG maintainers, who are funded by universities and companies but over 200 issues behind.
ui-mock -- game GUI test fixture This exercises rfd->egui->rend3->wgpu. It's a game GUI with menus and dialogs, but no game behind it, just a 3D drawing of a cube. It's useful for making bugs in that stack repeatable. That's been helpful in wringing out obscure bugs in egui.
Related posts
- Godot is not the new Unity – The anatomy of a Godot API call
- Meta Releases Intermediate Graphics Library
- Is bevy the best option for a Rust based game engine (long term)?
- Really frustrated. [Warning: Bit of a negative rant]
- Chrome ships WebGPU, a sort-of successor to WebGL. How soon do you see this being adopted by the game dev community?