Hello,

I created a web page for the release of my MegaPov patch (support of a basic
montecarlo path tracing feature) :
http://pagesperso-orange.fr/fidos/MCPov/MCPov.html.

I put basic documentation, the source code modification and a binary for Windows
(only tested on Intel CPU).

A feedback on the Linux compilation and the test of the Windows binary on a AMD
CPU is interesting feedback.

Any comments wellcome.

Regards,
Fidos.

Post a reply to this message

fidos <fid### [at] wanadoofr> wrote:
> http://pagesperso-orange.fr/fidos/MCPov/MCPov.html.

  Are you using the C rand() function to generate random numbers? That
function is of completely subpar quality and quite slow.

  You should use a fast high-quality RNG, such as for example
http://warp.povusers.org/IsaacRand.zip

  (That RNG generates very high-quality random numbers with an enormous
period and it's over twice as fast as the rand() in the gcc C library.)

-- 
                                                          - Warp

Post a reply to this message

Thanks!  Very exciting.  Some minor hiccups on compiling on Intel Mac OS X
10.5.2 with gcc 4.0.1, which should be a decent measure of compiling on Linux.
Just a few quick fixes and it compiles just fine, although I haven't actually
tested it yet.  Here are the errors, unabridged:

 - Ricky





In file included from render.cpp:55:
optout.h:69:1: warning: "DISTRIBUTION_MESSAGE_2" redefined
In file included from ../unix/config.h:91,
                 from frame.h:58,
                 from render.cpp:44:
.../conf.h:14:1: warning: this is the location of the previous definition
In file included from rendctrl.cpp:66:
optout.h:69:1: warning: "DISTRIBUTION_MESSAGE_2" redefined
In file included from ../unix/config.h:91,
                 from frame.h:58,
                 from rendctrl.cpp:41:
.../conf.h:14:1: warning: this is the location of the previous definition





make[3]: *** [render.o] Error 1
make[3]: *** Waiting for unfinished jobs....
make[2]: *** [all-recursive] Error 1
make[1]: *** [all-recursive] Error 1
make: *** [all] Error 2


g++ -DHAVE_CONFIG_H -I. -I. -I..  -I.. -I../source/base -I../source/frontend
-I../source/patches -I../unix -I../libraries/png -I../libraries/tiff/libtiff
-I../libraries/tiff/libtiff -I../libraries/jpeg -I/usr/X11/include   -pipe
-Wno-multichar -s -O3 -ffast-math -malign-double -minline-all-stringops
-march=i686 -mtune=i686  -c -o montecarlo.o montecarlo.cpp



















make[1]: *** [montecarlo.o] Error 1
make: *** [all-recursive] Error 1

Post a reply to this message

Oops.  Don't have time to investigate the cause right now so this probably isn't
of much use, but:

....

Rendering Warning: Start_Non_Adaptive_Tracing_one_pass(65) n=5000/10000
Possible Rendering Error: libpng: buffer error
Rendering Error: Cannot write PNG output data to /Users/***/Downloads/mctes
t/sky.png.
Segmentation fault


Do I need to use the windows/pvbmp.cpp file?  I didn't...

 - Ricky

Post a reply to this message

> Do I need to use the windows/pvbmp.cpp file?  I didn't...
The modification is necessary because it allow to wrap the current drawing line
when a pass is finished (and to restart at the top of the bitmap).

I will check how it is handled on Linux (MAC OS X is perhaps similar).

Fidos.

Post a reply to this message

"fidos" <fid### [at] wanadoofr> wrote:
> > Do I need to use the windows/pvbmp.cpp file?  I didn't...
> The modification is necessary because it allow to wrap the current drawing line
> when a pass is finished (and to restart at the top of the bitmap).
> I will check how it is handled on Linux (MAC OS X is perhaps similar).

Thank you very much for all your effort.  The binary works if I boot up in
Windows XP (knew I kept that around for something!), but I don't have any luck
with the gui.  It still renders just fine, but when I open it, it tells me
"Editor DLL initialisation failed [LoadLibary failed, code is 0000007e]," and
most of the buttons and menu items are disabled.  Probably due to my ignorance
of Windows.  You must have been dreading releasing this so you could watch the
errant bug reports and questions start flowing in...

So here's a question at least.  Is there a reason the following scene renders so
differently with the three different options?  Cases one and three produce the
smooth focal blur I would expect, but case 2 produces a sharp cutoff.  I have
tried to boil this down to the simplest scene that causes unexpected behavior,
but I just can't see what the problem is.

Again, I'm only trying to be helpful and really do appreciate your hard work.
Please let me know if you'd like either more or less input.  It seems unfair to
pile all the issues on you when I should probably, time permitting, figure out
the source myself.

 - Ricky


/* FOCAL BLUR TEST SCENE */

global_settings{
    montecarlo{
        mc_rand_seed
        mc_dof{mc_focal_distance 5.0 mc_lens_radius 0.5}
    }
}

default{finish{montecarlo{mc_diffuse{1 3 1}}}}

camera{
    location <0.0,1.0,-5.0>
    look_at y*0.5
}
sphere{0,1000
    pigment{rgb 1}
    finish{
        diffuse 0
        ambient 0.8
    }
}

#declare test_case = 2;

#switch(test_case)

    #case(1)
        box{<-100,-1,-10>,<100,0,100>
            pigment{rgb <0.9,0.7,0.2>}
        }
    #break;

    #case(2)
        box{<-100,-1,-10>,<100,0,100>
            pigment{rgb <0.9,0.7,0.2>}
        }
        sphere{y,0.01}
    #break

    #case(3)
        plane{y,0
            pigment{rgb <0.9,0.7,0.2>}
        }
        sphere{y,0.01}
    #break

#end

Post a reply to this message

"fidos" <fid### [at] wanadoofr> wrote:
> Hello,
>
> I created a web page for the release of my MegaPov patch (support of a basic
> montecarlo path tracing feature) :
> http://pagesperso-orange.fr/fidos/MCPov/MCPov.html.
>
> I put basic documentation, the source code modification and a binary for Windows
> (only tested on Intel CPU).
>
> A feedback on the Linux compilation and the test of the Windows binary on a AMD
> CPU is interesting feedback.
>
> Any comments wellcome.
>
> Regards,
> Fidos.

This is a fantastic news!
At first glance the documentation seems very good.
I look forward to experiment with MCPov.

Post a reply to this message

Warp <war### [at] tagpovrayorg> wrote:
> fidos <fid### [at] wanadoofr> wrote:
> > http://pagesperso-orange.fr/fidos/MCPov/MCPov.html.
>
>   Are you using the C rand() function to generate random numbers? That
> function is of completely subpar quality and quite slow.
Yes
>
>   You should use a fast high-quality RNG, such as for example
> http://warp.povusers.org/IsaacRand.zip
I downloaded the package. I will make a try. In fact, I never profile but I have
the feeling that in a complex scene, it is in the intersection routines that it
spend most of the time. Nevertheless, better and faster routine is good
improvement.

Thanks you.

Fidos

Post a reply to this message

there seems to be an error with png-output, I get ridiculously large files 
(a 64x64 rendering of the cornell-box gives me a 65MB png, or a 13KB BMP), 
and after a few iterations (ranging from 10 to 300, so far), I get the 
error-message:
"
Possible Rendering Error: libpng: buffer error
Rendering Error: Cannot write PNG output data to [outputdir]
Possible Rendering Error: Cannot write PNG data.
Possible Rendering Error: Cannot write PNG data.
Possible Rendering Error: Cannot write PNG data.
"

followed by the scene processing times and POV-Ray proclaiming it has 
finished

I'm using a slightly modified version of sample_08.pov (changed montecarlo 
{ mc_diffuse { 1 2 2 } } into montecarlo { mc_use_cosine_distrib mc_diffuse 
{ 1 1 1 } }) on an AMD Athlon64 X2 5600+ with 2GB RAM, running under Windows 
XP SP2

cu!
-- 
#macro G(b,e)b+(e-b)*C/50#end#macro _(b,e,k,l)#local C=0;#while(C<50)
sphere{G(b,e)+3*z.1pigment{rgb G(k,l)}finish{ambient 1}}#local C=C+1;
#end#end _(y-x,y,x,x+y)_(y,-x-y,x+y,y)_(-x-y,-y,y,y+z)_(-y,y,y+z,x+y)
_(0x+y.5+y/2x)_(0x-y.5+y/2x)            // ZK http://www.povplace.com

Post a reply to this message

"Zeger Knaepen" <zeg### [at] povplacecom> wrote:
> there seems to be an error with png-output, I get ridiculously large files
> (a 64x64 rendering of the cornell-box gives me a 65MB png, or a 13KB BMP),
> and after a few iterations (ranging from 10 to 300, so far), I get the
> error-message:

That's the same thing I get, but I think the answer is just that png output is
not really supported yet.  Since it renders in passes, the BMP output has been
altered so it overwrites the image, rather than appending.  Solution?  Use BMP
for now?

 - Ricky

Post a reply to this message