![](/i/fill.gif) |
![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
clipka <ano### [at] anonymous org> wrote:
> > Here's another odd and clueless observation/question: In 32-bit POV-Ray, the
> > default adc_bailout is 2^8. In the 64-bit version, is it 2^*higher power*?
>
> You mean 1.0/2^8 for the 32-bit version, right?
>
Oops! Right you are.
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
> clipka<ano### [at] anonymous org> wrote:
>
>>> Here's another odd and clueless observation/question: In 32-bit POV-Ray, the
>>> default adc_bailout is 2^8. In the 64-bit version, is it 2^*higher power*?
>>
>> You mean 1.0/2^8 for the 32-bit version, right?
>>
>
> Oops! Right you are.
>
>
>
If you render in a format that have a deeper range, then you can reduce
adc_bailout further.
If you render with +fn16 (16 bit per channel PNG), then, in some case,
it may make cense to set: adc_bailout 1/pow(2,16)
But that can increase the rendering time if you have many reflections
and transparence. It can also push you over the max_trace_level
resulting in black pixels.
Alain
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Alain <aze### [at] qwerty org> wrote:
> If you render in a format that have a deeper range, then you can reduce
> adc_bailout further.
> If you render with +fn16 (16 bit per channel PNG), then, in some case,
> it may make cense to set: adc_bailout 1/pow(2,16)
That's very interesting; I didn't know it was possible. (I *thought* the lower
limit was 1/2^8--although the docs don't say so.)
> But that can increase the rendering time if you have many reflections
> and transparence. It can also push you over the max_trace_level
> resulting in black pixels.
Reading the docs on max_trace_level, one part implies that the value *can* be
set higher than 256 if needed--but then later, it says that 256 is the limit.
I.e., a 'matching' value of pow(2,16) isn't possible. Which would indeed result
in some black pixels, I think.
Ken
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Kenneth wrote:
> I.e., a 'matching' value of pow(2,16) isn't possible. Which would indeed result
> in some black pixels, I think.
in those cases, pow(2,16) would probably give you *no* pixels ;)
Actually I think it is strange that adc_bailout would give you
extra black pixels. I would have expected max_trace_level to return
black only for the remaining part of the ray which was cut off. Then,
if that rays contribution was already negligible, there should not
be much difference. But if I read the docs right this is not how
max_trace_level works?
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
> Kenneth wrote:
>
>> I.e., a 'matching' value of pow(2,16) isn't possible. Which would
>> indeed result
>> in some black pixels, I think.
>
> in those cases, pow(2,16) would probably give you *no* pixels ;)
>
> Actually I think it is strange that adc_bailout would give you
> extra black pixels. I would have expected max_trace_level to return
> black only for the remaining part of the ray which was cut off. Then,
> if that rays contribution was already negligible, there should not
> be much difference. But if I read the docs right this is not how
> max_trace_level works?
When you reatch max_trace_level the ray return black.
A thing that can sometimes save you is when the ray have been split
trhough partial reflection.
In that case, it looks like that path(s) that stoped before
max_trace_level are retained and mixed with the black.
The result in 3.6 and 3.7 are not the same in that case.
Alain
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Am 15.04.2010 20:12, schrieb Christian Froeschlin:
> Actually I think it is strange that adc_bailout would give you
> extra black pixels. I would have expected max_trace_level to return
> black only for the remaining part of the ray which was cut off. Then,
> if that rays contribution was already negligible, there should not
> be much difference. But if I read the docs right this is not how
> max_trace_level works?
Then you're not reading the docs right: When max_trace_level is reached,
any /additional/ reflections and refractions are ignored, as if the
object /there/ was pitch black. All other objects the ray has
encountered on its way there will show up perfectly ok.
So if you're trying to achieve a Hall-Of-Mirrors effect with some dust
or dirt on each mirror, the resulting image will look like somewhere in
the "distance" there's a mirror that's just plain black instead of
reflecting anything, but you'll still see the dust and dirt on the
mirrors "in between".
BTW, adc_bailout works basically the same, except that it's kind of an
"adaptive max_trace_level".
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |