I'm just brooding over the issue of max trace level and ADC bailout.

If I'm not mistaken, at the moment this is handled such that a ray that is
either "too deep" or is unlikely to make much of a difference is truncated to
black. Which is not ideal, especially when dealing with low max trace level and
high bailout values (or low weights), as it happens during radiosity sample
gathering.

I have a few ideas that could help improve the results in such cases:

(A)

Have the user specify a "cutoff color", to be used instead of the current
default black when a ray exceeds the max trace level or ADC bailout limit; this
way, the color can be adapted to the scene, e.g. for a scene dominated by a
bright blue sky the user could choose a rather bright, blueish color.

(B)

Stick to the black, but automatically "boost" each pixel that has suffered
"cutoff" according to the "lost weight"; e.g. if during tracing for a pixel one
ray is "cut off" that would have contributed an estimated 10% of color to the
pixel, and another that would have contributed 5%, multiply the resulting pixel
color by 1/0.85. (Alternatively, such a correction could be applied at each
"fork" where a ray is cut off; however, it would then be unable to catch cases
where multiple "forked" rays are cut off.)

This may still be wrong, but hopefully not as wrong as the current "blackout".

(C)

Borrow some approach from path tracing: If at a "fork" both rays would drop
below the bailout threshold, but together they would still be above it, roll a
dice and trace one of them.

Post a reply to this message

I have considered the value of letting the user specify the color to use 
when max trace level is reached, although I figured it would just be the 
background color. In a way it makes sense, since if a ray ends up not 
hitting anything that is what the program assigns as the color of the pixel, 
correct? Might make more sense to use the background color as the last value 
and then still calculate the average to reduce the degree of wrongness.


"clipka" <nomail@nomail> wrote in message 
news:web.497e7f655867a2bd122a8da90@news.povray.org...
> I'm just brooding over the issue of max trace level and ADC bailout.
>
> If I'm not mistaken, at the moment this is handled such that a ray that is
> either "too deep" or is unlikely to make much of a difference is truncated 
> to
> black. Which is not ideal, especially when dealing with low max trace 
> level and
> high bailout values (or low weights), as it happens during radiosity 
> sample
> gathering.
>
> I have a few ideas that could help improve the results in such cases:
>
> (A)
>
> Have the user specify a "cutoff color", to be used instead of the current
> default black when a ray exceeds the max trace level or ADC bailout limit; 
> this
> way, the color can be adapted to the scene, e.g. for a scene dominated by 
> a
> bright blue sky the user could choose a rather bright, blueish color.
>
> (B)
>
> Stick to the black, but automatically "boost" each pixel that has suffered
> "cutoff" according to the "lost weight"; e.g. if during tracing for a 
> pixel one
> ray is "cut off" that would have contributed an estimated 10% of color to 
> the
> pixel, and another that would have contributed 5%, multiply the resulting 
> pixel
> color by 1/0.85. (Alternatively, such a correction could be applied at 
> each
> "fork" where a ray is cut off; however, it would then be unable to catch 
> cases
> where multiple "forked" rays are cut off.)
>
> This may still be wrong, but hopefully not as wrong as the current 
> "blackout".
>
> (C)
>
> Borrow some approach from path tracing: If at a "fork" both rays would 
> drop
> below the bailout threshold, but together they would still be above it, 
> roll a
> dice and trace one of them.
>
>
>

Post a reply to this message

"Mike Hough" <nos### [at] nospamcom> wrote:
> I have considered the value of letting the user specify the color to use
> when max trace level is reached, although I figured it would just be the
> background color. In a way it makes sense, since if a ray ends up not
> hitting anything that is what the program assigns as the color of the pixel,
> correct? Might make more sense to use the background color as the last value
> and then still calculate the average to reduce the degree of wrongness.

The background color is possibly not ideal, because its primary intention is to
be used just for that: The background.

There are multiple things coming into play here:

- Someone may use the background color for a "blue box" approach, setting it to
a very distinctive color.

- A scene showing a room may use the background color as an "outside color",
which would be visible only through a window.

The max trace level / adc bailout "cutoff color", however, should ideally be a
rough average of the color in the image.

Post a reply to this message

clipka wrote:

> I have a few ideas that could help improve the results in such cases:

another option would be to ignore transparent objects on the last
trace level, so the ray ends up intersecting with some object which
is actually visible in the scene. Not sure about opaque reflective
objects, remove those and the ray may end up in some part of the
scene with which light isn't actually exchanged at all. But I think
most artefacts with max_trace_level occur with glass/water anyway.

Post a reply to this message

clipka nous illumina en ce 2009-01-26 22:28 -->
> I'm just brooding over the issue of max trace level and ADC bailout.
> 
> If I'm not mistaken, at the moment this is handled such that a ray that is
> either "too deep" or is unlikely to make much of a difference is truncated to
> black. Which is not ideal, especially when dealing with low max trace level and
> high bailout values (or low weights), as it happens during radiosity sample
> gathering.
> 
> I have a few ideas that could help improve the results in such cases:
> 
> (A)
> 
> Have the user specify a "cutoff color", to be used instead of the current
> default black when a ray exceeds the max trace level or ADC bailout limit; this
> way, the color can be adapted to the scene, e.g. for a scene dominated by a
> bright blue sky the user could choose a rather bright, blueish color.
> 
> (B)
> 
> Stick to the black, but automatically "boost" each pixel that has suffered
> "cutoff" according to the "lost weight"; e.g. if during tracing for a pixel one
> ray is "cut off" that would have contributed an estimated 10% of color to the
> pixel, and another that would have contributed 5%, multiply the resulting pixel
> color by 1/0.85. (Alternatively, such a correction could be applied at each
> "fork" where a ray is cut off; however, it would then be unable to catch cases
> where multiple "forked" rays are cut off.)
> 
> This may still be wrong, but hopefully not as wrong as the current "blackout".
> 
> (C)
> 
> Borrow some approach from path tracing: If at a "fork" both rays would drop
> below the bailout threshold, but together they would still be above it, roll a
> dice and trace one of them.
> 
> 
> 
If you go to deep and max_trace kicks in, the color returned is black.

If the contribution goes under the adc_bailout value, you don't return black but 
the calculated color so far. Bailout never return black, unless it have only 
sampled black.

Thus, you ONLY get black if, and only if, max_trace_level kicks in before 
adc_bailout.

So, if you get black spots, you can increase max_trace_level, OR increase 
adc_bailout, OR both.

-- 
Alain
-------------------------------------------------
  "Having a smoking area in a restaurant is like having a peeing area in a pool."
   --Thomas Pfeffer, American Heart Association

Post a reply to this message

Alain <ele### [at] netscapenet> wrote:
> If you go to deep and max_trace kicks in, the color returned is black.
>
> If the contribution goes under the adc_bailout value, you don't return black but
> the calculated color so far. Bailout never return black, unless it have only
> sampled black.
>
> Thus, you ONLY get black if, and only if, max_trace_level kicks in before
> adc_bailout.

I know what you mean, but you're mistaken here:

*Both* max_trace_level and adc_bailout cut-offs do *not* return pure black. They
both do, however, both pretend as if the not-followed portion of the ray was
black. So effectively they both return the calculated color so far - *mixed*
with a more or less big deal of black.

That mix-in will be most notably in shots with high reflectance or refraction,
where max trace level kicks in and places an abrupt end to the ray, with the
contribution of the black mix-in being high enough to be percieved as as a
distinct object of pitch-black color, while the actual pixel values may differ
due to overlaid highlights, diffuse components etc. It is typically far less
obvious with adc_bailout because that mechanism by definition only kicks in
when the not-followed portion of the ray contributes very little to the overall
pixel color, making the outline of the mixed-in black patch far less obvious.

However, even with the adc_bailout, the mix-in of black color may still cause a
slight (and non-uniform) overall darkening of the image.


The math behind this is simple: If a pixel's color is, say, a mix of pure red
weighted at 60%, pure green weighted at 30%, and an untraced portion weighted
at 10%, POV-Ray will make that 0.6*<1,0,0> + 0.3*<0,1,1> + 0.1*<0,0,0>, i.e.
<0.6,0.3,0>. If, however, we assume that the unaccounted-for 10% are the same
color as the average of the accounted-for 90%, we would have to extrapolate
that value to 100% weight, giving <0.6,0.3,0>/0.9 = <0.667,0.333,0.000>, which
is a slightly brighter color.

Post a reply to this message