-
-
Notifications
You must be signed in to change notification settings - Fork 3.7k
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
Exposure settings #8407
Exposure settings #8407
Conversation
Adding to the 0.11 milestone as this change will be badly breaking and should be shipped sooner rather than later. |
aperture_f_stops: 4.0, | ||
shutter_speed_s: 1.0 / 250.0, | ||
sensitivity_iso: 100.0, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'd suggest ditching these individual settings and just passing the ev100 value directly. There's lots of sources online that provide tables of ev100 values, for instance this one from wikipedia
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Also, might be worth providing constants with a couple defaults. For instance, EXPOSURE_DIRECT_SUNLIGHT
, EXPOSURE_INDOOR_LIGHTING
, EXPOSURE_MOONLIGHT
, etc.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Agreed! You could also provide an Ev100::from_camera(aperture_f_stops, shutter_speed_s, etc...)
function.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, unless we had other effects of these parameters they should really be collapsed down into one.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good idea @JMS55 - I was thinking that it would be good to expose (HA!!!) the functionality to provide the parameters for those who it is more familiar. Was first thinking of an enum, but I agree the constructor approach could be nicer.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@alice-i-cecile hmm... now that you mention it... the filament docs did talk about how the different parameters affect depth of field (or focal depth - the aperture setting I think, I'm not familiar with cameras beyond physics stuff) and motion blur (shutter speed).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That's correct :) At the same time, I don't think we want those baked into our rendering engine by default: motion blur and focal depth are very specific effects that should be used artistically.
We're not simulating a real camera IMO, so we should just expose Ev100 and then provide independent control for things like motion blur and focal depth when we have them.
Skyboxes Edit: Environment lights seem to be handled correctly, but the output from skyboxes still needs to be scaled by |
The filament docs said that they pre-expose IBL sources too, as an alternative to just applying exposure to accumulated light from all sources. They do the pre-exposure for the sake of being able to use f16. I may switch over to trying to do individual source pre-exposure for that reason but I wanted to get the whole thing working first. @fintelia do you feel like trying out my branch to see if it matches your expectations? To me with the default values that Filament suggests, everything is very dark. I tried to find suggested values for cameras via random searches but they also seemed very dim. I feel I need to read through everything and probably compare to a reference scene + rendered in something else that is reliable. |
@@ -207,6 +207,7 @@ fn setup( | |||
// directional 'sun' light | |||
commands.spawn(DirectionalLightBundle { | |||
directional_light: DirectionalLight { | |||
illuminance: 1000.0, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The sun has an illuminance of ~100,000 lux. Though, having that bright a directional light that bright is of course going to overpower all the other lights in the scene (even stuff in shadows will mostly be lit by bounce lighting and light from the sky)
@@ -254,7 +254,7 @@ fn pbr( | |||
|
|||
// Total light | |||
output_color = vec4<f32>( | |||
direct_light + indirect_light + emissive_light, | |||
view.exposure * (direct_light + indirect_light + emissive_light), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This assumes that indirect light is already in photometric units. There may need to be a scale factor to undo any pre-exposure that's baked into the contents of the cubemaps.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah. There was talk about an "intensity" field for environment map lighting. I decided to leave it out in my original PR because I was worried it would be abused. Maybe it's time for that now.
@superdump rebased, converted ExposureSettings to hold EV100 directly, and did some misc work superdump#32. Remaining TODO:
|
I'd suggest against changing the default intensities for point/spot lights. An 800 lumen (i.e., 60 W incandescent brightness) light is more likely to be what a user wants compared to a 3.6 million lumen one. It means that, say, a flashlight will be completely overpowered by the light of the sun, but that's true in the real world too! Rather, the main suggested mitigation should be to specify exposure settings corresponding to an indoor or night scene. Then making sure the scale of the scene is accurate in meters. And only once those are both calibrated should you start increasing the number/brightness of lights. |
I can’t approve my own PR. But, as it is my PR, it needs @robtfm ’s approval and we can merge it, or two community reviews. |
We still need to fix all the examples... Changelog/migration guide also needs to mention the other newly added stuff like PhysicalCameraParameters and skybox/envmaplight brightness controls. |
@GitGhillie Fixing the examples would be a huge help :). It's really the main blocker of this PR. @fintelia suggested what we should do here: #8407 (comment). We should set an exposure that makes sense for the scene based on real-world values, and then tweak the light values to make sense. Also yeah, reevaluating the default exposure/light intensities probably makes sense. This PR itself is out of date, but I've just rebased it. Please use this branch as a base for your changes: https://github.com/JMS55/bevy/tree/exposure_jms |
I did some investigation of Blender's handling of light intensity and I'm somewhat skeptical that their brightness levels are even meaningful... Apparently, Blender uses a hard-coded conversion factor of 683 lumens/watt when exporting gltf (applied here). While the Blender documentation provides a table of common wattage values with conversion ratio varying from 227 lumens/watt to 556 lumens/watt. The term for this conversion factor seems to be luminous efficacy. And from what I can find online, the 683 lumens/watt number seems to be a theoretical upper bound and values as low as 15 lumens/watt apply to some light sources. Weirdly, I wasn't able to find any reference to how Blender determines how much of a light source's power is visible light. That feels like a rather relevant factor given that the whole reason there isn't only one luminous efficacy value is because different kinds of light have differently shaped spectrums |
If I change the default exposure from Having a default exposure of 7 instead of 12 also avoids having intensity/illuminance values in the 10000s in the examples. Here are some comparisons with an exposure of 7, with the Blender exposure and other settings at the default: Directional light 1W/m^2 (also Blender default. I assume they use 1W/m^2 as a default because the default exposure is for indoor scenes, and 1000W/m^2 (strength of the sun according to the Blender docs) would blow out the scene). @JMS55 thank you! If people agree with changing the default exposure I can start adjusting the examples |
@GitGhillie sounds fine to me. |
Ran into an issue while adjusting the transmission example: If I leave everything as it was and adjust the scene using the new Working on this branch btw: JMS55#16 |
Also wondering what the difference is between the |
Edit: It wasn't that, what was actually happening was that we were using an already exposure adjusted image (the background) as the input to another exposure adjustment. |
After talking to @DGriffin91 on discord, it sounds like we should keep ColorGrading exposure. We might also want to change it to take the new ExposureSettings. |
The exposure from ColorGrading is an exposure value offset that is meant to be subtracted from the camera's exposure, so I don't think re-using Exposure settings makes sense for it |
Fixed the underexposed transmission on GitGhillie#1 (It's now three staggered PRs from this one 😆 🚂🚋🚋🚋) |
Alright folks, all examples adjusted (I count 59 examples with lights). It's not perfect but maybe a good time to get some feedback. Here are some notes:
Anyways, this exercise has taught me a lot about Bevy. Don't be afraid to give feedback that would mean I have to go through everything again, I can probably do it a lot quicker the second time around :) |
On it! |
Fixed the atmospheric fog example: GitGhillie#2 |
Adopted! 🎉 Please review #11347 |
Merging the adopted PR now! |
Rebased and finished version of #8407. Huge thanks to @GitGhillie for adjusting all the examples, and the many other people who helped write this PR (@superdump , @coreh , among others) :) Fixes #8369 --- ## Changelog - Added a `brightness` control to `Skybox`. - Added an `intensity` control to `EnvironmentMapLight`. - Added `ExposureSettings` and `PhysicalCameraParameters` for controlling exposure of 3D cameras. - Removed the baked-in `DirectionalLight` exposure Bevy previously hardcoded internally. ## Migration Guide - If using a `Skybox` or `EnvironmentMapLight`, use the new `brightness` and `intensity` controls to adjust their strength. - All 3D scene will now have different apparent brightnesses due to Bevy implementing proper exposure controls. You will have to adjust the intensity of your lights and/or your camera exposure via the new `ExposureSettings` component to compensate. --------- Co-authored-by: Robert Swain <[email protected]> Co-authored-by: GitGhillie <[email protected]> Co-authored-by: Marco Buono <[email protected]> Co-authored-by: vero <[email protected]> Co-authored-by: atlas dostal <[email protected]>
Objective
Solution
Changelog
Migration Guide
ExposureSettings
component on anCamera
entity will be used to configure exposure for PBR rendering. Previously only directional lights were using hard-coded exposure, but now all light has exposure applied. This will mean that all light sources other than directional lights will be significantly darker. Adjust the exposure settings and light intensities as necessary.