Hi all,

	I wonder why there is no possibility to define a combination
of confidence/variance (as in focal blur for instance) when calculating
the area_light with adaptive keyword. Maybe a single parameter could
be also used, since in the current code the tolerance is set to 10 %.
	Also it seems that we cannot specify the maximum number of
shadow rays to be calculated when using the adaptive method, but only
a mimimum. Adressing these two points could maybe speed up rendering
in most of cases, don't u think ?


*** Nicolas Calimet
*** http://pov4grasp.free.fr

Post a reply to this message

In article <3A0AE8A1.97AB79F5@igbmc.u-strasbg.fr>, Nicolas Calimet 
<pov### [at] freefr> wrote:

> 	I wonder why there is no possibility to define a combination
> of confidence/variance (as in focal blur for instance) when calculating
> the area_light with adaptive keyword. Maybe a single parameter could
> be also used, since in the current code the tolerance is set to 10 %.

As I understand it, area lights use an algorithm more like adaptive 
antialiasing than focal blur.


> 	Also it seems that we cannot specify the maximum number of
> shadow rays to be calculated when using the adaptive method, but only
> a mimimum. Adressing these two points could maybe speed up rendering
> in most of cases, don't u think ?

The sampling parameters were probably originally intended to be set in 
the scene file, this is probably just an oversight, something never 
completed(like "track" in light sources, and "type" in black hole 
warps). More sampling methods/parameters definitely would be useful.

-- 
Christopher James Huff
Personal: chr### [at] maccom, http://homepage.mac.com/chrishuff/
TAG: chr### [at] tagpovrayorg, http://tag.povray.org/

<><

Post a reply to this message

> As I understand it, area lights use an algorithm more like adaptive
> antialiasing than focal blur.

	Yes, that's true, actually the idea is just the same. So I think
one could simply add a tolerance parameter (same effect as when using for
instance +A0.3 in adaptive antialiasing) to the definition of an area_light
- again when using adaptive method. This would replace the default 0.1
difference between the tested rays. I also propose to add an option to
specify either the recursion limit or the maximum number of shadow rays.
The first would be more consistent with the current available options.

	Another point is about a general optimisation of all these different
adaptive sampling methods. When using adaptive antialiasing, every ray hits
different portions on the object surfaces (at least for near objects), so the
shadow rays should be different too, but not *so* different. When using
area_light, at the first recursion level (antialiasing and shadowing), we get
at least 16 rays: 4 from the camera times 4 from the object to each corner of
the area_light. The situation becomes even more expensive for every next
recursion levels.

	Could it be possible to mix the area_light adaptive method with the
antialiasing one ? I understand the situations are different, especially if
the area_light is large enough. But maybe there's some way (approximation) to
save a lot of rays instead of multiplying all the tests required at every
recursion levels.

	Is that simply utopia ? I'm currently using my custom implementation
of a camera motion blur effect (moving camera; based on focal blur method) with
area_lights and adaptive anti-aliasing, and that's hell to render. I suspect a
lot of rays are "wasted" but I didn't yet find an appropriate method to solve that.


*** Nicolas Calimet
*** http://pov4grasp.free.fr

Post a reply to this message

In article <3A0BE522.1DE8E5B0@free.fr>, Nicolas Calimet 
<pov### [at] freefr> wrote:

> > As I understand it, area lights use an algorithm more like adaptive
> > antialiasing than focal blur.
> 
> 	Yes, that's true, actually the idea is just the same. So I think
> one could simply add a tolerance parameter (same effect as when using 
> for instance +A0.3 in adaptive antialiasing) to the definition of an 
> area_light - again when using adaptive method. This would replace the 
> default 0.1 difference between the tested rays. I also propose to add 
> an option to specify either the recursion limit or the maximum number 
> of shadow rays. The first would be more consistent with the current 
> available options.

It looks very easy to do that from the source code...never mind, I just 
did it, it took about 5 minutes, most of which was spent figuring out 
enough of block_area_light(though it isn't tested yet). :-)
I could post the changes here, but they really were nothing: I added an 
"Adaptive_Threshold" variable to the light source struct, initialized it 
to 0.1 in Create_Light_Source(), modified block_area_light to use that 
value instead of 0.1, and added a CASE() in Parse_Light_Source() using 
the "threshold" token.


> 	Could it be possible to mix the area_light adaptive method with the
> antialiasing one ? I understand the situations are different, 
> especially if the area_light is large enough. But maybe there's some 
> way (approximation) to save a lot of rays instead of multiplying all 
> the tests required at every recursion levels.

I'm not sure what exactly you mean...do you want to only calculate area 
lighting once and use that result for every sample of each pixel? So for 
each pixel, area lighting is calculated once, regardless of how many 
samples anti-aliasing uses?
I doubt this would be helpful...it would be equivalent to averaging one 
image using area lights with several images without area lights. Unless 
you propose to somehow use the same lighting calculations for all the 
additional samples...something that would probably require a complete 
redesign and rewrite of that entire portion of the code.


> 	Is that simply utopia ? I'm currently using my custom implementation
> of a camera motion blur effect (moving camera; based on focal blur 
> method) with area_lights and adaptive anti-aliasing, and that's hell 
> to render. I suspect a lot of rays are "wasted" but I didn't yet find 
> an appropriate method to solve that.

First: do you really need anti-aliasing with this camera motion blur?

Second: when are you going to release this patch? :-)
Or have you already?

-- 
Christopher James Huff
Personal: chr### [at] maccom, http://homepage.mac.com/chrishuff/
TAG: chr### [at] tagpovrayorg, http://tag.povray.org/

<><

Post a reply to this message

> I could post the changes here, but they really were nothing: I added an
> "Adaptive_Threshold" variable to the light source struct, initialized it
> to 0.1 in Create_Light_Source(), modified block_area_light to use that
> value instead of 0.1, and added a CASE() in Parse_Light_Source() using
> the "threshold" token.

	Yes I thought about doing exactly the same, maybe in 3 minutes
instead of 5 ;-) That's why I think it should (or may ?) be included
in POV 3.5... Only thing is at least to test if it's actually valuable.

> I'm not sure what exactly you mean...do you want to only calculate area
> lighting once and use that result for every sample of each pixel? So for
> each pixel, area lighting is calculated once, regardless of how many
> samples anti-aliasing uses?

	Well I'm not sure too, because if so I would at least try to do it.
What I'm thinking about is something like this: with antialias method 2
you start to sent 4 rays at each corner of the pixel; assume the rays are
all hitting the same object, at almost the same distance; then send rays
to the area_light to determine lighting/shadowing; for each point there
is normally 4 rays sent at the first recursion level of shadowing; but
these 4 rays are not so different from the others points, in term of
direction and probably shadow result. I would say in this particular
case: the 4 rays sent for each point hit starting from one pixel corner
are almost the same, one by one, than for the second point hit from the
second pixel corner, and so on. It means we could send only 4 rays to the
area_light and use them for each of the 4 "corners"; not 16. Also it
means we are probably in a situation where more further recursion level
are not necessary (both for area_light and antialiasing). So I'm not sure
it worth it. Finally all that looks like what you summarized in one or two
sentences... Sorry but my english is*that* bad ;-)

> I doubt this would be helpful...it would be equivalent to averaging one
> image using area lights with several images without area lights.

	I'm not sure this will be this kind of result... but I'm maybe
wrong.

> something that would probably require a complete
> redesign and rewrite of that entire portion of the code.

	Hehehehe maybe for POV 4.0 ?
 
> First: do you really need anti-aliasing with this camera motion blur?

	Yes, because it can happen there are sharp regions, just like in
focal blur (depends on the camera location and look_at moves). Actually
only the antialias method 2 can work properly. I also use it for focal
blur since it helps a little bit to reduce the grainy effect. But also
is more expensive.

> Second: when are you going to release this patch? :-)
> Or have you already?

	Yes I already did, and mentionned it several times in this group,
even not so long ago (see "Need solution for (simulating) Motion blur" in
p.a-users, 2000-10-29, for my last post about it). The thing is that this
is not the main feature of my patch which is devoted to structural biology,
so I guess almost nobody cares about it. Also there is still no related
page or tutorial; should be ready soon. Site adress is given below. I
implemented this feature quickly last february or march if I remember well,
since MegaPOV didn't do it yet. Code is really simple, not much of optimi-
zations. It works quite easily for instance when camera is following spline
paths (using C. Colefax's macros).

	Okay, enough advertising ;-)


*** Nicolas Calimet
*** http://pov4grasp.free.fr

Post a reply to this message

In article <3A0D82A3.37D5D7CF@free.fr>, Nicolas Calimet 
<pov### [at] freefr> wrote:

> 	Yes I thought about doing exactly the same, maybe in 3 minutes
> instead of 5 ;-)

Well, I had to find and decipher block_area_light() before I could 
start... ;-)


> That's why I think it should (or may ?) be included in POV 3.5... 
> Only thing is at least to test if it's actually valuable.

I will ask about it.


> > I doubt this would be helpful...it would be equivalent to averaging one
> > image using area lights with several images without area lights.
> 	I'm not sure this will be this kind of result... but I'm maybe
> wrong.

No, you are right...I thought you were talking about using point lights 
for the extra samples.


> > something that would probably require a complete
> > redesign and rewrite of that entire portion of the code.
> 
> 	Hehehehe maybe for POV 4.0 ?

Maybe... :-)


> Actually only the antialias method 2 can work properly.

Why is that?


> I also use it for focal blur since it helps a little bit to reduce 
> the grainy effect.

Hmm, I thought focal blur replaced ordinary anti-aliasing...but looking 
at the manual again, it only says AA isn't needed, not that it won't be 
done.

-- 
Christopher James Huff
Personal: chr### [at] maccom, http://homepage.mac.com/chrishuff/
TAG: chr### [at] tagpovrayorg, http://tag.povray.org/

<><

Post a reply to this message

> > Actually only the antialias method 2 can work properly.
> 
> Why is that?

	With method 1 the current pixel and its up and/or left neighbour
are both supersampled if required, and this leads to the opposite result
than the expected one. When I experienced that the first time, I found
it was obvious, but now I don't remember why ;-) Anyway the method 2
works fine since we are supersampling *through* the current pixel, leaving
the neighbours the same.

> > I also use it for focal blur since it helps a little bit to reduce
> > the grainy effect.
> 
> Hmm, I thought focal blur replaced ordinary anti-aliasing...but looking
> at the manual again, it only says AA isn't needed, not that it won't be
> done.

	Yes, ideally the method by itself will produce antialiased pic
since the camera is slightly moving (roughly on a disk). But, as Warp
mentionned on his site (a dedicated page), the sharp zone is not enough
antialiased. Allowing method 2 to work gives pretty good results (again
method 1 is bad). Rendering speed is of course slower. But I think it
worth it, since it also helps a little bit to reduce the grainy effect
produced by random numbers. This effect is especially strong for pure
colours (I only use that for scientific stills/movies), even when there
are a lot of blur_samples and variance is 0 (all rays are traced).

	You may know that similar effects are obtained with area_light
with a few lights inside and jittering. Same also for all the media
stuffs. I wonder if the "random" number generator could be renewed a
little bit to get smoother pictures... but I'm not sure this is the
real cause of those problems, although I suspect it from my tests on
focal blur code.


*** Nicolas Calimet
*** http://pov4grasp.free.fr

Post a reply to this message