 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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.
In a rather contrived test scene with a grid of 100 glowing
spheres over a checkered plane (each containing an actual fading
light_source) this sped things up by a factor of 10 without
noticably altering the output.
Do you think this would be a useful feature for real scenes?
I'm thinking of candles and other localized glows here.
Should it be used by photons as well? For them it might just
create additional overhead without speedup (except if you have
multiple photon sources and photon targets, then you could
simply ignore certain combinations due to target distance).
Would it also be useful for interior fading? Possibly for
objects which are so "dense" that they do not let light pass
except at their thinnest parts (so for all rays traversing
the object for more than the cutoff distance the color can
be set to black without continuing the tracing).
My current version is a simple change in Trace::ComputeOneLightRay:
double cutoff_dist_sqr = lightsource->Fade_Cutoff_Distance_Sqr;
if (cutoff_dist_sqr > 0.0 &&
(ipoint - Vector3d(lightsource->Center)).lengthSqr() >
cutoff_dist_sqr)
{
lightcolour = RGBColour();
return;
}
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Christian Froeschlin wrote:
> My current version is a simple change in Trace::ComputeOneLightRay:
And it will probably need to be adapted to work properly
with fading area_illumination, but that seems to be an open
issue in the bug tracker anyway.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Christian Froeschlin wrote:
> Do you think this would be a useful feature for real scenes?
> I'm thinking of candles and other localized glows here.
The only issue I have is that there is probably some way to accomplish
this using light groups; but this is a quick-and-simple way for the
modeling artist to accomplish the time savings, so perhaps a bit of
redundancy is acceptable.
Regards,
John
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
John VanSickle wrote:
> The only issue I have is that there is probably some way to accomplish
> this using light groups; but this is a quick-and-simple way for the
> modeling artist to accomplish the time savings, so perhaps a bit of
> redundancy is acceptable.
true, in most cases there will also be a way to achieve the same
result with light groups. But it may require a lot of manual work,
for example, if a candle illuminates part of the wall of the room,
you'd need to cut that segment out and put it into the light_group.
Also, if you wish to move objects or light_sources you will then
have to restructure your entire scene. I'm not sure how modeling
artists think about this but software developers don't like it ;)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 11.04.2010 16:15, schrieb Christian Froeschlin:
> 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.
How about automatically computing this from light brightness and
adc_bailout?
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
clipka <ano### [at] anonymous org> wrote:
> How about automatically computing this from light brightness and
> adc_bailout?
I don't think you can because how visible the lighting is depends on the
color of the surface being lighted. If the color is very bright, it will be
more easily visible than if it's dark.
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 12.04.2010 13:51, schrieb Warp:
>> How about automatically computing this from light brightness and
>> adc_bailout?
>
> I don't think you can because how visible the lighting is depends on the
> color of the surface being lighted. If the color is very bright, it will be
> more easily visible than if it's dark.
That, while being true, shouldn't prevent from computing a fade cutoff
distance where the light will no longer have any noticeable effect on a
worst-case" surface (e.g. weight = 1.0).
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
clipka <ano### [at] anonymousorg> wrote:
> That, while being true, shouldn't prevent from computing a fade cutoff
> distance where the light will no longer have any noticeable effect on a
> worst-case" surface (e.g. weight = 1.0).
Remember that you can have surface colors which are larger than 1.0.
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 12.04.2010 16:33, schrieb Warp:
> clipka<ano### [at] anonymousorg> wrote:
>> That, while being true, shouldn't prevent from computing a fade cutoff
>> distance where the light will no longer have any noticeable effect on a
>> worst-case" surface (e.g. weight = 1.0).
>
> Remember that you can have surface colors which are larger than 1.0.
Sure. So?
You should adjust adc_bailout accordingly for such scenes anyway.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp wrote:
> clipka <ano### [at] anonymousorg> wrote:
>> How about automatically computing this from light brightness and
>> adc_bailout?
>
> I don't think you can because how visible the lighting is depends on the
> color of the surface being lighted. If the color is very bright, it will be
> more easily visible than if it's dark.
There is also the possibility that the modeling artist wants to model
the effect of a large quantity of distant light sources. The bailout
mechanism will cull some light sources and not others, and in a way that
could produce visible artifacts.
Regards,
John
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Christian Froeschlin <chr### [at] chrfrde> 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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Le 2010-04-13 18:24, Kenneth a écrit :
> 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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Le 2010-04-15 14:12, Christian Froeschlin a écrit :
> 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
|
|
| |
| |
|
|
|
|
| |
