Add support for physical light units #4257
Comments
Calinou
changed the title
Isn't FOV aspect still needed for a physical camera? The camera needs to know in which direction FOV should be stretched as the aspect ratio changes. While defaulting to Hor+ (like Camera3D currently does) is a good thing, games in portrait mode will generally want to use Vert- FOV scaling.
I think temperature could be supported as a multiplier of the existing light color (which is white by default). This temperature property would be hidden when physical light units are disabled. There should be a formula out there for converting a temperature value in Kelvin to a color value. |
|
One tiny implementation detail, suggestion: HDR is often done with In Ogre-Next we simply avoid that problem by dividing by 1024 when doing most calculations, and multiplying by 1024 when the true physical units are needed (i.e. that's usually when doing non-linear math like log / exp operations). Increasing precision to Of course, this also means shaders that want to store light info after the multiplication must be |
Godot has a built-in debanding filter which works well in my experience. It could be enabled automatically when physical light units are used. |
Once you're approaching And after surpassing A debanding filter won't be the solution. |
Huh, I never even considered setting max and min values to control the auto exposure. To better control how the auto exposure result looks I really think an EC curve should be part of your proposal. Thats also what most implementations I have seen do: Use a histogram to produce a mostly neutral image and then apply an exposure compensation curve (fed with the original frame lumination) to gently nudge it back towards the original illumination. This can be very useful to make sure that darker areas still look dark-ish, while actually being visible for players.
Are you sure this should be an extra property? imo this should simply replace the current intensity value.
Why exactly would we want to make physical light units hideable? There is really no benefit to the current system when compared to physical light units. Even without fully understanding what the physical units mean artists could just play around with the value until they get what they are looking for, which is the same workflow they are currently using. |
|
@Ansraer you need min and max for both numerical precision reasons and because both eyes and camera sensors have limits. Regarding comparison to the current system. You are wrong regarding not being advantages. If light is multiplied by 1, you know the maximum amount of light is white so it jusy modulates the texture color. This is very useful for artistic purposes in many art styles. Also on GLES3 PLU will most likely not be supported. Agree about using histogram but thats an implememtation detail. |
|
@darksylinc That is interesting, thanks! I wonder how it compares to Filamemts approach of multiplying the lights by 1/exposure. |
true enough. I was more focused on exposing them to the user. But I suppose it can't hurt.
Afaik the color temperature is only used to determine the chromaticity (not intensity) of the light. So I expected it to be a button next to the color field, that simply opens an alternative color picker. Totally awesome mockup that was definitely NOT created in paint
|
You will want those min/max values. You really do. Unless the GI is near perfect in terms of accuracy, you'll quickly run into bursts of exposure spikes (because areas under shadow / indoor are greatly different from fully lit areas). Additionally it creates the problem that if you look at a place that is very dark and occupies most of the screen; the auto exposure will try to compensate and blacks become white. Artists will ask "why is this black object white?". Answer: because the max exposure is too high. This happens in real life too; our brains know not to adapt the eye if we're still staying outside but trying to look at the inside of an open door. You'd have to stare to that for a long time before the eye decides to adapt despite being outdoors. But this problem happens a lot with a camera which is why you have to tap in the bright parts to tell the camera how to adjust the exposure (if it's a consumer-friendly point and shoot camera), or use pro mode where the camera will stick to ISO values which contain min and max exposures. |
I'm not sure what part of this to correct first... First off, it doesn't make any sense to measure the intensity of a point light source (area/spot/omni) in illuminance. Why? Because illuminance is measured off of a surface the light is hitting, which means that unless you standardize how far that surface is from the light, it's a meaningless measurement. The reason illuminance works for a directional light is because directional lights have no attenuation, so all surfaces receive the same illuminance value regardless of their position. Second, lumens are not a measurement of illuminance, they're a measure of luminance (technically "luminous flux", meaning total perceived power of a light). Third, it doesn't make sense to arbitrarily pick lumens over, say, candelas - and in fact, you can easily convert between the two. Here's how I would refactor the whole thing: Directional lights Spot or omni lights Area light Emissives Light meter There's probably stuff I'm forgetting, but that's a good start. |
reduz
changed the title
I would strongly argue temperature colour editing being a must-have feature. It easily ensures your lights (even in non-realistisc art styles!) look correct. I missed this feature so much, I made an addon a couple months back: https://github.com/HaSa1002/godot-light-tools. |
|
All the points brought up in #723 still apply, but it seems some were skipped over. Including points about importing lights from blender. My notes here are long, so I'll break them up into separate camera and light sections. To have an effective physical photography system, we should have enough parameters to correspond to real lights and cameras that filmmakers, photographers, and equipment use, plus the ability to save, import, and export presets for lights and cameras. You don't have to define the presets now, just have the ability, and others can put them in. CamerasCamera settings:
Sensor preset examples:
+A cool feature in digital cameras is zebra mode. Turning this on points out areas in the viewport where the highlights are over-exposed. The hot areas are covered in a moving zebra stripe. Think of a cinematographer using it how a game dev would use visual collision debugging. There might be problems you don't notice during development, so the computer can point out the issues that might become more prominent on other's systems. This would be very useful when creating cut scenes, or setting up environment lighting and noticing lights gets too hot in a certain area. |
|
The zebra is a cool idea. I think an improvement on that (or alternative) is false color, which will show you over-exposure, under-exposure, middle-grey (if exposing with a colorchecker or gray patch visible), and, ideally, user-definable zones.
The issue with either zebra or false color is that it will depend on the tonemapper used. The linear render buffer is going to have a larger dynamic range than the output display, so the min/max values for all this stuff is a per-display thing. I am not familiar with how color management occurs in Godot. The common flow for a DP or a lighting artist nowadays is to use a Waveform (luma or RGB Parade) and a false color LUT to eyeball for any obvious issues. This all probably all a diversion from physical lights, though, since it's tied to final pixel values rather than scene-referred (light) energy. |
LightingExamples of light presets:
Discussion: Lux and illuminance should not be used for non-directional lights as they measure light received on a surface, baking in distance and fall off. Only lumens and candelas should be used as they measure light emitted. There is a difference between the two, but can probably be ignored... (expand spoiler if you care)There is a difference between the two when it comes to spotlights and lasers, as lumens measures the omnidirectional output of the bulb, while candelas measures the density of light output, which may be higher when focused in a single direction like with a spotlight or laser. In such cases the ratio of candelas to lumens will be higher than in an open bulb, omni directional configuration. This difference can probably be ignored for our purposes.Filmmakers are concerned with these (excluding things we can ignore like CRI and wattage):
Here is a typical filmmaking light bulb for a 1k Arri lite or mole richardson. It lists 28,000 lumens, and 3200k color temp. Virtually every bulb you can buy at the store, even for home use, lists lumens and most provide color temp. These should be the standard setting on physical lights, depending on factors.
Both should be provided. I would default to lumens, with a one click button to change units, or provide a project setting where units can be defined for lights and other measurements like other systems do. Physical lights will be used by people trained in filmmaking and photography, DPs, and cinematographers who buy light bulbs or rent light kits based in part on the lumen output printed on the package. Candelas aren't given. Some light meters can measure lumen and candela output, however most DPs and photographers use them only for camera settings.
I don't disagree with the rest, and have provided some points of clarification.
When we measure the light on the ground, the distance and fall off have already been baked in. In the spoiler below I consider not using lux, but as Polyrhythm stated, it makes sense here. The unit of illuminance is lux, so both aren't necessary. Lux is lumen/sq meter of the surface. The brightest sunlight might be 120,000 lux, an overcast at mid day 15,000 lux, sunrise 40 lux. The physically correct alternative... (spoiler)The more physically correct alternative is to render DLs as the area lights (sky) or omni lights (stars) that they are, and provide their values in lumens and candela per sq meter that are emitted from them. The surface of the sun is 2 billion nits (units discussed below in area), a partly sunny sky 30,000 nits, and a clear sky 3,000 nits. However then we'd have to calculate fall off from 93M miles away, and it's probably not worth the extra math in a real time rendering environment.ref p26, 37
Clarification: the unit of luminous flux is lumens. So only lumens and candelas are needed.
Clarification: So perhaps you could provide a unit toggle, but the numbers won't change. That might be confusing for users. On the other hand if you don't provide lumens and candela derived units, it might be confusing why I can set omnis in lumens, DLs in lux, and areas only in candelas or vica versa.
Luminance measures the emitting surface. A spot meter is used when you point the camera at a light source or someone's face and read out the amount of light hitting the sensor (which bakes in attentuation).
Illuminance is the receiving surface, measured when you put a light meter on someone's face and read how much light is hitting the surface, so you could use a meter that follows the mouse where you measure light based on the surface your cursor is pointing at. Or we could use zebras as I mentioned or false color as @Polyrhythm mentioned, as these could serve as a full-screen meters and provide the visual debugging that every major DCC renderer and video editing suite has. It is a bit of scope creep, but some of these could be considered or pushed to a post processing proposal:
|
I just wanna throw in that this feature should not only directed at those people. As Godot is heavily used by indies which either do game dev as hobby or have some education in one of the game dev fields (if any [see hobby]), this statement simply holds not for all the people that are going to use this feature. I get that you want to have great control but Godot is not an entreprise product that requires years of training and experience to get going. I don't have that education, yet I regularly use light units in other game engines to create working lighting situations. Please keep this in mind while proposing improvements. I feel like this either needs custom controls or some sort of simplified setting mode. |
|
@HaSa1002 Don't misunderstand. The tools should be designed to professional standards, and be physically correct. No one has suggested you should not be able to use them without training or that they should be difficult to use. When the average person buys a light bulb they likely never look at the lumens rating, nor even the color temperature, but they are there for those who know what they mean. And nearly every camera, even on our phones, have not only auto mode but also manual settings for ISO, white balance and shutter speed. Yet no one suggests indie filmmakers can't use basic light bulbs and phones for filmmaking or require special training. Yet if we were making a camera, it would be a disservice to both amateurs and professionals to make one without manual settings, or worse, with wrong or made up, non industry standard units because we didn't know what we were doing. Edit: @HaSa1002 The point you quoted out of context was specifically about using lumens vs candelas as primary units. That wasn't expected to be relevant to those without experience using them. |
I feel I should mention: for the first iteration of physically based light it doesn't really matter how much is exposed to users or in what way, easy or difficult. The key is to first make it as physically correct as possible under the hood, because that's what will be most difficult to change later on once users become accustomed to the implementation and certain behaviors become expected. If that's done first, then future Godot releases can concentrate on improving how that functionality is exposed to users in a comprehensive and friendly way, but the functionality itself could remain consistent across versions. |
|
Can it be named PhysicalCameraLens, PracticalCameraLens? |
|
Why is lens in the name at all? Many of the attributes specified such as ISO, exposure mode, shutter speed, and sensor dimensions I suggested have nothing to do with lenses. They are part of the sensor, shutter, physical attributes, or electronics. Camera attributes, settings or properties maybe. |
Describe the project you are working on
Godot
Describe the problem or limitation you are having in your project
The new renderer in Godot 4 is for the most part complete (save pending reorganization) but one issue that misses to be tackled is physical light unit support.
The main issue with it is that it has to be implemented in a way that also allows Godot users to not use those if they don't desire, as many games do not really care about these, nor are looking towards photorealistic artistic styles.
Describe the feature / enhancement and how it helps to overcome the problem or limitation
The idea is relatively simple, right now Godot4 has the CameraEffects class. This class will be renamed to CameraLens.
This will be an abstract class that will allow for different implementations (physical or not), but also simply disabling physical light units altogether.
Describe how your proposal will work, with code, pseudo-code, mock-ups, and/or diagrams
CameraEffects will be renamed to CameraLens. This will be an abstract class that will be inherited by two classes:
It will be possible to set this resource to:
CameraLensPhysical
This version of CameraLens will contain the following properties:
CameraLensPractical
This version of CameraLens will contain the following properties:
Lights
DirectionalLight will have an extra property:
Omni/Spot Lights will have an extra property:
Temperature might be supported, would be interesting to ask what you think.
Materials, Skybox, Etc.
Currently a single (energy) multiplier is used. I believe we should rename energy to:
energy/iso (in ev100, will be hidden in physical units are not enabled)
energy/multiplier (as just a multiplier)
If this enhancement will not be used often, can it be worked around with a few lines of script?
N/A
Is there a reason why this should be core and not an add-on in the asset library?
N/A
The text was updated successfully, but these errors were encountered: