cgltf VS learn-wgpu

If you want to go all the way, https://learnopengl.com/ is a favorite around here. You could build a glTF viewer from scratch starting from that tutorial and https://github.com/jkuhlmann/cgltf and eventually building towards https://google.github.io/filament/Filament.html or whatever wacky artsy direction you like.

Use https://github.com/jkuhlmann/cgltf to parse the files. https://github.com/ocornut/imgui for your UI. Maybe https://www.libsdl.org/ just to set up a window, handle mouse clicks and initialize the GL context in that window.

Use glTF and https://github.com/jkuhlmann/cgltf Or, looks like you are using C#, so https://github.com/vpenades/SharpGLTF

Do you really have to use fbx? An open format like gltf is better supported, and there are bazillions loaders(I use cgltf without any issues, which is also used by raylib, Unigine and bgfx). It's also a perfect fit for OpenGL.

I recently discovered this pattern in cgltf (https://github.com/jkuhlmann/cgltf), and I agree, it makes deployment so much nicer.

Use https://github.com/jkuhlmann/cgltf It’s the most popular loader.

It's easy to generate a BVH for a generated triangle set (like a fractal pyramid or a dense cube). But, quickly generating a high quality BVH for a loaded model requires some research. Use https://github.com/jkuhlmann/cgltf to load models.

Write a simple glTF viewer in OpenGL. This is a throw-away warm-up. So, don't fret over the code. Don't do anything complicated. Shoot for a simple, forward renderer for a simple, animated character with trivial Phong lighting, diffuse map, normal map and a basic directional shadow map. Use OpenGL ES 3.0/GL 4.3 API with no crazy features. Don't worry about performance. Use https://github.com/jkuhlmann/cgltf to load the files. KTX is a great container for textures.

If you haven't seen it: https://sotrh.github.io/learn-wgpu/ is a good introduction that will explain most of what you asked, then can refer to rend3d or bevys renderer to see how a render graph works.

I suggest looking into Rust for developing WASM applications with WebGPU, since Rust has in my experience way better support for WASM than c++. wgpu is the implementation of the WebGPU standard in rust and is very well documented. It also isn't just a backend for WebGPU but also for OpenGL, WebGL, Vulkan, Metal and DirectX, so you application can run on every device. There is a great tutorial series here.

So my advice would be to try Bevy, but don't force it if it doesn't work for you. If you're interested in more "low-level" graphics programming or you have some experience in that area, then learning wgpu is another thing you can do (and if you start doing advanced things with Bevy, you will want to be familiar with wgpu anyway)

When should I create encoders and render passes? I'm following these WebGPU tutorials here, and it creates both an encoder and render pass from that encoder on a per-frame-basis. Can it be expensive to create these each frame? Should I at least cache the encoder to somewhere more persistent, so that I'm not creating a new one each frame? It looks like creating render passes need to be created each frame because they need to be dropped from their scopes in order to finish the render pass before submitting the queue.

For context, I've got rudimentary knowledge of how to work with shaders through learnopengl.com, and https://sotrh.github.io/learn-wgpu/.

* I've left this for last, but the explicit binding model sucks. WebGPU is fairly high level, but keeping explicit binding instead of requiring binding arrays is awful. Every time you want to add a texture/buffer/etc to your shader, you need to modify the bind group layout, modify the bind group, and then modify the shader, and keep those definitions in sync. When you have multiple pipelines, bind groups, shaders, and modular systems that only need certain resources under different conditions or certain parts of different shaders, it's just awful to keep track of. The ergonomics are terrible. I wish WebGPU would've required binding arrays and just accepted losing support for some older devices. In Bevy we plan to write an abstraction that acts more like binding arrays and falls back to explicit bindings where needed, but that's still a lot of work.

Overall, I generally think wgpu was/is the right choice for Bevy. The ergonomics could still use work, we leave performance on the table, we don't get all the advanced and new features, and the growing pains were (and still are, to a lesser degree) real. But we still get better ergonomics compared to other options, WebGPU support for browsers, 1 rendering backend vs at least 3 (Vulkan/Metal/WebGL2), and the rest of the issues are fixable over time and with more work done on both Bevy's side and the library and tooling side.

Sometimes I wish we went with just Vulkan+Metal and could drop down to lower level stuff, get access to new features, and just generally not have to deal with extra layers and immature tooling. But I still think it's the right choice for the project overall. Discalimer: just my own opinion, I don't represent the project.

> Also, have you thought of teaming up with anyone who is explicitly teaching webgpu / wgsl? Seeing someone create a rust perspective course on learning webgpu could be nice.

Learn wgpu (https://sotrh.github.io/learn-wgpu) provides a nice intro to WebGPU/WGSL. I don't think there's really anything Bevy specifically would be able to provide. Once you wrap your head around the APIs themselves, generally the hard part of graphics programming is dealing with the boilerplate, and the actual 3D rendering techniques themselves irrespective of the API you write in.

That said, there's a few improvements I've though about contributing to learn wgpu to cover the more advanced side of things (compute shaders, storage resources, alignment rules, etc), but I haven't had time lately.

A little bit of context: I am working on translating https://observablehq.com/@flimsyhat/tdse-simulation / https://davidar.io/post/quantum-glsl to a wgpu based implementation. So far, I have adapter the triangle example by adding a buffer that can be read to and written to by both the render shader and a compute shader. However, when I try to initialize the values in the buffer inside of a compute shader ( which I know can be done on the CPU as well, but I need to write to the buffer on the GPU eventually ), I get the error "The pipeline layout, associated with the current compute pipeline, contains a bind group layout at index 0 which is incompatible with the bind group layout associated with the bind group at 0". The only reference of this error I saw online was https://github.com/sotrh/learn-wgpu/issues/40, where the buffer was not initialized before it the compute shader attempted to write to it, however I don't think that is the case with mine.

Here’s a good tutorial that I followed to get things workings: https://sotrh.github.io/learn-wgpu/