 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Christian Froeschlin <chr### [at] chrfr de> wrote:
> I just tried complementing fade_power and fade_distance for
> light_sources with an experimental new keyword
>
> fade_cutoff_distance
>
> and then simply ignoring all light_sources which are farther
> away from a given point. The idea is that fading light sources
> may be needlessly considered in the calculation even if they
> are so far away that they no longer contribute noticably.
>
The 'calculations' that come to my mind are those for shadows (and possibly
reflectivity of an object, in some way.) This may be a bit off-topic, but I've
recently been wondering about how fade_distance and fade_power currently work
with those--based on some odd rendering results I encountered with my B-29
bomber scene.
The basic question I have is this: When a light's intensity finally drops to
zero at a certain distance, is POV-Ray still spending time trying to compute
shadow calculations for objects out past that distance? I had assumed that it
does not, but I'm not so sure.
Ken
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Kenneth wrote:
> The basic question I have is this: When a light's intensity finally drops to
> zero at a certain distance
the problem is that the intensity never really drops to
zero mathematically, so they are always considered.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
clipka wrote:
> How about automatically computing this from light brightness and
> adc_bailout?
doing it automatically based on light intensity was my first
thought as well but then I found it difficult to place a limit
due to the problem Warp mentioned. But I didn't consider
adc_bailout, that actually seems to fit quite well.
The two drawbacks with that might be
1. It is not so intuitive for the user to change the parameter
"Adaptive Depth Control" for this as the fade cutoff doesn't
affect tracing depth, and removing a fade light artefact with
this parameter may slow down rendering more than necessary as
other rays get traced further out as well.
2. It is less flexible. The cutoff distance has an easily
predictable effect and could well be used for artistic
purposes such as creating a strongly visible boundary
on purpose (e.g. cartoon street lights). Also, in some
situations it might be an alternative to using a light
group (such as a lamp without fading illuminating a
room but not distant objects outside the window).
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. In case the user whishes to override this
behavior to work around some problem or for artistic
reasons the distance could still be set manually.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Christian Froeschlin <chr### [at] chrfrde> wrote:
> 2. It is less flexible. The cutoff distance has an easily
> predictable effect and could well be used for artistic
> purposes such as creating a strongly visible boundary
> on purpose (e.g. cartoon street lights). Also, in some
> situations it might be an alternative to using a light
> group (such as a lamp without fading illuminating a
> room but not distant objects outside the window).
How about instead of it being a parameter related to fading lights, it's
simply a parameter related to lights in general: Set a maximum distance for
the light source to have effect. If a point is farther away than that
distance, ignore that light source.
Maybe if a value is omitted, an automatically computed value is then used
if the light is a fading light.
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp wrote:
> Christian Froeschlin <chr### [at] chrfrde> wrote:
>> 2. It is less flexible. The cutoff distance has an easily
>> predictable effect and could well be used for artistic
>> purposes such as creating a strongly visible boundary
>> on purpose (e.g. cartoon street lights).
> How about instead of it being a parameter related to fading lights, it's
> simply a parameter related to lights in general
It's an alternative. But if you intend to use cutoff for artistic
effect, you'd probably need to set it on a per light_source basis.
And if it's only about speedup or artefact avoidance, adc_bailout
might suffice.
Also, the cutoff distance is logically related to light_source
fading parameters as it affects how the light intensity changes
with distance (even if its just dropping to zero at some point).
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 13.04.2010 13:26, schrieb Christian Froeschlin:
>> How about instead of it being a parameter related to fading lights, it's
>> simply a parameter related to lights in general
>
> It's an alternative. But if you intend to use cutoff for artistic
> effect, you'd probably need to set it on a per light_source basis.
> And if it's only about speedup or artefact avoidance, adc_bailout
> might suffice.
As far as I understand, Warp's suggestion is merely making the setting
available for non-fading light sources as well (which doesn't hurt
anybody as long as the default for non-fading lights would be "infinite").
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
