"Warp" <war### [at] tagpovrayorg> wrote in message 
news:47cc7714@news.povray.org...

>  I measured the algorithm (compiled with g++ 4.1.2), and with my
> computer (Pentium4 3.4GHz) it generated 150 million random numbers per
> second. According to the author the randomness should be of very high
> quality (cryptographically strong).

Maybe this is a stupid question, but here it is: Is this implemented in 
Pov-Ray's "rand" function? If not, can it be implemented in future versions?


-- 
-Nekar Xenos-

Post a reply to this message

Nekar Xenos wrote:
> Maybe this is a stupid question, but here it is: Is this implemented in 
> Pov-Ray's "rand" function?

  Nope. POV-Ray's rand() uses a very simple linear congruential
generator (with period 2^32).

> If not, can it be implemented in future versions?

  The idea has crossed my mind, and I have been intending to ask the
team about it, but I have not yet got to actually do it.

Post a reply to this message

Nicolas Alvarez wrote:
> How do the ugly C code and your clean implementation compare in terms of
> performance? Pure curiosity.

  The C++ version generates approximately 151M numbers/s, while the
original C version generates, in the same conditions, approximately 167M
numbers/s.

  Maybe I could try profiling the program to see what is causing the
slight delay in the C++ version.

Post a reply to this message

Warp wrote:
> Nicolas Alvarez wrote:
>> How do the ugly C code and your clean implementation compare in terms of
>> performance? Pure curiosity.
> 
>   The C++ version generates approximately 151M numbers/s, while the
> original C version generates, in the same conditions, approximately 167M
> numbers/s.

  Oops, scratch that. The conditions were not the same, after all (I had
configured the two versions to use differently sized arrays).

  Configuring both to use the exact same settings resulted in both being
equally fast (that is, approximately 151M numbers/s), so there's no
difference in speed. (I didn't expect there to be.)

  (Curiously, though, this showed me that increasing the array used by
the algorithm, while it requires more memory, makes the algorithm
slightly faster. More precisely increasing the array size from 16 ints
to 256 ints makes the algorithm about 10% faster.)

Post a reply to this message

Hi Severi,

Your renderer is truly great! How long did you let it run on that image, and how
many passes/iterations did it do in that time?

I have lately been playing around with Blender and rendering with Kerkythea
2008, which supports several brute force rendering methods: Path tracing,
bi-directional path tracing (BiPT) and Metropolis Light Transport (MLT) (two
methods built on top of each of the two path-tracing methods).

I didn't have your scene data so I just improvised by eye.. attached is a render
using MLT on PT, that I let run for 1h 20m, in which time it did about 65
iterations. It isn't an exact match, obviously, since I got the spacing a bit
wrong, but I can see that our renderers agree on all the right light in all the
right places!

(btw I was using 2 threads on a Core2 Duo 2.5GHz (2 cores), running WinAmp and
browsing news.povray.org at the same time ;)


Also in the future if you would like me to run any other comparisons I would be
happy to oblige. It would be nice if I could use the same geometry as you -
sphere coordinates and radii, etc. How do you define your scenes?

Cheers
sooperFoX


Severi Salminen wrote:
> Here is a new render. Now with boxes and properly working total internal
> reflection (you can see the windows through green glass, for example).
> Everything looks pretty good to me: shadows, highlights, caustics etc.
> The "windows" are actually only light emitting boxes. I also stopped
> using the infamous C rand() and implemented Mersenne Twister RNG. It is
> a lot faster (some 20-30% faster rendering) - and there is even faster
> variation available.
>
> Next:
>
> 1. Wait till "the Bible" arrives in mail. "Physically based rendering",
> by Matt Pharr and Greg Humphreys.
> 2. Implement basic transformations.
> 3. Improve box intersections stuff.
> 4. Some kind of bounding box hierarchy acceleration system is needed.
> 5.- 1000004. Million other things.

Post a reply to this message

Attachments:
Download 'kuva11_mlt_pt_1h_20m.jpg' (116 KB)

Preview of image 'kuva11_mlt_pt_1h_20m.jpg'

> Nekar Xenos wrote:
>> Maybe this is a stupid question, but here it is: Is this implemented in 
>> Pov-Ray's "rand" function?
>> If not, can it be implemented in future versions?
> 
>   The idea has crossed my mind, and I have been intending to ask the
> team about it, but I have not yet got to actually do it.

Well, it would have problems with backwards compatibility: changing the 
random number generator would make existing scenes look different, as if 
they had changed the seed. So we probably need something like 
global_settings { random_generator 2 }

Post a reply to this message

> Also in the future if you would like me to run any other comparisons I would be
> happy to oblige. It would be nice if I could use the same geometry as you -
> sphere coordinates and radii, etc. How do you define your scenes?

Somebody should make that scene in a format we all know (like POV SDL 
with no #directives).

Also, could you please test this one? :)
http://www.winosi.onlinehome.de/Gallery_t14_01.htm

Post a reply to this message

"Nicolas Alvarez" <nic### [at] gmailisthebestcom> wrote in message 
news:47cd674d$1@news.povray.org...
> Well, it would have problems with backwards compatibility: changing the 
> random number generator would make existing scenes look different, as if 
> they had changed the seed. So we probably need something like 
> global_settings { random_generator 2 }

..or just let people use the #version-directive

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 escribió:
> "Nicolas Alvarez" <nic### [at] gmailisthebestcom> wrote in message 
> news:47cd674d$1@news.povray.org...
>> Well, it would have problems with backwards compatibility: changing the 
>> random number generator would make existing scenes look different, as if 
>> they had changed the seed. So we probably need something like 
>> global_settings { random_generator 2 }
> 
> ..or just let people use the #version-directive

People might still want the old generator for some strange reason :)

Post a reply to this message

"Nicolas Alvarez" <nic### [at] gmailisthebestcom> wrote in message 
news:47cd8bee@news.povray.org...

>> "Nicolas Alvarez" <nic### [at] gmailisthebestcom> wrote in 
>> message news:47cd674d$1@news.povray.org...
>>> Well, it would have problems with backwards compatibility: changing the 
>>> random number generator would make existing scenes look different, as if 
>>> they had changed the seed. So we probably need something like 
>>> global_settings { random_generator 2 }
>>
>> ..or just let people use the #version-directive
>
> People might still want the old generator for some strange reason :)

yes, and those people can use the #version-directive, I don't see the 
problem?

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