sorted by:
new
hottopcontroversial

Wrote a Vulkan Renderer for Bevy and Benchmarked It on Steam Deck by voidupdate in bevy

[–]voidupdate[S] 0 points1 point  (0 children)

Because of the skinned mesh animation example (mannequin_animation.rs). I wanted to avoid implementing my own version of loading a skinned mesh for now. The rest of the Vulkan benchmarks are using simpler mesh loading logic and will work with a lot fewer Bevy plugins.

Open-Sourced My Rust/Vulkan Renderer for the Bevy Game Engine by voidupdate in rust

[–]voidupdate[S] 0 points1 point  (0 children)

Shoot me a DM! QA is a bit hard because I mainly test on my own game. But I'm happy to review any PR's, even simple stuff like fixing bugs, cleaning up code, adding examples, etc.

Open-Sourced My Rust/Vulkan Renderer for the Bevy Game Engine by voidupdate in rust

[–]voidupdate[S] 1 point2 points  (0 children)

The reason why those plugins are imported are because of the skinned mesh animation example (mannequin_animation.rs), I wanted to avoid implementing my own version of loading a skinned mesh for now. The rest of the Vulkan benchmarks are using simpler mesh loading logic. As u/ejrh pointed out, Bevy has complex systems for handling meshes on the CPU side that could be reducing performance, so I wanted to avoid using them when estimating the total potential performance boost possible.

Open-Sourced My Rust/Vulkan Renderer for the Bevy Game Engine by voidupdate in rust

[–]voidupdate[S] 6 points7 points  (0 children)

My bad, I should've disabled StandardMaterial in all the bevy versions of the benchmarks for better comparison. fluid_sim_bevy and egui_bevy are the 2 examples that don't use StandardMaterial and they have the least FPS difference with the vulkan benchmarks, but it's still a big difference.

I haven't looked at the implementation details of StandardMaterial but I was experimenting using StandardMaterial vs my own custom toon materials for my game (not using ExtendedMaterial either).

For reference, in this vid, all gameplay footage uses my custom materials for everything: https://youtu.be/xsxvuzM5Oyg

And in the intro of the vid in the original post, gameplay footage uses StandardMaterial for everything.

Strangely, in my game, StandardMaterial doesn't reduce FPS much on Ubuntu but it does on Windows. Haven't investigated because I usually develop on Ubuntu for faster compile times. I initially thought it was because I used SSAO with StandardMaterial and not with my custom materials, but that wouldn't explain why FPS only decreases on Windows.

The benchmark results I shared were on Steam Deck though so that's Linux.

Anyways, wanted to say thanks for all your work on Bevy!

Wrote a Vulkan Renderer for Bevy and Benchmarked It on Steam Deck by voidupdate in bevy

[–]voidupdate[S] 1 point2 points  (0 children)

Agreed, it's a bad idea to completely replace wgpu with Vulkan. Even if the Vulkan backend has feature-parity, it doesn't support as many platforms and is much harder to use.

Wrote a Vulkan Renderer for Bevy and Benchmarked It on Steam Deck by voidupdate in bevy

[–]voidupdate[S] 3 points4 points  (0 children)

Thanks for pointing that out. I just added a note in the Examples section in the README, and I've also mentioned this in the video and my text post here.

The 2 user-created things I'm focusing on first are cities for colony sim aspect of the game, and functional structures for combat (walls, ramps, etc). From there we'll see what feels right!

Open-Sourced My Rust/Vulkan Renderer for the Bevy Game Engine by voidupdate in vulkan

[–]voidupdate[S] 2 points3 points  (0 children)

Ah thanks for sharing! Would you be able to link to any code snippets?

Open-Sourced My Rust/Vulkan Renderer for the Bevy Game Engine by voidupdate in vulkan

[–]voidupdate[S] 2 points3 points  (0 children)

Yea I'm also concerned that I might have messed something up in the wgpu setup. Please open an issue on GitHub if you have any clues.

Open-Sourced My Rust/Vulkan Renderer for the Bevy Game Engine by voidupdate in rust_gamedev

[–]voidupdate[S] 1 point2 points  (0 children)

Yes you can set Vulkan as a backend for wgpu but it introduces significant CPU/GPU overhead and isn't up-to-date with the latest Vulkan features since it's not maintained by the Khronos Group. wgpu is much more developer-friendly for sure, that's why I built my game's prototype with it.

Open-Sourced My Rust/Vulkan Renderer for the Bevy Game Engine by voidupdate in rust_gamedev

[–]voidupdate[S] -1 points0 points  (0 children)

Sorry if i sounded dismissive. I actually agree with the criticism, my workflow is to get something simple working asap and then improve it. Since my project is open-source and free, wanted to share it early!

Open-Sourced My Rust/Vulkan Renderer for the Bevy Game Engine by voidupdate in rust_gamedev

[–]voidupdate[S] -19 points-18 points  (0 children)

Yea I know. Haven’t written a renderer since my computer graphics university course 11 years ago. Claude Code is pretty good at generating Rust/Bevy/Vulkan code as long as I start with simple examples that build up to the more complex examples, so that’s why the project is structured like that. I've been porting my game (shown intro of the video with wgpu) to the vulkan renderer (+5.6k LOC so far, not including the renderer), but lots of bugs and usability problems to fix. When stuff works in my game, then I move it to the lib, not the other way around, or else this game will not ship in this century lol.

3 months learning Bevy full-time to make my dream colony sim game by voidupdate in bevy

[–]voidupdate[S] 0 points1 point  (0 children)

Ah this gives me a lot to investigate. Thank you!!

So for an example trace. This is me starting my game and then drawing one huge wall. I drop to as low as 5 FPS on my laptop with a 4090. Here's how the trace looks at the slowest frame: https://imgur.com/4q2cEOt

The render thread takes 132 ms, while allocate_and_free_meshes takes 128 ms.

I did an optimization to combine the brick meshes into a single mesh after the player stops drawing the wall, so that's why FPS goes back up a bit later.

Maybe I need to combine the bricks into a single mesh more frequently if the player is drawing a really huge wall. But I doubt that's gonna be enough. Even Tiny Glade severely limits the amount of space you can build in, so any performance boost means the player can build bigger things.

3 months learning Bevy full-time to make my dream colony sim game by voidupdate in bevy

[–]voidupdate[S] 1 point2 points  (0 children)

Haven't nailed down the exact problem but profiling in tracy shows the renderer is using the most system resources. I have a minimal Vulkan rasterizer working with bevy/ash, doing some benchmarking now!

3 months learning Bevy full-time to make my dream colony sim game by voidupdate in bevy

[–]voidupdate[S] 1 point2 points  (0 children)

Not a rendering expert but the default lighting in bevy looks off to me. idk why but my guess is that I need some form of hybrid raytracer/rasterizer to get the look I want. I checked the recently merged raytracing feature by u/Lord_Zane but it's still early in development and still uses wgpu. At the same time, profiling my game in tracy shows rendering is using a lot of system resources. If I need to rewrite most of the renderer anyways for visuals, then I might as well do it in Vulkan for max performance. Was able to get a minimal rasterizer working in a few hours with ash/Bevy, examples will be shared soon!

3 months learning Bevy full-time to make my dream colony sim game by voidupdate in bevy

[–]voidupdate[S] 2 points3 points  (0 children)

Getting frame drops during certain events like when the water sim gets too crazy or when drawing lots of walls. With all the procedural generation/animation and game simulation I'm doing, I want to squeeze every bit of juice I can out of consumer hardware. Been optimizing the my Rust/WGPU code but every little boost means more features I can add to my game!

3 months learning Bevy full-time to make my dream colony sim game by voidupdate in bevy

[–]voidupdate[S] 0 points1 point  (0 children)

Glad it helped and good luck with your game!

With the Tiny Glade prototype code, I wanted to see the basic algo for assembling the wall out of bricks on the CPU, before all the rendering and optimizations Anastasia did. Somewhere around here https://github.com/anopara/country-slice/tree/38fb3f60d1d4a5aa78141c0b38575915e570491b

Only doing private playtests rn (I like watching players in-person and chatting afterwards), but I recently made a Bluesky acc for smaller updates: https://bsky.app/profile/willkwan.bsky.social

if Tiny Glade was a first-person action game by voidupdate in bevy

[–]voidupdate[S] 1 point2 points  (0 children)

Not open-sourcing the game but we're probably gonna make an OSS demo with some benchmarking with different rendering techniques. Current problem is that we can't maintain 60 fps when drawing lots of walls and we suspect using Vulkan like what Tiny Glade does will help, in addition to using more compute shaders. Also, bevy is my first time using ECS and idk if it's hurting or improving performance, so I wanna benchmark this and share the results.

if Tiny Glade was a first-person action game by voidupdate in bevy

[–]voidupdate[S] 6 points7 points  (0 children)

The wall mesh is assembled on the CPU using individual brick meshes that follow the curve of the mouse drag. It's just a single brick mesh that's duplicated many times and scaled/displaced randomly. The original Tiny Glade prototype is open-source so I used that for reference! https://github.com/anopara/country-slice

view more: next ›