The crate itself is further split between the realtime lighting plugin, base "raytracing scene" plugin that could be used for your own custom raytracing-based rendering, and the reference pathtracer I use for comparing the realtime lighting against.
There were some small changes to the rest of Bevy, e.g. adding a way to set extra buffer usages for the buffers we store vertex/index data in from another plugin https://github.com/bevyengine/bevy/pull/19546, or copying some more previous frame camera data to the GPU https://github.com/bevyengine/bevy/pull/19605, but nothing really major. It was added pretty independently.
I've been working on raytraced lighting in the Bevy game engine, using wgpu's new support for hardware raytracing in WGSL. The initial prototype is launching with the release of Bevy 0.17 tomorrow, but there's still a ton left to improve. Lots of experimenting with shaders and different optimizations.
I've been evaluating texture compression options for including in Bevy https://bevy.org, and there's just, not really any good options?
Requirements:
* Generate mipmaps
* Convert to BC and ASTC
* Convert to ktx2 with zstd super-compression
* Handle color, normal maps, alpha masks, HDR textures, etc
* Open source
* (Nice to have) runs on the GPU to be fast
I unfortunately haven't found any option that cover all of these points. Some tools only write DDS, or don't handle ASTC, or want to use basis universal, or don't generate mipmaps, etc.
It's better than OpenGL 3 in my opinion. It has a much saner API, is a lot more predictable, and API calls can be made from multiple CPU threads.
OpenGL 4 has some more advanced features like bindless that WebGPU lacks (and Vulkan has), but I wouldn't use OpenGL because of that.
My recommendation is start with WebGPU if you're new to graphics programming. Once you're at the end point where you have a bunch of working features and have optimized your engine as much as you can, and are starting to push against WebGPU limits, then I would think about switching to Vulkan 1.3 / DirectX 12.
I develop a lot of the more advanced features for Bevy, so I'm fully aware :)
The unfortunate reality is that wgpu does not have enough funding. Extremely valuable features like bindless, multi queue, and mesh shaders/raytracing are missing. CPU-overhead is fairly high. Things like debugging support are not great. Having to abstract over all of Vulkan/DX12/Metal brings difficulties.
I love wgpu, and don't begrudge the volunteer devs (they've done a lot of amazing work already), but I'm also frequently frustrated by its limitations.
> Now instead of vendors writing this correctly once for everyone, everyone can do it poorly.
_Vendors_ did it poorly, which is why everyone wanted to get away from them. You could argue they over-corrected and left _too_ much to the user, but better safe than sorry.
Sure users can write bad code as well, but at least it's _consistently_ bad, and fully under their control. There are so many fewer problems nowadays like "oh it works on my desktop, but on this older intel GPU for a user with outdated drivers it segfaults in the driver, and there's nothing we can do to fix it ourselves".
It depends on your requirements and experience level. Using WebGPU is _much_ easier than Vulkan, so if you don't have a lot of prior experience with all of computer graphics theory / graphics APIs / engine design, I would definitely start with WebGPU. You can still get very far with it, and it's way easier.
Exactly this. Vulkan, especially Vulkan 1.0, was never really meant directly for graphics developers. It was meant specifically for engine developers that didn't want to have to deal with buggy and inconsistent drivers, e.g. Nvidia vs AMD vs crappy Android phones.
The solution Vulkan came up with was "make everything as explicit and user-controlled as possible", and leave "implementing a more user friendly driver" up to user-space, so that it could be tweaked by users, wouldn't be tied to driver updates users would never do, would be consistent across platforms, etc.
Except that never really happened. There are some graphics-driver-as-a-library projects (daxa, nabla, etc), but none with a large amount of community support.
Meanwhile GPU's evolved over time (AMD RDNA1, Nvidia Turing, Intel Arc, Apple Silicon), and it turns out that some of the choices Vulkan 1.0 bet on weren't great (explicit extensive pipeline state, binding model, render passes).
Vulkan 1.2/1.3 cleaned up a lot of this (dynamic state, descriptor indexing, sync v2), which also happens to improve ergonomics a lot to the point that it's much less painful to use Vulkan directly nowadays, as long as you're ok dropping support for older platforms.
The actual issue is not CPU-side. The issue is GPU-side.
The CPU feeds commands (CommandBuffers) telling the GPU what to do over a Queue.
WebGPU/wgpu/dawn only have a single general purpose queue. Meaning any data upload commands (copyBufferToBuffer) you send on the queue block rendering commands from starting.
The solution is multiple queues. Modern GPUs have a dedicated transfer/copy queue separate from the main general purpose queue.
> All those layers create problems. WGPU tries to support web browsers, Vulkan, Metal, DX11 (recently dropped), DX12, Android, and OpenGL. So it needs a big dev team and changes are hard. WGPU's own API is mostly like Vulkan - you still have to do your own GPU memory allocation and synchronization.
The first part is true, but the second part is not. Allocation and synchronization is automatic.
So the AI doesn't actually understand the code does it? It only looks for similar things. So if I'm writing a game in Rust using the hecs ECS library, how is it going to help me? How many other people have written a game in that language using that library in this genre trying to do this task before? Probably very very few.
And yeah that's a niche example, maybe this is super helpful for writing a react app or something very library heavy. But gut feeling without trying it is that there's no way this could actually work on anything but the most common tasks that you can google and find solutions for already, just made easier so you don't actually have to google for it.
When I used tabnine which learned from you as you edit, it was fairly helpful for very repetitive code within the same project. But it was no where near "read english and write the code I meant for it". I'm curious to know how well this actually performs for non-common tasks, and whether it can understand ideas in your codebase that you come up with. If I make a WorldAbstractionOverEntities thing in my code, and then later use it in the project, will the AI be able to help me out? Or is it going to go "sorry, no one on github has used this thing you came up with an hour ago, I can't help you". An AI that could understand your own codebase and the abstractions you make and not just popular libraries would be infinitely more useful imo.
That said, I haven't tried this, maybe it'll turn out really good.
1. Fail in the first X amount of time
2. Fail towards the end of their rated lifespan
So buying used drives doesn't seem like the worst idea to me. You've already filtered out the drivers that would fail early.
Disclaimer: I have no idea what I'm talking about