Using getLighting to keep custom light source subjective visibility in daylight

[Rydygier 1309]

I'm trying to make custom light source's impact on surrounding environment/objects at daylight as close, as during night conditions, as possible (for human eye). As a criteria I'm using subjective visiblity range of blue light tint on the surfaces around the light source. 

 

This code seems to work along described lines:

 

RYD_LightEqualizer = 
	{
	private _lght = getLighting select 1;//ambientLightBrightness

	if ((_lght > 570.06) and {(_lght < 1754.41)}) then
		{
		(linearConversion [570.06, 1754.41, _lght, 1.2808, 1.7545, false])
		}
	else
		{
		((_lght/1000) max 1)
		};
	};

 

used like this:

 

_someBrightness = 1;
_brCoeff = [] call RYD_LightEqualizer;		
_someLightSource setLightBrightness (_someBrightness * _brCoeff);

 

Exemplary result for native brightness 1:

 

Spoiler

 

Midnight - coefficient = 1

 

Noon - coefficient = 28.5262

 

Noon - without coefficient (native brightness of 1):

 

 

 

So, if anyone wants, can use it. But, as you can see, there's a certain (determined empirically) range of ambient light brightness values (happening at some time during sunrise and sunset), where general formula - (_lght/1000) max 1 - doesn't suffice (light not visible during that period) which enforced patching with linearConversion part. I could use any advice/improvement to avoid such patching and to have rather one, always working formula (and other good ideas, if any). 

 

PS code was tested on Altis with an assumption, it is the same on every map, but wasn't tested on other maps. Also overcast seem irrelevant as for ambient light brightness value. 

[Rydygier 1309]

Apparently there's some hard treshold of final custom light brightness (CLB) required for certain "ambient light brightness" (ALB). Below this treshold custom light is not visible (immediate disappearance, not fluid fading, thus above function will not ensure constant light visibility for native brightness < 1 - values was calibrated for 1). For example, full daylight for Altis or Tanoa means ALB=28526.2 (constant most of the day except sunrise and sunset, 2048 for VR map), for this ALB CLB treshold seems to be: ~7.074318 (custom light need to be at least of this brightness to be visible - light up any surface - at all). This treshold is different for lower ALB, but the change seems not linear, so the ratio between ALB and CLB treshold isn't constant. Pity, linear change/constant ratio would make things easier. Nitpicking investigation continues...

 

EDIT: also seems, that treshold depends on the light color, which adds another layer of complexicity. 😕

[Rydygier 1309]

On 10/23/2020 at 11:41 AM, Rydygier said:

also seems, that treshold depends on the light color, which adds another layer of complexicity.

 

So far tested for blue component solely, and the relation between this value and actual visibility brightness treshold (VT) seems to be: VT * ((1/blue)^0.5), at least for ALB=28526.2. Also seems, that R and G components in this regard "weight" more, than B for some reason. 

 

This rabbit hole appears to become deeper, than I planned to dive... 🙂 

 

EDIT:

 

For  ALB=28526.2 VT (minimal light source brightness to make it visible at all) looks like:

 

[r,0,0]: 4.368189 * ((1/r)^0.5)

[0,g,0]: 3.117583 * ((1/g)^0.5)

[0,0,b]: 7.074318 * ((1/b)^0.5)

 

so the green component seems to "weight" more, than r or b and r - more than b. 

 

For  ALB= ~1000 VT (x28,5262 less)

 

[r,0,0]: 0.817855 * ((1/r)^0.5) (x5,3410 less)

[0,g,0]: 0.583704 * ((1/g)^0.5) (x5,3410 less)

[0,0,b]: 1.324523 * ((1/b)^0.5) (x5,3410 less)

 

some consistency at last... Note, (28,5262^0.5) = 5,34099. So in these cases rising the Ambient Light Brightness X times rises the Visibility Brigthness Treshold of custom light source (square root of X) times.

 

One mystery, that remains (apart from the main question - why there's such hard treshold in the first place...): why r,g,b have different tresholds. Time to try some r,g,b mixes, I guess.