POV-Ray : Newsgroups : povray.unofficial.patches : Re: Stochastic Radiosity Patch for PoV 3.1g Server Time
2 Sep 2024 08:13:43 EDT (-0400)
  Re: Stochastic Radiosity Patch for PoV 3.1g (Message 7 to 16 of 16)  
<<< Previous 6 Messages Goto Initial 10 Messages
From: Warp
Subject: Re: Stochastic Radiosity Patch for PoV 3.1g
Date: 29 May 2000 10:13:24
Message: <39327b04@news.povray.org>
Stephane Marty <alb### [at] wanadoofr> wrote:
: Don't you think there's a bit difference of realism, especially for the
: yellow box ?

  I can compare the two images very well by pressing alt+left (back) and
alt+right (forward) successively in Netscape. It changes between the images
very quickly making it very easy to see the differences in the images.

  I'm sorry but I can't see _any_ difference in the yellow box, no matter
how carefully I look.
  Well, in the right face, near the floor, I can see a couple of blotchy
spots which are missing in the megapov image. I can't say that these
blotchy spots are very realistic. They are probably caused by the low
sampling amount (300 if I remember right?).

  Instead, there's a big difference in the white wall. In the megapov version
it's quite well lit, with a reddish tint at the left side and a blueish tint
at the right side. Looks quite good to me.
  However, in the second image created by your patch this wall is pretty dark
and there's no visible color bleeding from the colored side walls.
  I have to say that I like more the megapov version of this wall. It just
looks better, and in my opinion more realistic.
  I think I know what's the problem: What's the recursion level of your
algorithm?

  I would like to see bigger versions of these images. For example 640x480.
And antialiased.

: However, the first rendering was twice as fast as the second.

  Well, this is another advantage of the megapov version. I suppose that if
you had used antialiasing the speed difference might have been even bigger.

-- 
main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
):5;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/


Post a reply to this message

From: Stephane Marty
Subject: Re: Stochastic Radiosity Patch for PoV 3.1g
Date: 29 May 2000 13:55:43
Message: <3932AE5B.4F71@wanadoo.fr>
Warp wrote:
> 
>   I'm sorry but I can't see _any_ difference in the yellow box, no matter
> how carefully I look.

What about the shading of the yellow box ?

>   Well, in the right face, near the floor, I can see a couple of blotchy
> spots which are missing in the megapov image. I can't say that these
> blotchy spots are very realistic. They are probably caused by the low
> sampling amount (300 if I remember right?).
> 
>   Instead, there's a big difference in the white wall. In the megapov version
> it's quite well lit, with a reddish tint at the left side and a blueish tint
> at the right side. Looks quite good to me.
>   However, in the second image created by your patch this wall is pretty dark
> and there's no visible color bleeding from the colored side walls.
>   I have to say that I like more the megapov version of this wall. It just
> looks better, and in my opinion more realistic.
>   I think I know what's the problem: What's the recursion level of your
> algorithm?

2.

>   I would like to see bigger versions of these images. For example 640x480.
> And antialiased.
> 
> : However, the first rendering was twice as fast as the second.
> 
>   Well, this is another advantage of the megapov version. I suppose that if
> you had used antialiasing the speed difference might have been even bigger.

Well, what is clear to me is that your opinion is a bit influenced by
something I don't understand.
Too bad.


Post a reply to this message

From: Warp
Subject: Re: Stochastic Radiosity Patch for PoV 3.1g
Date: 30 May 2000 07:02:50
Message: <39339fda@news.povray.org>
Stephane Marty <alb### [at] wanadoofr> wrote:
: Well, what is clear to me is that your opinion is a bit influenced by
: something I don't understand.
: Too bad.

  I don't think it should be so hard to understand.

  - Your patch certainly makes the so-called "color bleeding" more evident.
This, however, doesn't make the image look better or more realistic, only
kind of overexposed.

  - As seen in the two example images made with my scene, the brightness seems
to need some fixing. At least to me the megapov version looks more like it
should be (I'm talking about the white wall). If you look at the image created
with your patch and compare the brightness of the colored walls to the white
wall, there seems to be an odd discontinuity: The colored walls are well lit
while the white wall is quite dark. In the real word the light reflecting
from the side walls, the floor, the backwall and even the objects should make
the white wall more lit.

  - Your patch seems to have some graininess problem which is somewhat evident
in the example image in the www-page of the patch. If I understood correctly,
it happens when the sample count is too low. In megapov even an extremely
low sample count creates almost perfectly smooth illumination. It was mentioned
that your patch may need even 10 times more samples than megapov needs to
create a non-grainy image (80 samples vs. 800 samples).

  - Your patch is very slow compared to megapov. Even when megapov uses
recursion level 4 and your patch uses only recursion level 2 (which of
course reduces the quality), your patch took twice the render time of
megapov to get an image of approximately the same quality. Even then some
blotchy spots can be seen in some parts of the scene (probably due to the
low sample count?).
  Somehow I also have the feeling that using antialiasing would have made the
render time even longer compared to megapov (I may be wrong here, of course).

  - You haven't rendered the sample image at a higher resolution (eg. 640x480)
and somehow I have the feeling that using the same radiosity settings but
using higher resolution might cause graininess in the image (of course it's
only a hypotesis). Please correct me if I'm wrong.
  The radiosity in megapov is independent of the image size. You can render
that image at any resolution you want and you will probably not get any
graininess, blotchiness or whatever that doesn't appear in the small image.
  If I'm correct in my assumption then I think that you'll have to increase
the sample count for bigger resolutions thus making the rendering times
extremely long.
  (If I'm mistaken here, please forgive me.)

-- 
main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
):5;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/


Post a reply to this message

From: Margus Ramst
Subject: Re: Stochastic Radiosity Patch for PoV 3.1g
Date: 30 May 2000 12:53:14
Message: <3933E424.CAA4E23B@peak.edu.ee>
Warp wrote:
> 
>   The radiosity in megapov is independent of the image size. You can render
> that image at any resolution you want and you will probably not get any
> graininess, blotchiness or whatever that doesn't appear in the small image.

That's probably not entirely true. You would get the same amount of radiosity
detail in a larger image, but the inaccuracies would become more conspicuous.

-- 
Margus Ramst

Personal e-mail: mar### [at] peakeduee
TAG (Team Assistance Group) e-mail: mar### [at] tagpovrayorg


Post a reply to this message

From: Nathan Kopp
Subject: Re: Stochastic Radiosity Patch for PoV 3.1g
Date: 30 May 2000 13:23:01
Message: <3933f8f5$1@news.povray.org>
Warp <war### [at] tagpovrayorg> wrote...

>   - Your patch certainly makes the so-called "color bleeding" more
evident.
> This, however, doesn't make the image look better or more realistic, only
> kind of overexposed.

From what I understand, Mr. Marty's Stochastic model has the potential to
produce more realistic results than MegaPov.  MegaPov's approach sacrafices
a bit of realism for speed and good-looking results.

Actually, the two approaches are very similar.  Stephane's model gathers
samples from the scene for every intersection.  MegaPov, on the other hand,
only gathers samples between 1% to 10% of the time (or more, if higher
quality is required), and interpolates between these gather points to fill
in the missing data.  The result is a much smoother image.  The overall
"correctness" of the MegaPov solution should be very good, but dome detail
is lost because of the interpolation.  Fortunately, this loss of detail is
more natural and pleasing to the eye than the noise that is introduced by
other stochastic (monte-carlo) ray-tracing techniques.  The Radiance engine,
which is known for its realistic output, uses a technique similar to the one
employed by POV-Ray and MegaPov (cached & interpolated stochastic
gathering).  Unfortuantely, POV's radiosity code still contains some bugs,
often leads to splotchiness when the error_bound is decreased.

>   - As seen in the two example images made with my scene, the brightness
seems
> to need some fixing. At least to me the megapov version looks more like it
> should be (I'm talking about the white wall).

Again, we are talking about how it "should" be even though we don't really
know what it really should look like.  Until someone converts the Cornell
Box to POV format, we won't really know.

>   - Your patch seems to have some graininess problem which is somewhat
evident
> in the example image in the www-page of the patch.  If I understood
correctly,
> it happens when the sample count is too low. In megapov even an extremely
> low sample count creates almost perfectly smooth illumination.

The graininess exists because samples are taken for each intersection point.
MegaPov removes this noise by interpolating between multiple sampling
points.  MegaPov's indirect illumination is actually smoother than it should
be (but because there is no high-frequency noise, the image looks better).

>   - Your patch is very slow compared to megapov

Actually, I'm interested in how _fast_ it is, considering how much work it
is doing.  800 samples for

>   Somehow I also have the feeling that using antialiasing would have made
the
> render time even longer compared to megapov (I may be wrong here, of
course).

I believe that you are correct.

-Nathan


Post a reply to this message

From: Kari Kivisalo
Subject: Re: Stochastic Radiosity Patch for PoV 3.1g
Date: 30 May 2000 14:56:30
Message: <39340F3A.836652FA@kivisalo.net>
I got "Wrong editor dll version" error when running the exe.


-----------------------------------------------------------------------
Kari Kivisalo                                          www.kivisalo.net


Post a reply to this message

From: Kari Kivisalo
Subject: Re: Stochastic Radiosity Patch for PoV 3.1g
Date: 30 May 2000 14:58:54
Message: <39340FCB.8932E54A@kivisalo.net>
Nathan Kopp wrote:
> Again, we are talking about how it "should" be even though we don't really
> know what it really should look like.  Until someone converts the Cornell
> Box to POV format, we won't really know.

I did an approximation from the photo. See binaries.images.

-----------------------------------------------------------------------
Kari Kivisalo                                          www.kivisalo.net


Post a reply to this message

From: Stephane Marty
Subject: Re: Stochastic Radiosity Patch for PoV 3.1g
Date: 30 May 2000 17:59:11
Message: <393438EA.43E8@wanadoo.fr>
Kari Kivisalo wrote:
> 
> I got "Wrong editor dll version" error when running the exe.

What DLL do you have ? Mine are :
CMAX101		size 174080 Kb		date 09/09/1998
CMEDIT		size 694784 Kb		date 09/22/1998

Stephane Marty
- - - - - - - -
Computer Graphics Software
http://perso.wanadoo.fr/albedo


Post a reply to this message

From: Warp
Subject: Re: Stochastic Radiosity Patch for PoV 3.1g
Date: 31 May 2000 05:00:25
Message: <3934d4a9@news.povray.org>
By the way, I would like to apologize for attacking you so aggressively.
  It is not my intention to attack you or say that your work is worthless.
This kind of work is never worthless, all the contrary. Although it
certainly may sound like I don't appreciate your work, that's not true.
If people would not try algorithms and methods in patches we would not have
outstanding new features like photon mapping, isosurfaces and so on. These
are the result of people trying and making patches to see how do they work.
  I just tried to express my personal opinion, which can be sometimes quite
strong (and somehow I always manage to write in a form that sounds stronger
than I intended).
  Your work is very valuable and it's a good testbed for the algorithm you
used and I'm sure that something useful can be generated from it. I just
tried to express that, at least in the current form, I personally like more
the current megapov solution. It doesn't mean that your solution could not
be even better if some minor problems are optimized.

-- 
main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
):5;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/


Post a reply to this message

From: Stephane Marty
Subject: Re: Stochastic Radiosity Patch for PoV 3.1g
Date: 31 May 2000 17:16:03
Message: <3935804E.5AAA@wanadoo.fr>
Warp wrote:
> 
>   By the way, I would like to apologize for attacking you so aggressively.
>   It is not my intention to attack you or say that your work is worthless.
> This kind of work is never worthless, all the contrary. Although it
> certainly may sound like I don't appreciate your work, that's not true.
> If people would not try algorithms and methods in patches we would not have
> outstanding new features like photon mapping, isosurfaces and so on. These
> are the result of people trying and making patches to see how do they work.
>   I just tried to express my personal opinion, which can be sometimes quite
> strong (and somehow I always manage to write in a form that sounds stronger
> than I intended).
>   Your work is very valuable and it's a good testbed for the algorithm you
> used and I'm sure that something useful can be generated from it. I just
> tried to express that, at least in the current form, I personally like more
> the current megapov solution. It doesn't mean that your solution could not
> be even better if some minor problems are optimized.

Thank you.
I fixed 2 bugs in my patch since the public release, but it seems
there's a third one to solve. If the scene is too big, the hemisphere
sampling is uncorrectly distributed and the rendering becomes very
dirty...
I'm working on it.

Stephane Marty
- - - - - - - -
Computer Graphics Software
http://perso.wanadoo.fr/albedo


Post a reply to this message

<<< Previous 6 Messages Goto Initial 10 Messages

Copyright 2003-2023 Persistence of Vision Raytracer Pty. Ltd.