-
-
Notifications
You must be signed in to change notification settings - Fork 3.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Implement lightmaps. #10231
Implement lightmaps. #10231
Conversation
TODO: Explain this better. This pull request introduces a new render set, `PrepareBatches`, makes it run after `PrepareResources`, and moves all the batching logic into that set. It's needed because the lightmap indices must be assigned before the batches are built, because the `Mesh` data structure contains the lightmap index. Additionally, this PR makes `MeshBindGroups` generic over *mesh layout keys*. A mesh layout key is a set of flags that determines the type of bind group that the mesh needs. Prior to this PR, all the combinations of bind groups were hard-coded: `model_only`, `skinned`, `morphed`, and `morphed_skinned`. Because this PR introduces `lightmapped` as a new type of key, and that doubles the number of bind groups, to aid maintainability all of the mesh layout keys `SKINNED`, `MORPHED`, and `LIGHTMAPPED` are now flags. These flags are dealt with generically, to avoid having to write out combinations explicitly. Bind groups are further subdivided into *generic* bind groups, which can be shared among all meshes, and *mesh-specific* bind groups, which are specific to a mesh. All combinations of bind groups are generated up front.
Can we split this into a second PR? It'll make this one easier to review, but more importantly, we should be able to merge it quickly and avoid merge conflicts :)
Same comment about this actually :) |
The generated |
PR bevyengine#10231 needs to add some logic that runs as part of `PrepareResources` but before batch building, because it creates data that batch building needs. This commit adds a new render set for this. It was split out of bevyengine#10231 at reviewer request.
Currently, Bevy hardcodes the bind group layouts and bind groups for every combination of mesh features: `model_only`, `skinned`, `morphed`, and `morphed_skinned`. This causes a combinatorial explosion when new mesh features are added, as PR bevyengine#10231 does for lightmaps. To solve this, PR introduces `MeshLayoutKey`, which is a set of flags that define which mesh features are enabled. All possible combinations of bind group layouts and bind groups are generated generically, so new mesh features can be easily added in the future. To avoid a runtime combinatorial explosion, the following optimizations have been added: * Some flags are marked *generic*, which means that bind groups with them only have to be generated once and then can be reused across all meshes. * `SKINNED` and `MORPHED` bind groups are never generated if the scene doesn't contain any skinned or morphed meshes, respectively. * `SKINNED` and `MORPHED` bind groups are only generated for meshes that actually have skins or morph targets, respectively.
We now support two sets of UVs, so `uv` and `VERTEX_UVS` in shaders are now ambiguous. PR bevyengine#10231 needs to use the second UV set. To solve this, we explicitly mark the UV set we're using in the shaders, so as to distinguish it from the second UV set used for lightmaps in PR The obvious question is "why use `UV_A` and `UV_B` instead of UV0 and UV1?" The answer is that Naga doesn't currently allow preprocessor definitions that end in numbers. To work around this restriction, I renamed UV0 to `UV_A` and UV1 to `UV_B`.
I pushed a new commit that gets rid of MeshLayoutKey and builds on top of Bevy's current system instead. So #10235 is no longer a dependency. |
The generated |
How easy would this be to extend to other UV maps and to potentially use different shaders? I ask this because I use lightmaps generated by unreal and they currently go up to at least UV4 and a custom shader is required to decode them |
@Adriaaaaan You probably want to look at https://github.com/pcwalton/bevy-baked-gi which shows how to implement lightmaps without modifying Bevy itself. Note that it's targeted toward 0.12 and doesn't have ExtendedMaterial; with ExtendedMaterial it'd be a lot simpler. |
Updated to remove the renaming of |
The generated |
The generated |
Fixed. |
Looks like the Clippy failure in CI is truly unrelated, as fixing it led to another clearly-unrelated Clippy failure. I'm going to just revert that attempt to fix it; another PR will need to fix the Clippy issues, as bundling them into this one will just be confusing. |
I think we should include vertex uv b in the prepass as well. At some point we should probably consolidate the code a bit between the prepass and forward specialization so they don't diverge. |
Done. |
This should be ready to go, if nothing else comes up--the CI failure is just unrelated Clippy stuff. |
I forgot that MSAA isn't supported when using the prepass on webgl2. No issue here with bevy main or this PR. |
@pcwalton if this doesn't go through, can you please merge main in? We're struggling with CI difficulties. |
Head branch was pushed to by a user without write access
This was missed in bevyengine#10231. Closes bevyengine#11190.
# Objective Provide a public replacement for `Into<MeshUniform>` trait impl which was removed by #10231. I made use of this in the `bevy_mod_outline` crate and will have to duplicate this function if it's not accessible. ## Solution Change the MeshUniform::new() method to be public.
Objective
Lightmaps, textures that store baked global illumination, have been a mainstay of real-time graphics for decades. Bevy currently has no support for them, so this pull request implements them.
Solution
The new
Lightmap
component can be attached to any entity that contains aHandle<Mesh>
and aStandardMaterial
. When present, it will be applied in the PBR shader. Because multiple lightmaps are frequently packed into atlases, each lightmap may have its own UV boundaries within its texture. Anexposure
field is also provided, to control the brightness of the lightmap.Note that this PR doesn't provide any way to bake the lightmaps. That can be done with The Lightmapper or another solution, such as Unity's Bakery.
Changelog
Added
Lightmap
, is available, for baked global illumination. If your mesh has a second UV channel (UV1), and you attach this component to the entity with that mesh, Bevy will apply the texture referenced in the lightmap.