clipka wrote:

> As far as I understand, Warp's suggestion is merely making the setting 
> available for non-fading light sources as well 

ah I see. Of course, fade_cutoff_distance does not depend
on fade_power, so it also works for fade_power 0. It may raise
the question of whether the name should begin with "fade_".
But it could be seen as a special form of fading. Especially
if the same keyword were to be used for interior attenuation.

Post a reply to this message

Christian Froeschlin <chr### [at] chrfrde> wrote:
> clipka wrote:
>
> > How about automatically computing this from light brightness and
> > adc_bailout?

> But the approaches are not mutually exclusive: we could have
> the default cutoff distance for each light source set based on
> adc_bailout and intensity to speed up rendering without user
> interaction...

I vote YES to that one!  This is the way that I assumed POV-Ray already worked.
:-(  It would speed up many things, to my way of thinking, cutting off
unnecessary calculations for: shadows, IOR, photons and their target objects,
etc. I'm rather clueless as to any problematic 'details' this might produce (or
computational overhead) but on first glance, it seems like a winner.

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*?

Ken

Post a reply to this message

Kenneth 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*?

No, 8 bit here relates to the 8 bit per color in 24-bit RGB output.
And the default is 1/255.

Post a reply to this message

Am 13.04.2010 22:29, schrieb Kenneth:

>> But the approaches are not mutually exclusive: we could have
>> the default cutoff distance for each light source set based on
>> adc_bailout and intensity to speed up rendering without user
>> interaction...
>
> I vote YES to that one!  This is the way that I assumed POV-Ray already worked.
> :-(  It would speed up many things, to my way of thinking, cutting off
> unnecessary calculations for: shadows, IOR, photons and their target objects,
> etc. I'm rather clueless as to any problematic 'details' this might produce (or
> computational overhead) but on first glance, it seems like a winner.

It is done for *some* computations, but there's no shortcut yet to check 
the distance to a light source before testing for shadows (or even 
before computing the distance-attenuated brightness, for that matter).

> 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?

In the 64-bit version, the default is still the same. It's a limit to 
cut short computations that would be unlikely to have any /noticeable/ 
influence on the resulting image; it has nothing to do with the internal 
precision of computations.

By the way, the major difference between the 64-bit and 32-bit versions 
is just the amount of memory POV-Ray can make use of, by using wider 
memory address words in the 64-bit version. While 64-bit processors do 
offer integer arithmetic with larger range than normally used on 32-bit 
processors, they do not offer any advantage in range or precision when 
it comes to floating point arithmetic, which is what POV-Ray really 
needs. Hence, all the constants are the same in both versions.

Post a reply to this message

clipka <ano### [at] anonymousorg> 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

> clipka<ano### [at] anonymousorg>  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

Alain <aze### [at] qwertyorg> 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

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

> 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

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