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;
if (recSettings.maxReuseFactor >= BOUND_HUGE)
maximum_distance = BOUND_HUGE;
smallest_dist = HUGE_VAL;
if (depth > BOUND_HUGE)
depth = BOUND_HUGE;
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
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
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
The bottom two rows show there are always differences between a
radiosity environment set up by shapes and any set up with
- 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.
Post a reply to this message
Download 'radbkgndskystory.jpg' (157 KB)
Preview of image 'radbkgndskystory.jpg'