While chasing the odd uninitialized vector while working to eliminate 
the dual initialization most 2d and 3d vectors get today in v3.8, found 
a long standing issue with radiosity using sky_spheres / backgrounds.

In radiosity.cpp change:

...
if (recSettings.maxReuseFactor >= HUGE_VAL)
     maximum_distance = HUGE_VAL;
...
smallest_dist = BOUND_HUGE;
...
if (depth > HUGE_VAL)
     depth = HUGE_VAL;
...


to:

...
if (recSettings.maxReuseFactor >= BOUND_HUGE)
     maximum_distance = BOUND_HUGE;
...
smallest_dist = HUGE_VAL;
...
if (depth > BOUND_HUGE)
     depth = BOUND_HUGE;
...


Background.

Originally HUGE_VAL was a POV-Ray defined value of 1e17. As early as the 
mid to late 1990s HUGE_VAL was often a c/c++ include defined macro 
value. Today in c++11, it is a macro defined to double +inf.

Originally the POV-Ray defined BOUND_HUGE was 1e30, it is today 2e10.

The maximum intersection depth to actual shapes is limited to 
MAX_DISTANCE set at 1.0e7.

POV-Ray long returned a BOUND_HUGE value for the intersection depth when 
no intersection was found with TraceRay() as well as all the 
FindIntersection() variations. Today in v3.7,v3.8,v4.0 it returns 
HUGE_VAL for the function TraceRay() alone.

TraceRay does this using optional max distance conditionals and logic 
I'm 'guessing' might have been added to support the obscure mesh camera 
feature (v3.7) allowing a max range spec for the camera rays.

If you are setting up an environment for radiosity with shapes - a 
surrounding hollow sphere say - there is no exposure to the bug being 
fixed here.

If, however, you are using the background color or a sky_sphere the 
TraceRay() code returns inf and often enough all the radiosity samples 
in the half sphere end up with an infinite result and the nearest vector 
doesn't get set to anything. Several other values driven large by the 
inf results get clamped more or less as they do for shape intersections 
at large distances.

Where the nearest vector doesn't get set, it happens we've been 
mitigating the bug via the fact the vector.h template allocation always 
initializes to a zero vector (this the very, almost always duplicate, 
initialization I'm trying to eliminate in povr). Today, where the 
nearest vector is 'left' a 0,0,0 the vector dot product comes out at 
zero and we use 100% of the 'harmonic mean' of samples in the code 
instead of one more vigorously weighted in the direction of one of the 
samples in the half dome of samples.

The bug is real, however, how much one might see it in any given scene - 
especially with better radiosity settings - I'm not sure. My guess is it 
would most often present as slightly darker and bland/washed out results 
when the bug is in play - with better radiosity settings.

For more background on the v3.8/v4.0 performance issues I am, in part, 
trying to address by eliminating the nearly always double vector 
initialization see:

https://github.com/POV-Ray/povray/issues/363

--- image
The top row of the attached image shows there is no change due the fix 
where the environment is set up with a sphere.

The second row shows there are corrections due the fix when using a 
sky_sphere.

The bottom two rows show there are always differences between a 
radiosity environment set up by shapes and any set up with 
background/sky_spheres.

Asides:

- Environmental set up with shapes is slower than any with 
backgrounds/sky_spheres because intersections on the containing shape 
exist and must be handled as real shape intersections.

- Noted too while digging around, there are differences between the 
accuracy of loaded radiosity samples and immediately calculated ones 
which 'might' - occasionally - present as visible differences.

Bill P.

Post a reply to this message

Attachments:
Download 'radbkgndskystory.jpg' (157 KB)

Preview of image 'radbkgndskystory.jpg'