Port of FS118 - More efficient handling of fading lights

[wfpokorny]

http://bugs.povray.org/task/118

(Note there is too a light max distance variant of UberPOV: https://github.com/UberPOV/UberPOV/tree/feature/light_source-max_distance)

---

Details:

Currently, fading light sources are used for lighting and shadow calculations even when so far away as to no longer have any effect on the outcome. The proposed solution is to add a new keyword fade_cutoff_distance which tells povray to ignore the light source when alluminating a point at larger distance.

A sample implementation is provided in the attached files. These changes are still based on beta 34 as sources for the current beta are not yet available, and starting to merge changes to beta 35 only at this time didn't seem worth the effort. Also, please disregard, changes in the CVS header comments (I also use CVS locally for managing source files).

Further considerations regarding this feature:

• For special effects this feature can also be used if the light source does not actually use fading. On the other hand, cutting the light at some distances can be considered an extreme form of fading which may justify the keyword name anyhow.

• Depending on how FS#46 (Now implemented area_illuminate feature) is implemented, the test for cutoff may then be needed at another location as well.

• The default value currently is 0 (or no cutoff distance). For #version 3.7 of higher, the default could be chosen automatically based on the light source intensity and adc_bailout, although it may then need to be overriden by the user for extreme pigments.

  cutoff.zip (106 KiB)

cutoff.zip

When I tried to unzip file above on 24 June 2021, it was corrupted. Trying to attach original again.

cutoff.zip

---

Comments:

---

Comment by Thorsten Fröhlich (thorsten) - Tuesday, 23 August 2011, 11:05 GMT+5

I think this could be added after 3.7 release assuming this code is licensed until GPL/AGPL. Then Chris Cason could merge it, I suppose.

---

Comment by Christian Froeschlin (froesccn) - Wednesday, 24 August 2011, 03:15 GMT+5

The changes are mine, feel free to use them under any license desired.

[c-lipka]

Someone should check whether we've already added this.

[wfpokorny]

FWIW... In a quick check I don't see anything. Pretty sure nothing there when you added a similar feature to Uber* because I used Uber once just for this feature.

I see no fade_cutoff_distance keyword and only DISTANCE_TOKEN, FADE_DISTANCE_TOKEN, for tokens with 'distance'.

But, I didn't look at the source in the zip file...

[wfpokorny]

Ran across a conditional I thought might be related to this issue while banging around in my povr branch. Grabbed the zip but the original attached file is corrupted... Edited and pasted in the original flyspray one again and at least at the moment it's OK.

There isn't much for a change. A new keyword resulting in the parser code:

   CASE (FADE_POWER_TOKEN)
      Object->Fade_Power = Parse_Float();
    END_CASE

    CASE (FADE_CUTOFF_DISTANCE_TOKEN)
      Object->Fade_Cutoff_Distance_Sqr = Parse_Float();
      Object->Fade_Cutoff_Distance_Sqr *= Object->Fade_Cutoff_Distance_Sqr;
    END_CASE

and in trace.cpp this:

void Trace::ComputeOneLightRay(LightSource *lightsource, double& lightsourcedepth, Ray& lightsourceray, Ray& eyeray, Vector3d& ipoint, RGBColour& lightcolour)
{
	double attenuation;
  double cutoff_dist_sqr = lightsource->Fade_Cutoff_Distance_Sqr;

  // CHF: Experimental maximum distance cutoff (intended for lights with strong fading)
  if (cutoff_dist_sqr > 0.0 && (ipoint - Vector3d(lightsource->Center)).lengthSqr() > cutoff_dist_sqr)
  {
    // Returning black causess this ray to be ignored. The same
    // mechanism is used for spot lights and cylindrical lights.
    lightcolour = RGBColour();
    return;
  }

Plus the usual additional glue for initialization, enabling keyword ....

Ehhh, don't know. I think a cut off more automatic and intensity based would be better - would need to think some about how to do that safely.

For the record the bit of code which triggered my looking again at this was the test in trace.cpp / ComputeOneDiffuseLight where I see a hard EPSILON value as a bit suspect given HDR rendering (and expect the calculation and test itself is not cheap).

if (!lightcolour.IsNearZero(EPSILON)) { ... }

[c-lipka]

Ehhh, don't know. I think a cut off more automatic and intensity based would be better - would need to think some about how to do that safely.

The whole point about this cutoff mechanism is that nobody needs to check anything about the light source. Not the distance-based falloff based on whatever settings the light source may have, nor media-based attenuation, nor direction-based attenuation, nor any other attenuation that might be relevant, and most of all not shadow computations. Just the simplest of tests: Is (the square of) the distance larger than (the square of) a certain threshold? Yes? Then ditch everything else - period. Don't even spend a single instruction on computing how much of the light reaches this point.

The beauty of the straightforward distance-based cutoff parameter is that it can be used without too much hassle to implement a straifgtforward cutoff based on intensity and falloff; but at the same time is also easy to use in other scenarios in which itensity and falloff are entirely irrelevant - such as a light source that can't possibly provide direct illumination to anything further than X meters away because in every direction there are walls and other opaque objects in the way.

For the record the bit of code which triggered my looking again at this was the test in trace.cpp / ComputeOneDiffuseLight where I see a hard EPSILON value as a bit suspect given HDR rendering (and expect the calculation and test itself is not cheap).

The comparison with EPSILON itself is rather benign in terms of performance cost, and based on gut feeling I'm pretty sure it's worth to have it. And it shouldn't be that much of a problem with respect to HDR rendering, presuming you stick to half-precision float file formats. Unless you have a pathologically vast array of pathologically dim light sources to illuminate your pathologically dimly-lit scene.