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

I got "Wrong editor dll version" error when running the exe.


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

Post a reply to this message

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

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

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

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