 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Does anyone know about the importance of the SIGMOID_METHOD/SAW_METHOD
switch in 'radiosit.cpp', line 432:
#ifdef SIGMOID_METHOD
weight = error_reuse / info->Current_Error_Bound; /* 0 < t < 1
*/
weight = (cos(weight * M_PI) + 1.0) * 0.5; /* 0 < w < 1
*/
#endif
#ifdef SAW_METHOD
weight = 1.0 - (error_reuse / info->Current_Error_Bound); /* 0 <
t < 1 */
weight = sqrt(sqrt(weight)); /* less splotchy */
/*weight = sqrt(sqrt(sqrt(weight))); maybe even less splotchy
*/
/*weight = weight*weight*weight*weight*weight; more splotchy */
#endif
By default 'SAW_METHOD' is used, but i have no idea why and what the
difference between the methods is. Also note the commented additional
lines.
A search in the newsgroups archive revealed Margus Ramst had already asked
this quite some time ago, but with no reply:
Subject: radiosity sigmoid_method?
Date: Thu, 03 Dec 1998 00:11:07 +0200
Newsgroups: povray.programming
From: Margus Ramst <mar### [at] peak eduee>
news://news.povray.org/3665BAFB.D420BD6E@peak.edu.ee
http://news.povray.org/3665BAFB.D420BD6E@peak.edu.ee
Christoph
--
POV-Ray tutorials, IsoWood include,
TransSkin and more: http://www.tu-bs.de/~y0013390/
Last updated 13 Aug. 2002 _____./\/^>_*_<^\/\.______
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Fri, 13 Sep 2002 17:46:01 +0200, Christoph Hormann <chr### [at] gmxde>
wrote:
> Does anyone know about the importance of the SIGMOID_METHOD/SAW_METHOD
I don't know what it makes but perhaps some references can be found when
google is asked about sigmoid. Have you tried PDFs returned by
http://www.google.com/search?q=sigmoid+radiosity ?
ABX
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
ABX wrote:
>
> > Does anyone know about the importance of the SIGMOID_METHOD/SAW_METHOD
>
> I don't know what it makes but perhaps some references can be found when
> google is asked about sigmoid. Have you tried PDFs returned by
> http://www.google.com/search?q=sigmoid+radiosity ?
No, they are mostly stuff with coincident occurence of those terms, i also
tried searching various other things, but no success.
Christoph
--
POV-Ray tutorials, IsoWood include,
TransSkin and more: http://www.tu-bs.de/~y0013390/
Last updated 13 Aug. 2002 _____./\/^>_*_<^\/\.______
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Fri, 13 Sep 2002 18:39:01 +0200, Christoph Hormann <chr### [at] gmxde>
wrote:
> No, they are mostly stuff with coincident occurence of those terms, i also
> tried searching various other things, but no success.
Could it be somehow related ?
http://mathworld.wolfram.com/SigmoidFunction.html
http://astronomy.swin.edu.au/~pbourke/analysis/sigmoid/
ABX
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
ABX wrote:
>
> Could it be somehow related ?
>
> http://mathworld.wolfram.com/SigmoidFunction.html
> http://astronomy.swin.edu.au/~pbourke/analysis/sigmoid/
I know about the sigmoid function, but this does not explain why there are
those two methods in the radiosity code and what the purpose of this
alternative is.
Christoph
--
POV-Ray tutorials, IsoWood include,
TransSkin and more: http://www.tu-bs.de/~y0013390/
Last updated 13 Aug. 2002 _____./\/^>_*_<^\/\.______
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Fri, 13 Sep 2002 19:41:02 +0200, Christoph Hormann <chr### [at] gmxde>
wrote:
> I know about the sigmoid function, but this does not explain why there are
> those two methods in the radiosity code and what the purpose of this
> alternative is.
I expected similiar answer but there is a lot of various pages using saw and
sigmoid. I didn't expected to find 'Evolving Virtual Creatures' subject here.
ABX
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Christoph Hormann wrote:
> Does anyone know about the importance of the SIGMOID_METHOD/SAW_METHOD
> switch in 'radiosit.cpp', line 432:
Hi, Jim here.
I actually wrote the offending line of code.
Here's what it means:
When the global illumination samples are reused, several are
put together in a weighted average. The weights are inversely proportional
to the estimated error of each sample. One of the factors governing
the estimated error is how far away it is. So, as you move away
from a point, the error estimate goes up, and the weight of that
sample in the average is gradually reduced. So, the question is,
HOW does the weight vary with distance?
In Greg Ward's original 1998 Siggraph paper, the weight was
the inverse of the estimated error. The estimated error was given
as zero at a zero distance from the sample, which gave an infinite
weight, which I found (if few samples were included in the average)
gave the problem of sudden changes in the value. So, I roll off the
weight more gradually. The saw method makes the effective
area like a cone (a zigzag in section, hence the name): highest
at the old sample location, falling off linearly with distance.
This still gives a discontinuity in the weight at the old sample point,
suddenly changing from rising weight to falling weight. I was seeing
some artefacts that seemed like they might have come from this
effect, so I added the option of the sigmoid weighting. (sigmoid
simply means S-shaped). The weight follows a cosine shape:
higest at the old sample point, rolling off very slowly at first,
then falling faster, then falling slowly again as the weight approaches
zero. In the end, I don't think it matters very much which you use: by far
the
biggest factor in blotchiness (the bane of the radiosity fan) is
how many samples are included in the average, not the rate
of change of the weights.
One exception: I've been finding, tracking down, and very slowly
fixing a few bugs that caused discontinuities in the average. However,
these are caused by old samples not being included in the average,
then being included on the next pixel, and jumping in with a noticeable
weight. Again, this isn't fixed by the sigmoid or saw method, although
there is a possibility that the sigmoid might be a whisker better,
since it has an outer border area of very low, slowly changing weight around
each point.
Jim
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Jim McElhiney wrote:
>
> Hi, Jim here.
Hello and welcome!
> I actually wrote the offending line of code.
Thanks for the detailed explanation, especially considering that is has
been quite some time since you wrote that code (which is probably at the
same time one of the most loved and most hated parts of POV-Ray...).
I have made some tests with the different methods some time ago:
http://www-public.tu-bs.de:8080/~y0013390/simpov/docu04.html
and it seems there are quite significant differences although you can't
really say one method is better than the other in general as it seems.
Christoph
--
POV-Ray tutorials, include files, Sim-POV,
HCR-Edit and more: http://www.tu-bs.de/~y0013390/
Last updated 17 Jun. 2003 _____./\/^>_*_<^\/\.______
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Christoph Hormann wrote:
> Jim McElhiney wrote:
> >
> > Hi, Jim here.
>
> Hello and welcome!
>
Thanks! This is my first post here. Last time I said anything was in the
GO GRAPHICS forum at Compuserve.
(yawn! Rip van Winkling on this for a few years now...)
In fact I'm now a retired guy and I've been working on the radiosity
code lately, fixing the ancient and dreaded blotchiness problem,
and other bugs.
(turns out the blotchiness really is mostly a bug all along).
Not even sure how the POV team works these days,
i.e., who keeps the ball for making new official patches, or
(for that matter) whether or not anyone is interested in my bug fixes.
I like your examples. Frankly, I like any image made using that
code, as I was very proud of it. (not Catholic, so it ain't a sin!)
If you build your own versions, and if you're interested, I can suggest a
VERY quick hack (not a real bug fix) which will fix one big error.
In radiosit.cpp, around line 844 where it calls ot_index (there is only
one call), the second parameter is (and always has been) wrong.
(it is correct for top level light collection only, but does not allow
for the situations where the error bound gets adjusted on the fly,
which happens with recursion depth and with low-radiosity-contribution
points)
I'm working on the exact expression, (depends on the implemention
of other things, such as recursion limit depth), but if you just take the
value
there and multiply it by 3 or 4 your images will look better, by
avoiding some discontinuities in shading.
This will make results more correct and *very* slightly slower.
(it will make searches in the octree a bit slower, by considering
a few extra nodes, but that's pretty quick integer stuff, not like
tracing more rays).
Rgds
Jim
>
> > I actually wrote the offending line of code.
>
> Thanks for the detailed explanation, especially considering that is has
> been quite some time since you wrote that code (which is probably at the
> same time one of the most loved and most hated parts of POV-Ray...).
>
> I have made some tests with the different methods some time ago:
>
> http://www-public.tu-bs.de:8080/~y0013390/simpov/docu04.html
>
> and it seems there are quite significant differences although you can't
> really say one method is better than the other in general as it seems.
>
> Christoph
>
> --
> POV-Ray tutorials, include files, Sim-POV,
> HCR-Edit and more: http://www.tu-bs.de/~y0013390/
> Last updated 17 Jun. 2003 _____./\/^>_*_<^\/\.______
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Jim McElhiney wrote:
>
> [...]
> Not even sure how the POV team works these days,
> i.e., who keeps the ball for making new official patches, or
> (for that matter) whether or not anyone is interested in my bug fixes.
In case of bug fixes i'm pretty sure the Team is interested in including
them in the next official release (3.51). If you have more elaborate
changes this will be greatly appreciated for MegaPOV (3.51 is a bugfix
release so there will be no new features).
While you are here - something that has wondered some of us lately is how
the 1600 sample ray directions which are hardcoded in the program are
originally generated. There have been some affords to generate a better
distribution (and the possibility to use more than 1600 rays).
> If you build your own versions, and if you're interested, I can suggest a
> VERY quick hack (not a real bug fix) which will fix one big error.
> In radiosit.cpp, around line 844 where it calls ot_index (there is only
> one call), the second parameter is (and always has been) wrong.
> (it is correct for top level light collection only, but does not allow
> for the situations where the error bound gets adjusted on the fly,
> which happens with recursion depth and with low-radiosity-contribution
> points)
> I'm working on the exact expression, (depends on the implemention
> of other things, such as recursion limit depth), but if you just take the
> value
> there and multiply it by 3 or 4 your images will look better, by
> avoiding some discontinuities in shading.
> This will make results more correct and *very* slightly slower.
> (it will make searches in the octree a bit slower, by considering
> a few extra nodes, but that's pretty quick integer stuff, not like
> tracing more rays).
Sounds interesting, i will try it.
Christoph
--
POV-Ray tutorials, include files, Sim-POV,
HCR-Edit and more: http://www.tu-bs.de/~y0013390/
Last updated 17 Jun. 2003 _____./\/^>_*_<^\/\.______
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
