bevy_pbr2: Add support for most of the StandardMaterial textures

[superdump]

Normal maps are not included here as they require tangents in a vertex attribute.

[superdump]

This is not ready to merge. I thought it was as I thought I ran texture_pipelined one time and saw the same as texture, but now I think I just ran texture and didn't notice my mistake. :) It's almost there though I think. My current problem is:

cargo run --release --example texture_pipelined

...

     Running `target/release/examples/texture_pipelined`
thread 'main' panicked at 'called `Option::unwrap()` on a `None` value', pipelined/bevy_pbr2/src/render/mod.rs:174:91
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

[superdump]

Still more to fix, but making some progress:

I need to figure out a good way of mapping from view space z (where -z goes away from the camera in front of it) to some fixed number of bits of unsigned integer to fit into a sort key.

[superdump]

Now supporting unlit, double-sided, and optional texture fetches using uniform control flow:

[superdump]

I think this is ready for review.

I think the sorting should be solved separately rather than doing it in this PR. There is shadow acne too and we should add some configurable biases for this but it felt like a rabbit hole we can go down another time, I just did enough for the pbr_pipelined example to not have all spheres in shadow because the light projection's z_far was hard-coded to 20.0 which was not far enough. I've set the light projection's z_far to light.range, and I increased the FOV to 90 as I guess we will do cube maps or something.

The projection member of PointLight in pbr.frag was holding the light's view projection matrix, so I renamed that. Our 'point lights' have a radius, so I renamed them to OmniLight.

[superdump]

This is in theory (and kind of practice) working on top of the updated pipelined-rendering with wgpu types and whatnot. Unfortunately on macOS no image is displayed in the bevy window, neither on this PR nor on pipelined-rendering. But if I run it through Xcode's GPU frame debugger, I can see that everything is being drawn correctly.

[cart]

I think the real answer is that we shouldn't do that :)

If we make Drawable generic, we can make sort_key whatever type we want

[cart]

We just need to make sure that the type we choose for a given phase is suitable for all possible things in that phase

[superdump]

Are we concerned about performance of not encoding into a directly comparable data type like usize or u64 or so? Depending on the sorting algorithm, a lot of comparisons could be made and if we’re doing something like A.a < B.a || A.b < B.b || … then it could result in a lot more comparison operations in practice. @mtsr raised this point to me earlier.

[cart]

I think its worth benchmarking when we make the switch.

[cart]

This looks good to me in general. Pushed a few small tweaks that probably won't be contentious. textured_pipelined doesn't draw the texture for me though 😄

[cart]

The bound color texture is the 1x1 white texture:

[cart]

Fixed! The problem was that we were extracting and drawing meshes even when their materials' textures haven't loaded yet. This resulted in the creation (and caching) of bind groups with empty white textures. The fix is to check the load state of each mesh's material's textures prior to extracting.

[cart]

We can optimize this by pre-computing material texture load state somewhere instead of checking for each entity. We should think about the best way to do this. I'm not a huge fan of hard coding a cache for this use case, as "sub asset load status" seems like a reasonable thing to keep track of.

We do this for asset server managed assets, but we don't do it for assets directly added to Assets collections.

[cart]

I'm gonna merge this as is to keep the ball rolling. Feel free to follow up if you have alternative ideas.

[superdump]

Fixed! The problem was that we were extracting and drawing meshes even when their materials' textures haven't loaded yet. This resulted in the creation (and caching) of bind groups with empty white textures. The fix is to check the load state of each mesh's material's textures prior to extracting.

I'd forgotten to test that example after updating for the bing group caching. Thanks for fixing it!

We can optimize this by pre-computing material texture load state somewhere instead of checking for each entity. We should think about the best way to do this. I'm not a huge fan of hard coding a cache for this use case, as "sub asset load status" seems like a reasonable thing to keep track of.

We do this for asset server managed assets, but we don't do it for assets directly added to Assets collections.

It's a bit unclear from what you've written what you mean the solution should be. I'm not 100% on what the problem is either. If the material's textures haven't loaded yet then bind groups were being created that use the dummy white texture and were not being updated once the texture loaded. You fixed that to not extract the mesh if any of its material textures were not yet loaded. But you're saying that this approach of checking if the texture has loaded is inefficient and we should use some other approach? Is it specifically because it is per-entity?