Hello,

I've read http://radsite.lbl.gov/radiance/papers/erw92/paper.pdf which
explains how to use irradiance gradient (rotational (rotation of the normal)
and translational (sample point translated)) to improve extrapolation of
radiosity between sampling locations. Then I looked at pov source and I
didn't recognize anything in the gradient it calculate, in fact I don't
understand what exactly is this gradient... I tried to desactivate it then
render some radiosity scenes but see no differences ! I may have done
something wrong, so if anyone can confirm this .. ?
The rotational gradient seems easy to add to pov radiosity, but the
translational gradient is more difficult to implement (because it uses
radiance differences between neightboring samples)

M

Post a reply to this message

Mael wrote:
> 
> Hello,
> 
> I've read http://radsite.lbl.gov/radiance/papers/erw92/paper.pdf which
> explains how to use irradiance gradient (rotational (rotation of the normal)
> and translational (sample point translated)) to improve extrapolation of
> radiosity between sampling locations. Then I looked at pov source and I
> didn't recognize anything in the gradient it calculate, in fact I don't
> understand what exactly is this gradient... I tried to desactivate it then
> render some radiosity scenes but see no differences ! I may have done
> something wrong, so if anyone can confirm this .. ?
> The rotational gradient seems easy to add to pov radiosity, but the
> translational gradient is more difficult to implement (because it uses
> radiance differences between neightboring samples)

I am not sure if i understand you correctly but POV-Ray already calculates
and uses the translational gradients of the illumination values to improve
the results.  I have not tried to deactivate this with the RAD_GRADIENT
switch but i guess this would make a difference.  

Concerning what irradiance gradients are - they are the rate at which the
illumination changes when changing certain variables, in case of the
translational gradients when changing the position.  How this is estimated
is described in the paper you cited.  

Christoph

-- 
POV-Ray tutorials, include files, Sim-POV,
HCR-Edit and more: http://www.tu-bs.de/~y0013390/
Last updated 28 Feb. 2003 _____./\/^>_*_<^\/\.______

Post a reply to this message

Ok sorry, I manage to build a simple scene that clearly shows the effect of
the gradient
http://195.221.122.126/gradients/plan_radgrad.png
http://195.221.122.126/gradients/plan_radnograd.png


As a test I tried to replace pov translational gradient by a rotational
gradient. Here are some results :

Radiosity parameters :
pretrace_start 0.04
pretrace_end 0.02
count 450
recursion_limit 1
nearest_count 5
error_bound .5

official pov
http://195.221.122.126/gradients/cornell_rad_eb.5c450_pov35.png

halton sampling, pov translational gradient
http://195.221.122.126/gradients/cornell_rad_eb.5c450_halton_povgrad.png

halton sampling, no gradients
http://195.221.122.126/gradients/cornell_rad_eb.5c450_halton_nograd.png

halton sampling, rotational gradient
http://195.221.122.126/gradients/cornell_rad_eb.5c450_halton_rotgrad.png

all scenes = 500 ko

(as always it's easier to see the differences with an image viewer to
quickly switch between images)

M

Post a reply to this message

Mael wrote:
> 
> Ok sorry, I manage to build a simple scene that clearly shows the effect of
> the gradient
> http://195.221.122.126/gradients/plan_radgrad.png
> http://195.221.122.126/gradients/plan_radnograd.png
> 
> As a test I tried to replace pov translational gradient by a rotational
> gradient. Here are some results :
> 
> [...]

The results look quite how you would expect them i think - rotational
gradients improving results on curved surfaces.  But the lighting on the
spheres looks somewhat wrong, at least quite different from the other
images.  A test with higher quality (i.e. less disturbing artefacts) would
be good.  

In practical situations artefacts on flat surfaces are often more relevant
though.  Therefore i would not remove the translational version.  Note the
difference in the ceiling appearance in front of the light.  It would also
be important to test with real light sources in the scene since this is
the more common situation.

Christoph

-- 
POV-Ray tutorials, include files, Sim-POV,
HCR-Edit and more: http://www.tu-bs.de/~y0013390/
Last updated 28 Feb. 2003 _____./\/^>_*_<^\/\.______

Post a reply to this message

> The results look quite how you would expect them i think - rotational
> gradients improving results on curved surfaces.

yes it's logical

> But the lighting on the
> spheres looks somewhat wrong, at least quite different from the other
> images.

How wrong ? I see a smoother lightning
Side note : all those images have the 0 1 clipping done by pov on prediction
value (IMHO this clipping should be removed..)

> In practical situations artefacts on flat surfaces are often more relevant
> though.  Therefore i would not remove the translational version.

Right, But a final aim would not be to replace or remove translational
gradient, but to have translational+rotational gradients

> Note the
> difference in the ceiling appearance in front of the light.

concerning ceiling (and the top of back wall) I think it's more a problem of


> It would also
> be important to test with real light sources in the scene since this is
> the more common situation.

For test scenes I prefer to use radiosity only as it's easier to see what
happens.

None the less for real scenes I'm not sure the gradient is really useful.
For example when you render a scene using a 2 pass method (with a second
pass with sample off) you don't use irradiance gradient at all (it is not
saved in the file)

M

Post a reply to this message

> Side note : all those images have the 0 1 clipping done by pov on
prediction
> value (IMHO this clipping should be removed..)

Same parameters, with rotational gradient, (so compare to
cornell_rad_eb.5c450_halton_rotgrad.png) but with  no clipping (the 'light'
is rgb 1 ambient 7.8)
http://195.221.122.126/gradients/cornell_rad_eb.5c450_rotgrad_noclipping.png

M

Post a reply to this message

On Mon, 17 Mar 2003 17:59:14 +0100, Mael wrote:

>> Side note : all those images have the 0 1 clipping done by pov on
> prediction
>> value (IMHO this clipping should be removed..)
> 
> Same parameters, with rotational gradient, (so compare to
> cornell_rad_eb.5c450_halton_rotgrad.png) but with  no clipping (the 'light'
> is rgb 1 ambient 7.8)
> http://195.221.122.126/gradients/cornell_rad_eb.5c450_rotgrad_noclipping.png
> 
> M

Ah, this clipping may explain why whenever I try to use ambient 
objects/emission media as light sources it NEVER works! (All I see are a 
few dull splotches)

-- 
light_source#macro G(E)sphere{z+E*y*5e-3.04rotate-z*E*6pigment{rgbt#end{
20*y-10#local n=162;1}#while(n)#local n=n-.3;G(n)x}}G(-n).7}}#end//GregE

Post a reply to this message

> Ah, this clipping may explain why whenever I try to use ambient 
> objects/emission media as light sources it NEVER works! (All I see are a 
> few dull splotches)

I was talking about it.... 2 weeks ago...
But Christoph said that I am the "bad man" because I am attacking POV community :)
OK till next sunday will provide patch for clipping removement and
full implementation of gradients... because there is no translational gradient in
current POV implementation... only rotational... because its cheap to calculate.

Post a reply to this message

On Tue, 18 Mar 2003 09:10:14 +0100, "T.J.Viking" <vik### [at] bp-domarpl> wrote:
> I was talking about it.... 2 weeks ago...
> But Christoph said that I am the "bad man" because I am attacking POV community :)

False claims. You were "bad man" because the wrong way helping in fixing it. You
demanded better quality but at that time refused to be responsible for making it
better and share you knowledge. The discussion was inspired by HDRI/radiosity
but was concerned about behaviour in opensourced-like community.

> OK till next sunday will provide patch

You said you have knowledge. You said mistakes are obvious. But you need three
weeks to fix it. Other patchers and Team members works on much more complicated
tasks spending months on some additions. I hope you understand now why
complaining without exact arguments and source code quotation is so annoying.

I really wait for your patch.

ABX

Post a reply to this message

> False claims. You were "bad man" because the wrong way helping in fixing it. You
> demanded better quality but at that time refused to be responsible for making it
> better and share you knowledge. The discussion was inspired by HDRI/radiosity
> but was concerned about behaviour in opensourced-like community.

ok,ok :) EOT in this subject for me...
 
> > OK till next sunday will provide patch
> 
> You said you have knowledge. You said mistakes are obvious. But you need three
> weeks to fix it. Other patchers and Team members works on much more complicated
> tasks spending months on some additions. I hope you understand now why
> complaining without exact arguments and source code quotation is so annoying.

I never said I will need three weeks to fix it....
You can fix it in 30-60 minutes...
But testing and providing stable patch is another matter, and having a lot of time
in the nowadays world.... is another hard try.

Post a reply to this message