> 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