Hey all,
Can someone explain to me the proper way to set up hemisphere light in 164+, the way it works? Say I want 0xFF0000 red, 0x0000FF blue, testing on a sphere, I get only the poles to receive my colours. The rest is white. Using a third of the colours per channel gives me the expected colours. so 0x330000 and 0x000033. Above the values are clamped to 255 and all is mostly white. To my understanding, the color should be the average of 2 dotprods. (normal to light dir and the inverse) or a mix based on the complement of the first one no matter the intensity. Is there a param non documented that I miss? Also as I increase/decrease the intensity for the same test scene, I keep the intended colours using 0.33, fine, but I see the ground color gets more importance vs the sky while I still should have at the equator of my test sphere 50% of both colours no matter the intensity. Then the position, which seams to be a direction instead…
This is not a correct assumption for a physically-based lighting model, and in general there is no guarantee that reflected light will have the same RGB values as incoming light. Results will also depend on choices like material parameters, rendering color space, tone mapping, exposure… I’m not sure what decisions you’ve made there, or whether you’re using a framework like R3F or Threlte that has additional defaults.
There were important changes in r155, described in —
You might find the answers you’re looking for there, and in particular…
Light intensities are not internally scaled by factor PI anymore. This so called artist-friendly light intensity scaling factor was in place to make it easier to achieve good looking lighting with intensities around 1. However, in context of physically correct lighting such scaling factors are incorrect and make it impossible to use proper SI units.
… try applying a factor of Math.PI to your intensities?
For absolute control of RGB values coming from your surface, you may prefer to use a custom shader or MatCap material.
thx for the reply Don. I’ve red about the changes, still am actually!
I’m not totally sold on your statements tho (not saying they are wrong!). But in a basic scene with basic phong material, no other light than this hemisphere, I do expect a gradian and the right colours instead them to quickly get clamped at the equator while the poles (in my sphere case) have not yet reached the colours I gave while increasing intensity. I can imagine some differences for the PB model, but here we talk burned to death colours for the same intensity vs if I pass each rgb to a third of their values per channel.
try applying a factor of Math.PI to your intensities?..
My editor is 1mm = 1 unit and seek a concordance for my exports. Basically factor 100. At my scale PI doesn’t really helps. But may be I need to try export at this scale as I do for my blender exports.
For absolute control of RGB values coming from your surface, you may prefer to use a custom shader…
Yes, and that’s probably what I’ll end up doing at a later stage, after I saw the flamingo example shader, which makes more sense to me (when properties/factors are available as in the shader). Tho, I will for the time being simply use the 1/3 of value hack, as it perfectly works for my needs and my incorrect assumption!
About the factor of PI – what I mean is that perhaps your “1/3 of value hack” is really just an approximation of light.intensity /= Math.PI, and not necessarily a hack at all.
Just tried and while it does produce much better results than before for the same params. It’s not yet as my brain expect it nor respecting the colors as by directly affecting the rgb channels. Before I go on with this. I first need to have a proper environment to compare (my program to 3js ) with unit conversion / distances, factors etc… Right now I can manage for any custom work to adjust the values I need but I need a solid solution for my exports.
Thx again Don.
