Re-introduce "Replace Ambient Lights with Environment Map Lights (#17482)"

[SparkyPotato]

#17482 was reverted due to unintentional changes in ambient light rendering.
However, after further inspection, that was due to environment maps being more physically-correct, so the changes are positive.

Closes #17367.

[github-actions]

Your PR caused a change in the graphical output of an example or rendering test. This might be intentional, but it could also mean that something broke!
You can review it at https://pixel-eagle.com/project/B04F67C0-C054-4A6F-92EC-F599FEC2FD1D?filter=PR-18207

If it's expected, please add the M-Deliberate-Rendering-Change label.

If this change seems unrelated to your PR, you can consider updating your PR to target the latest main branch, either by rebasing or merging main into it.

[github-actions]

It looks like your PR is a breaking change, but you didn't provide a migration guide.

Could you add some context on what users should update when this change get released in a new version of Bevy?
It will be used to help writing the migration guide for the version. Putting it after a ## Migration Guide will help it get automatically picked up by our tooling.

[alice-i-cecile]

However, after further inspection, that was due to environment maps being more physically-correct, so the changes are positive.

Can you say more about this? Has this been discussed elsewhere?

I'd really like to do this, but we need clear rationale for changing how user scenes are rendered.

[mockersf]

AmbientLight is still a resource that is initialised by default with this PR, but also marked as deprecrated.

Does that mean we'll change again how every scene renders in the next version?

[mockersf]

Example code shouldn't use deprecated things, they need to be updated to use the new component.

[mockersf]

this would also close #17367

[aloucks]

Would it make sense to rename the EnvironmentMapLight struct to AmbientLight?

Conceptually, it is ambient light, right? Isn't it just being implemented with an environment map?

[IceSentry]

Can you say more about this? Has this been discussed elsewhere?

It was discussed on discord.

Does that mean we'll change again how every scene renders in the next version?

There's no plan that I'm aware of to do other changes related to this. The main goal is still to yeet the non physical ambient light but have an easy way to still emulate an ambient light with less overall shader code to maintain.

Would it make sense to rename the EnvironmentMapLight struct to AmbientLight?

No, because the EnvironmentMapLight is still using an environment map, it can just be used with a small map to emulate an ambient light, but it's more advanced than just a flat ambient light.

[mockersf]

is there an explanation why some scenes are darker (https://pixel-eagle.com/project/b25a040a-a980-4602-b90c-d480ab84076d/run/9021/compare/9009?screenshot=3D+Rendering/ssao.png or https://pixel-eagle.com/project/b25a040a-a980-4602-b90c-d480ab84076d/run/9021/compare/9009?screenshot=3D+Rendering/pbr.png) and some are lighter (https://pixel-eagle.com/project/b25a040a-a980-4602-b90c-d480ab84076d/run/9021/compare/9009?screenshot=3D+Rendering/spotlight.png or https://pixel-eagle.com/project/b25a040a-a980-4602-b90c-d480ab84076d/run/9021/compare/9009?screenshot=3D+Rendering/ssao.png)?

on https://pixel-eagle.com/project/b25a040a-a980-4602-b90c-d480ab84076d/run/9021/compare/9009?screenshot=3D+Rendering/anisotropy.png some details completely disappear. for example the dark bar between the light filaments that should be there when looking at https://github.com/KhronosGroup/glTF-Sample-Assets/tree/main/Models/AnisotropyBarnLamp

[SparkyPotato]

is there an explanation why some scenes are darker (https://pixel-eagle.com/project/b25a040a-a980-4602-b90c-d480ab84076d/run/9021/compare/9009?screenshot=3D+Rendering/ssao.png or https://pixel-eagle.com/project/b25a040a-a980-4602-b90c-d480ab84076d/run/9021/compare/9009?screenshot=3D+Rendering/pbr.png) and some are lighter (https://pixel-eagle.com/project/b25a040a-a980-4602-b90c-d480ab84076d/run/9021/compare/9009?screenshot=3D+Rendering/spotlight.png or https://pixel-eagle.com/project/b25a040a-a980-4602-b90c-d480ab84076d/run/9021/compare/9009?screenshot=3D+Rendering/ssao.png)?

on https://pixel-eagle.com/project/b25a040a-a980-4602-b90c-d480ab84076d/run/9021/compare/9009?screenshot=3D+Rendering/anisotropy.png some details completely disappear. for example the dark bar between the light filaments that should be there when looking at https://github.com/KhronosGroup/glTF-Sample-Assets/tree/main/Models/AnisotropyBarnLamp

Certain scenes are darker since they had both an ambient light and an environment map, but now the ambient light is overridden by the environment map. For scenes that are lighter, this is because the ambient light had no effect on specular reflections, whereas the environment map does.

Example code shouldn't use deprecated things, they need to be updated to use the new component.

Examples that modified the ambient light have been updated to use environment map lights instead, but I haven't modified any that relied on the default resource. That change should probably be done when we remove AmbientLight in the next version.

[rparrett]

I feel like we should make some effort to preserve the scenes of our users. If the new light is brighter because it is more physically correct then it seems like the default intensity should be lower. Or we at least need to tell users what happened and how to fix their scenes.

Just linking for reference, the PR that set the current default ambient intensity: 11868.

[mockersf]

Examples that modified the ambient light have been updated to use environment map lights instead

There are still examples that use ambient light, they should be fixed now

[mockersf]

I also think that if we deprecate AmbientLight, it should be not kept as a resource initialised by default.

[SparkyPotato]

I also think that if we deprecate AmbientLight, it should be not kept as a resource initialised by default.

This makes sense, but I'm not sure how to replace that with a default environment map, because the new constructors require an &mut Assets<Image> to create the 1x1 cubemaps.

While I do think that having no lights by default is a good idea, as it forces users to be deliberate with their lighting setup, it does hurt quick prototyping.

[hukasu]

can't you create a default image on startup to use for the default environment map?

[hukasu]

bevy already has this 1x1 default images

bevy/crates/bevy_render/src/texture/mod.rs

Lines 24 to 30 in 3b9e2e6

	/// A handle to a 1 x 1 transparent white image.
	///
	/// Like [`Handle<Image>::default`], this is a handle to a fallback image asset.
	/// While that handle points to an opaque white 1 x 1 image, this handle points to a transparent 1 x 1 white image.
	// Number randomly selected by fair WolframAlpha query. Totally arbitrary.
	pub const TRANSPARENT_IMAGE_HANDLE: Handle<Image> =
	weak_handle!("d18ad97e-a322-4981-9505-44c59a4b5e46");

other locations with images created on setup

bevy/crates/bevy_core_pipeline/src/post_process/mod.rs

Lines 56 to 61 in 3b9e2e6

	/// The handle to the default chromatic aberration lookup texture.
	///
	/// This is just a 3x1 image consisting of one red pixel, one green pixel, and
	/// one blue pixel, in that order.
	const DEFAULT_CHROMATIC_ABERRATION_LUT_HANDLE: Handle<Image> =
	weak_handle!("dc3e3307-40a1-49bb-be6d-e0634e8836b2");

bevy/crates/bevy_core_pipeline/src/smaa/mod.rs

Lines 86 to 90 in 3b9e2e6

	const SMAA_AREA_LUT_TEXTURE_HANDLE: Handle<Image> =
	weak_handle!("569c4d67-c7fa-4958-b1af-0836023603c0");
	/// The handle of the search LUT, a KTX2 format texture that SMAA uses internally.
	const SMAA_SEARCH_LUT_TEXTURE_HANDLE: Handle<Image> =
	weak_handle!("43b97515-252e-4c8a-b9af-f2fc528a1c27");

[mockersf]

yup you can static embed small assets, a 1x1 cubemap shouldn't use a lot of memory

[SparkyPotato]

I've swapped out the default AmbientLight resource to a required component on Camera3d that is added at runtime only if the user enables PbrPlugin::default_environment_map_light. I've also reduced the default intensity so that scenes are a similar brightness to before.

This should mean that users will only be using the AmbientLight fallback if they've explicitly added or changed the resource, in which case they'll also get the deprecated warning. On that note, do we really want to keep AmbientLight around for a version or should it just be removed altogether?

[alice-i-cecile]

On that note, do we really want to keep AmbientLight around for a version or should it just be removed altogether?

I think that the migration will be easier if we do a deprecation notice. This will point the users to the right spot.

[inodentry]

I missed the original discussion and PR, but I'd like to ask something about the whole idea of removing ambient light.

Isn't the whole point of ambient light that it is extremely cheap? AFAIK, it's just another term added to the lighting equations computed in the shader, no? Just some extra arithmetic.

Whereas environment map lighting requires texture sampling operations (much slower operation for the GPU) in addition to computation.

I thought the reason why ambient light exists is to have an ultra-cheap fallback for very low-end GPUs. That alone makes it a useful feature. Yes, it looks ugly and is not physically correct, but that's kinda the point.

Using environment map lighting looks better, yes, but also costs performance, and that kinda defeats the point.

Emulating the look of ambient light (ugly) with environment maps (slower perf) just sounds like the worst of both worlds.

[IceSentry]

If using an envmap is already too slow for you, then you should probably not be using bevy's default PBR shader and should be using a custom material that is more appropriate for that use case. And if bevy's PBR is good enough, then the envmap is likely not the bottleneck and it's more accurate. This PR also has the nice side effect of making scenes with only an envmap faster.