wgpu-rs VS bevy-website

You could start with one of examples from wgpu and tinker with it to see if that's your thing. Ie. copy hello-triangle and add more triangles / make them move, etc.

wgpu-rs (https://github.com/gfx-rs/wgpu-rs) is probably closer to what you're looking for, it's a "high level wrapper" over wgpu-core (Which implements "WebGPU", an upcoming browser API for graphics using gfx-rs, and AIUI "implements" means this is what a browser might use to actually call a graphics API when javascript uses webGPU, although if you're compiling for wasm it could just call the browser APIs). It can run natively, ignore the fact it has "Web" in the name

rust-gpu) is used for compiling a compute shader written in Rust to SPIR-V. wgpu-rs is used natively for running the GPU computation.

For web assembly there is the unofficial bevy_webgl2 plugin. Official bevy web assembly support would probably use the wgpu webgl backend, which still needs some work, and is currently untested in bevy.

We let wgpu https://github.com/gfx-rs/wgpu-rs handle our graphics backend abstraction, so our OpenGL support will come whenever they implement and release it. Currently, it seems to be a WIP.

It's the same thing, the Rust implementation is just called[wgpu](https://wgpu.rs/)

Same as with GLSL, isn't it? What we do in wgpu-rs examples, and that's something I expect to see more widely, is having an integration test that just parses all the WGSL in the project and reports errors. Ideally though, we'd have a set of IDE plugins to do the parsing and report errors right where you type the code. We'd appreciate any help to get these started!

Also you could use an existing cross-platform graphics library, e.g. wgpu-rs. It supports Vulkan, Metal, DirectX, OpenGL and WebGPU. Oh and it seems to allow switching backends at compile-time via the WGPU_BACKEND environment variable, so maybe check out how they're doing it.

https://github.com/bevyengine/bevy-website/issues/1097 Yep, on our wishlist and will be added :)

We'd like to open the floodgates on Bevy Book development asap. This taking so long has largely been my fault ... I've been overly protective of the Bevy Book while also not giving it the attention it deserves. Here is our current plan: https://github.com/bevyengine/bevy-website/issues/623#issuec..., which I'd like to execute during the next cycle.

Latest Progress: https://github.com/bevyengine/bevy-website/pull/550/files

I do want previews though.

API docs, examples and the revised book: https://github.com/bevyengine/bevy-website/pulls?q=is%3Aopen...

Strongly agreed on the need for better introductory material; the existing book is extremely incomplete.

> I don't have this clear. Are 5/6 teams actually building commercial games with Bevy, or they just planning to do it in the future? This is a crucial distinction.

I know of 2 released commercial projects, the CAD team, a few indie devs who have started and 3 or so small studios who are looking to start. There's a little thread in the Discord where I've rounded folks up: [Bevy in production](https://discord.com/channels/691052431525675048/995713618526...).

We also do some real cleverness around split borrows in order to enable automatic system parallelism. This draft book page goes into more concrete details :)

Can do

I used the unofficial bevy cheatbook a lot to learn the ropes. Everyone on the discord is super friendly and helpful and the official documentation is being updated, you can check out the PRs on the book branch

If you're curious about the ECS side of things, that chapter is now ~approximately complete, and should make an excellent learning resource: https://github.com/bevyengine/bevy-website/pull/182