GenerateEnvironmentMapLight #9414
Conversation
JMS55
added
C-Feature
|
Example |
|
Example |
|
Example |
|
Example |
|
Example |
1 similar comment
|
Example |
|
@robtfm add |
|
Is Also, |
|
The rust file is not needed, no. It's unused, but I left it as a reference. I can remove it if we're ok with an opaque bin file. Up to you/cart. Also damn, I thought I had double checked my spelling :( |
| case 0u: { return vec3(1.0, v, -u); } | ||
| case 1u: { return vec3(-1.0, v, u); } | ||
| case 2u: { return vec3(u, 1.0, -v); } | ||
| case 3u: { return vec3(u, -1.0, v); } |
There was a problem hiding this comment.
These two are flipped compared to https://github.com/KhronosGroup/glTF-IBL-Sampler/blob/master/lib/source/shaders/filter.frag, is that intentional?
There was a problem hiding this comment.
I used the same get_dir function from https://www.activision.com/cdn/research/filter_using_table_128.txt that I used in the other shaders
| /// * The first frame this component is added to the skybox entity, an [`EnvironmentMapLight`] | ||
| /// component will be generated and added to the skybox entity. |
There was a problem hiding this comment.
You could just say "this is generally a quick operation".
| var color = vec4(0.0); | ||
| for (var axis = 0u; axis < 3u; axis++) { | ||
| let other_axis0 = 1u - (axis & 1u) - (axis >> 1u); | ||
| let other_axis1 = 2u - (axis >> 1u); |
There was a problem hiding this comment.
I feel like if you're switching over axis below anyway you might as well just set other_axis0 and other_axis1 explicitly in a switch statement instead of using these bit tricks.
| var color = vec3(0.0); | ||
| for (var sample_i = 0u; sample_i < 32u; sample_i++) { | ||
| // R2 sequence - http://extremelearning.com.au/unreasonable-effectiveness-of-quasirandom-sequences | ||
| let r = fract(0.5 + f32(sample_i) * vec2<f32>(0.75487766624669276005, 0.5698402909980532659114)); |
There was a problem hiding this comment.
Factor this out into a rand function :)
There was a problem hiding this comment.
It's 1 line, I'm inclined not to 😅
|
Diffuse filtering is suffering from not enough samples, and fireflys. I should look at https://www.shadertoy.com/view/4c2GRh. |
| // R2 sequence - http://extremelearning.com.au/unreasonable-effectiveness-of-quasirandom-sequences | ||
| let r = fract(0.5 + f32(sample_i) * vec2<f32>(0.75487766624669276005, 0.5698402909980532659114)); | ||
|
|
||
| let cos_theta = sqrt(1.0 - f32(r.y)); |
There was a problem hiding this comment.
| let cos_theta = sqrt(1.0 - f32(r.y)); | |
| // map uniformly distributed [0..1)^2 into hemisphere with cosine importance (Lambertian distribution) | |
| let cos_theta = sqrt(1.0 - f32(r.y)); |
| fn main(@builtin(global_invocation_id) global_id: vec3<u32>) { | ||
| var id = global_id; | ||
| var level = 0u; | ||
| if id.x < 128u * 128u { |
There was a problem hiding this comment.
I think it has to do the biggest mip first for other reasons, maybe because all the mips after it depend on it. but wgsl workgroups are not guaranteed to run in any particular order so idk
| id.x -= id.y * res; | ||
|
|
||
| let u = (f32(id.x) * 2.0 + 1.0) / f32(res) - 1.0; | ||
| let v = -(f32(id.y) * 2.0 + 1.0) / f32(res) + 1.0; |
There was a problem hiding this comment.
it maps to the centers of every other 2x2 texel patch, because the lower mip level must represent those texels as one larger one that covers the area of all 4 original ones.
| id.y = id.x / res; | ||
| id.x -= id.y * res; | ||
|
|
||
| let u = (f32(id.x) * 2.0 + 1.0) / f32(res) - 1.0; |
There was a problem hiding this comment.
| let u = (f32(id.x) * 2.0 + 1.0) / f32(res) - 1.0; | |
| // remap integers [0..res-1]^2 to the centers of every 2x2 texel patch we are mipping down to one texel, in (-1..1)^2 | |
| let u = (f32(id.x) * 2.0 + 1.0) / f32(res) - 1.0; |
|
This PR has artifacts unfortunately. It can't be merged as-is. |
|
|
||
| id.z = id.y; | ||
| let res = 128u >> level; | ||
| id.y = id.x / res; |
There was a problem hiding this comment.
could save an integer division here with
| id.y = id.x / res; | |
| id.y = id.x >> (7 - level); |
This commit introduces a new type of camera, the *omnidirectional* camera. These cameras render to a cubemap texture, and as such extract into six different cameras in the render world, one for each side. The cubemap texture can be attached to a reflection probe as usual, which allows reflections to contain moving objects. To use an omnidirectional camera, create an [`OmnidirectionalCameraBundle`]. Because omnidirectional cameras extract to six different sub-cameras in the render world, render world extraction code that targets components present on cameras now needs to be aware of this fact and extract components to the individual sub-cameras, not the root camera component. They also need to run after omnidirectional camera extraction, as only then will the sub-cameras be present in the render world. New plugins, `ExtractCameraComponentPlugin` and `ExtractCameraInstancesPlugin`, are available to assist with this. Each side of an omnidirectional camera can be individually marked as active via the `ActiveCubemapSides` bitfield. This allows for the common technique of rendering only one (or two, or three) sides of the cubemap per frame, to reduce rendering overhead. It also allows for on-demand rendering, so that an application that wishes to optimize further can choose sides to refresh. For example, an application might wish to only rerender sides whose frusta contain moving entities. In addition to real-time reflection probes, this patch introduces much of the infrastructure necessary to support baking reflection probes from within Bevy as opposed to in an external program such as Blender, which has been the status quo up to this point. Even with this patch, there are still missing pieces needed to make this truly convenient, however: 1. Baking a reflection probe requires more than just saving a cubemap: it requires pre-filtering the cubemap into diffuse and specular parts in the same way that the [glTF IBL Sampler] does. This is not yet implemented in Bevy; see bevyengine#9414 for a previous attempt. 2. The cubemap needs to be saved in `.ktx2` format, as that's the only format that Bevy presently knows how to load. There's no comprehensive Rust crate for this, though note that my [glTF IBL Sampler UI] has code to do it for the specific case of cubemaps. 3. An editor UI is necessary for convenience, as otherwise every application will have to create some sort of bespoke tool that arranges scenes and saves the reflection cubemaps. The `reflection_probes` example has been updated in order to add an option to enable dynamic reflection probes, as well as an option to spin the cubes so that the impact of the dynamic reflection probes is visible. Additionally, the static reflection probe, which was previously rendered in Blender, has been changed to one rendered in Bevy. This results in a change in appearance, as Blender and Bevy render somewhat differently. Partially addresses bevyengine#12233. [glTF IBL Sampler]: https://github.com/KhronosGroup/glTF-IBL-Sampler [glTF IBL Sampler UI]: https://github.com/pcwalton/gltf-ibl-sampler-egui
This commit introduces a new type of camera, the *omnidirectional* camera. These cameras render to a cubemap texture, and as such extract into six different cameras in the render world, one for each side. The cubemap texture can be attached to a reflection probe as usual, which allows reflections to contain moving objects. To use an omnidirectional camera, create an [`OmnidirectionalCameraBundle`]. Because omnidirectional cameras extract to six different sub-cameras in the render world, render world extraction code that targets components present on cameras now needs to be aware of this fact and extract components to the individual sub-cameras, not the root camera component. They also need to run after omnidirectional camera extraction, as only then will the sub-cameras be present in the render world. New plugins, `ExtractCameraComponentPlugin` and `ExtractCameraInstancesPlugin`, are available to assist with this. Each side of an omnidirectional camera can be individually marked as active via the `ActiveCubemapSides` bitfield. This allows for the common technique of rendering only one (or two, or three) sides of the cubemap per frame, to reduce rendering overhead. It also allows for on-demand rendering, so that an application that wishes to optimize further can choose sides to refresh. For example, an application might wish to only rerender sides whose frusta contain moving entities. In addition to real-time reflection probes, this patch introduces much of the infrastructure necessary to support baking reflection probes from within Bevy as opposed to in an external program such as Blender, which has been the status quo up to this point. Even with this patch, there are still missing pieces needed to make this truly convenient, however: 1. Baking a reflection probe requires more than just saving a cubemap: it requires pre-filtering the cubemap into diffuse and specular parts in the same way that the [glTF IBL Sampler] does. This is not yet implemented in Bevy; see bevyengine#9414 for a previous attempt. 2. The cubemap needs to be saved in `.ktx2` format, as that's the only format that Bevy presently knows how to load. There's no comprehensive Rust crate for this, though note that my [glTF IBL Sampler UI] has code to do it for the specific case of cubemaps. 3. An editor UI is necessary for convenience, as otherwise every application will have to create some sort of bespoke tool that arranges scenes and saves the reflection cubemaps. The `reflection_probes` example has been updated in order to add an option to enable dynamic reflection probes, as well as an option to spin the cubes so that the impact of the dynamic reflection probes is visible. Additionally, the static reflection probe, which was previously rendered in Blender, has been changed to one rendered in Bevy. This results in a change in appearance, as Blender and Bevy render somewhat differently. Partially addresses bevyengine#12233. [glTF IBL Sampler]: https://github.com/KhronosGroup/glTF-IBL-Sampler [glTF IBL Sampler UI]: https://github.com/pcwalton/gltf-ibl-sampler-egui
Objective
Solution
GenerateEnvironmentMapLightcomponent.Changelog
GenerateEnvironmentMapLightfor automatically generating anEnvironmentMapLightcomponent from aSkyboxcomponent. This can be used instead of KhronosGroup'sglTF-IBL-Sampler.