Open BeRo1985 opened 9 months ago
Cc @will-ca @donmccurdy
TL;DR: I'm pretty sure the current implemention is correct. The 0.0083
conversion factor sounds like it includes infrared, and is meant for estimating heat flux for physical objects left in the sun, not for rendering.
The current formulae are the result of an extensive discussion at https://github.com/KhronosGroup/glTF/pull/2214, involved experiments which explicitly confirmed how Blender and other renderers work (https://github.com/KhronosGroup/glTF/pull/2214#issuecomment-1278292085), are consistent with how other renderers work (https://github.com/KhronosGroup/glTF/pull/2214#issuecomment-1276762979), produce results that are consistent with how other renderers look (considering the spec, with appropriate exposure) (https://github.com/KhronosGroup/glTF-Blender-IO/pull/1760), and are immediately derivable from the SI definitions of the candela and the lumen.
I can PR a fix if the current implementation isn't right, but I'm afraid I'm going to have to ask for further explanation why, with consideration of the information and links above/below, if that is the case.
The feedback provided is comprehensive and illustrates a well-considered approach to the implementation of light intensity conversion within the GLTF exporter. However, I believe there is a misunderstanding regarding the application of these principles specifically to the representation of sunlight intensity in physically based rendering (PBR) environments, particularly in the context of the GLTF KHR_lights_punctual
extension specification, which clearly states that directional lights use illuminance in lux (lm/m2).
The conversion factor of 683 lumens per watt is indeed rooted in the definition of the candela and lumen, based on the most efficient wavelength of light perceivable by the human eye. While this conversion is scientifically valid, its direct application to model sunlight intensity in a PBR scene raises concerns. Sunlight, being a natural light source, has a broad spectrum that includes not only visible light but also infrared and ultraviolet wavelengths. The maximum perceived intensity of sunlight on Earth's surface is widely recognized as around 120,000 lux. This figure is not arbitrary but is derived from empirical measurements that consider the full spectrum of sunlight, including its distribution and the human eye's response to it.
Physically based rendering strives for realism, attempting to mimic real-world materials and lighting conditions as closely as possible. The KHR_lights_punctual
extension specifies that directional lights, such as sunlight, use illuminance in lux (lm/m^2). A value of 683,000 lux for sunlight significantly exceeds the natural world's observed maximum values, which can distort the realism PBR aims to achieve. By adhering strictly to the 683 lumens per watt conversion without considering the specific nature of sunlight, we risk overestimating sunlight's intensity in our virtual environments, leading to non-physically plausible results.
While the use of 683 lumens per watt for converting watts to lumens under the most efficient wavelength is technically correct, it disregards the practical aspect of how sunlight is experienced and measured in real-world conditions. For the purpose of rendering environments that are true to life, it is essential to consider real-world measurements and empirical data that provide a more accurate representation of sunlight. This includes recognizing that the maximum sunlight intensity does not exceed 120,000 lux under clear sky conditions at the Earth's surface.
In light of the above points, I propose revisiting the application of the 683 lumens per watt conversion factor specifically for sunlight in the GLTF exporter. Adjusting this implementation to reflect a maximum sunlight intensity of around 120,000 lux would align more closely with real-world observations and empirical data. This adjustment would not only adhere to the physical correctness sought in PBR workflows but also ensure consistency and realism in the representation of sunlight across PBR environments.
For further substantiation, it's pertinent to consider authoritative resources and expert opinions. Resources such as the Filament Rendering Engine Documentation and the Frostbite PBR Guide provide insights into realistic lighting models and their application in PBR, supporting a more nuanced approach to modeling sunlight intensity.
Additionally, engaging with experts like Romain Guy, a developer of the Filament rendering engine and a recognized authority in the field of realistic lighting models (@romainguy on GitHub), could yield invaluable insights. His extensive experience and active participation in the PBR community position him as an invaluable resource for exploring the standards of lighting intensity in PBR environments.
While I acknowledge the rationale behind the current implementation, I believe that adjusting the sunlight intensity to reflect a maximum of 120,000 lux specifically for gaming applications in Physically Based Rendering (PBR) contexts would offer a more accurate and realistic modeling of natural sunlight. This adjustment aligns with the GLTF KHR_lights_punctual
specification and empirical real-world data, thereby enhancing the physical realism that PBR workflows strive to achieve in games. Engaging with authoritative resources and expert opinions, such as those from the Filament Rendering Engine Documentation and insights from Romain Guy, could further substantiate this position, making a compelling case for reconsideration.
Moreover, adopting a more physically accurate sunlight intensity could significantly enhance the immersive quality of video games and game engines that utilize GLTF-based assets in their content pipelines, similar to the one I'm currently developing. This approach not only improves the aesthetics and realism of the games' graphics but also ensures consistency across different application cases, including games.
Edit:
I have now also found https://www.researchgate.net/publication/347362859_A_conversion_guide_solar_irradiance_and_lux_illuminance from December 2020 where the conclusion of this confirms my value of 120000 lux, where in the introduction it says: Easy-to-find Internet sources contain conflicting and widely varying values ranging from 688449 to 21000 lx for 1000 W/m2 (1 Sun) of solar irradiance.
1. Misapplication of Conversion Factor for Sunlight:
[…] The maximum perceived intensity of sunlight on Earth's surface is widely recognized as around 120,000 lux. […]
2. Physical Realism in PBR:
[…] A value of 683,000 lux for sunlight significantly exceeds the natural world's observed maximum values, which can distort the realism PBR aims to achieve. […]
Right. See my previous comment:
For rendering, we assume (and measured, by sampling resulting pixel values) that the energy levels used by Blender include only visible wavelengths. […]
I guess you're probably gonna want to specify a much lower emitted power than 1000W in Blender, then, to realistically account for only the visible wavelengths in sunlight and get the exported lux to an appropriate 120,000.
The radiometric→photometric conversion is a much more complicated process physically than it is possible to model using a simple coefficient. Currently the exporter is based on correct/standard physics and produces light intensities that are proportioned correctly in spec-compliant renderers, to my knowledge.
You can take it up with/submit a patch to show lumens in Blender's UI to the Blender Foundation if you don't want work out the appropriate wattages yourself. But the exporter shouldn't just be changed to use an arbitrary new algorithm if it's currently behaving correctly according to physics/the spec/the ecosystem.
[…] By adhering strictly to the 683 lumens per watt conversion without considering the specific nature of sunlight, we risk overestimating sunlight's intensity in our virtual environments, leading to non-physically plausible results. […]
[…] it disregards the practical aspect of how sunlight is experienced and measured in real-world conditions. […] This includes recognizing that the maximum sunlight intensity does not exceed 120,000 lux under clear sky conditions at the Earth's surface.
4. Adjustment for Realism in PBR Workflows:
In light of the above points, I propose revisiting the application of the 683 lumens per watt conversion factor specifically for sunlight in the GLTF exporter. Adjusting this implementation to reflect a maximum sunlight intensity of around 120,000 lux would align more closely with real-world observations and empirical data. This adjustment would not only adhere to the physical correctness sought in PBR workflows but also ensure consistency and realism in the representation of sunlight across PBR environments.
While I acknowledge the rationale behind the current implementation, I believe that adjusting the sunlight intensity to reflect a maximum of 120,000 lux specifically for gaming applications in Physically Based Rendering (PBR) contexts would offer a more accurate and realistic modeling of natural sunlight.
Note that the words "sun" and "sunlight" do not appear at any point in the KHR_lights_punctual
specification. Instead, what the specification defines is directional lights. It doesn't matter if those lights represent the sun, a large lamp placed far away, Rigel, a big laser, or an array of candles inside paraboloidal reflectors.
Modifying the importer/exporter to specifically accomodate sunlight would cause it to violate the spec (and also be inconsistent with Blender/Cycles/EEVEE's behavior, plus every other renderer and importer).
5. Expert Consultation:
For further substantiation, it's pertinent to consider authoritative resources and expert opinions. Resources such as the Filament Rendering Engine Documentation […]
Additionally, engaging with experts like Romain Guy, a developer of the Filament rendering engine […]
I have consulted the document in question. It is one of the places we got the 683
coefficient from.
Unless you are actually intending for Romain Guy to address this issue personally, in an exporter to which AFAIK he has no prior association, I don't see how any part of the rest of this point is relevant to this specific issue and feature, except for in a superficial and stochastic way.
@julienduroure Unless additional information comes to light, I don't think there's a bug here.
I have now written to an astrophysicist (an old acquaintance of mine) and I hope that he will write something here soon. And Romain Guy should already or soon know about this issue, as I wrote to him via Twitter/X.
And as a suggestion on my part, what about another lighting mode or a checkbox called "Directional sunlight scale" or something like that? Because then it would only be optional and it wouldn't break anything else.
In the first place, are any facts about the real physical sun relevant? Correctness needs to be based on equivalence of behavior, not equations between names. The fact there is a thing in Blender called a "sun" does not immediately mean it behaves the same as the thing in the real world called a "sun".
In the first place, are any facts about the real physical sun relevant? Correctness needs to be based on equivalence of behavior, not equations between names. The fact there is a thing in Blender called a "sun" does not immediately mean it behaves the same as the thing in the real world called a "sun".
Hmm? But the essence of Physically Based Rendering (PBR) should be to closely simulate real-world light behavior and material interaction, using real values where possible for greater realism and consistency in digital visuals, in my point of view.
Hmm? But the essence of Physically Based Rendering (PBR) should be to closely simulate real-world light behavior […]
Yes, light. 683,000
lux is indeed too bright for a physically based model of our sun. But you got there by defining a 1,000W/m² visible light flux for the sun, which, as I've tried to explain in both my comments, is also not correct and too high because real-world insolation numbers include quantities like infrared and other things that are decidedly not visible light.
The fact there is a thing in Blender called a "sun" does not immediately mean it behaves the same as the thing in the real world called a "sun".
I.E. Our own real-world "sun" is an approximate blackbody radiator filtered through a nitrogen-oxygen-water atmosphere, where less than half the total energy reaching the surface is even visible and even less gets anywhere near the theoretical 683 lm/W peak luminous efficiency at 555nm.
Blender's "sun" is a theoretically perfect radiator where 100% of all its energy is concentrated in the visible spectrum, and furthermore even deep blue and red wavelengths are treated like they have the maximum cone cell sensitivity of green light.
The physics are (mostly) the same, but the object itself is different— Like how a "60W" incandescent lightbulb is different from a "60W" fluorescent light, which is different from a "60W" LED array, which is different from "60W" of idealized point light radiation as you might have in Blender.
In order to have equivalence of behaviour, you need to convert from the two different things you're measuring— So, theoretically, as I said in my first comment, divide the integral of the infrared-inclusive solar spectrum by the integral of that solar spectrum multiplied by human luminous efficiency curves, to calculate how much of the "1,000W" that you're using for your sun should actually be visible— Or, since you know your target lumens and the conversion factor, just do 120,000lm/(683lm/W)≈176W
to figure it out.
TL;DR: 1,000W is wrong because it includes a bunch of radiation that isn't light. So of course starting with the wrong wattage also gives you the wrong lux. For rendering you want to include only the part of "sunlight" that's actually visible light, weighted for luminous efficiency, which should be around 176W
or so. There's no meaningful/physically consistent way to compensate for that in the exporter, because different suns/planets/light sources/weather conditions/latitudes could change the spectral composition of "sunlight" too.
The Blender documentation clearly says to use 1000 W/m^2 to model the strength of the sun on a clear day.
The Blender documentation clearly says to use 1000 W/m^2 to model the strength of the sun on a clear day.
Yes. We discussed that page of the documentation in the first discussion I linked from my first reply, as well as in an issue linked to the Blender Foundation issue tracker from there:
That page of the documentation also contradicts itself repeatedly. For example, it says a 2500lm light source should be 4.5W, and yet a 5000lm light source should be 22W.
Thanks for linking that PR. This line feels like it cuts to the core of the issue:
when Blender decided to move past their own unitless setup they just slapped a "Watts" label on everything (and that happened to work out with mostly sane exposures),
Though I will push back on whether Blender's default exposure is actually reasonable. This Wikipedia section lists out exposure values to use with a real camera which range from 5–7 (home interiors) to 15–16 (daylight). By contrast, Blender's default exposure value seems to be 0!
Has anyone tried to get Blender to make changes on their end? Either to update the documentation to at least be self consistent (and ideally also consistent with the gltf exporter!) or even better to have the option to have light units be lumens / lux?
@fintelia Pushed for it, no. But I think they might be open to it:
billrey Feb '19 Because this is now part of the units system, we should be able to add a way to display light values in Lumens (Lm) Luxers (Lx) or Candelas (Cd), by adding an enum menu of options in the Scene > Units section.
This might be a good task for a new developer to create a patch for this.
I bet there's a single big struct
/enum
somewhere that you'd pop the 683.0
coefficient(s) into, CTRL+SHIFT+F to find the places it's used, add a dropdown to the scene panel— Hm, looks like it's PROP_POWER
in #60824 on the BF Gitea.
(Though if W is used anywhere else to mean actual power, and not just luminous flux, then that would be another needed separation.)
Don't know about the "Exposure" slider. It acts more like the "Exp Comp" button you get on cameras, than the shutter speed/aperture definition (especially without ISO).
I just meant Watts was both physically based and backwards-compatible, without introducing numeric changes or changed exposure to old files.
Description:
When exporting a scene with a 1000W Sun light using the GLTF exporter set to the standard lighting mode (intended for use with physically-based units), the exporter incorrectly calculates the light's intensity as 683,000 lux. The expected intensity, based on a widely accepted conversion factor, should be approximately 120,000 lux or more accurately, 120,481 lux. It appears that the exporter uses the formula
1000W * 683
(where PBR_WATTS_TO_LUMENS = 683) for the conversion, misinterpreting the physically based rendering (PBR) watts-to-lumens conversion rate for sunlight. The correct calculation should instead use the conversion factor0.0083
, which translates 1000 watts per square meter to approximately 120,000 lux, or directly apply a multiplication factor of120.48192771084337
to achieve the precise value of 120,481 lux.Steps to Reproduce:
Expected Result:
The Sun light's intensity should be calculated to be around 120,000 lux, reflecting the use of the division conversion factor
0.0083
, which equates 1000 watts per square meter to 120,000 lux, or using the precise multiplication factor to achieve 120,481 lux.Actual Result:
The Sun light's intensity is incorrectly calculated as 683,000 lux, indicating the use of the formula
1000W * 683
, which misapplies the PBR watts-to-lumens conversion factor.Additional Information:
The conversion factor
0.0083
is endorsed by a source on ResearchGate discussing the conversion of solar intensity in lux to watts per square meter for sunlight. This factor suggests that 1 lux equals 0.0083 watts per square meter, providing a more accurate method for converting sunlight intensity into lux (ResearchGate discussion).Environment: