> Oh, and that's a beautiful render.  I love the square caustics on the sphere.
> No tweaking necessary.  Wow.  You should try triangles.  That would open up a
> world of possibilities, but then you'd certainly need some acceleration.  I
> guess that's already been accounted for in 5-1000004.  Sorry.  Keep it up.

Yeah, triangles and BSP acceleration are on the list. And definitely
closer to 5 than to 1000004 :)

Post a reply to this message

"Zeger Knaepen" <zeg### [at] povplacecom> wrote in message 
news:47cd94ea$1@news.povray.org...
> "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?
>

Unless they want the scene to look the same and use new features.


-- 
-Nekar Xenos-

Post a reply to this message

> Unless they want the scene to look the same and use new features.

#local Version=version;
#local Seed=seed(1);
#local NewRND=rand(Seed);
#version 3.6 #local OldRND=rand(Seed); #version Version

that should do it.  Advantages: no need for new keywords, and the 
possibility to use both the old and the new random-number generator in 1 
scene. Disadvantages: doesn't look as clean.

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

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

Yes, it seems the creators of Kerkythea knew about that - they included a scene
file of it in the distribution!

Here it is, rendered at 800x600 using its new network rendering feature on 2
threads on a C2D 2.5GHz and 1 thread on an AMD Athlon XP 2400+ (2.0GHz) for 3
hours and 40 minutes - about 150+150+100 passes in total, using unbiased Path
Tracing. You can see that it is still very noisy, this would not be quite so
noisy with BiPT or MLT.


Now I will try your scene again Severi with just Path Tracing (no MLT). I
already tried it using BiPT overnight (8 hours) and still there was a noisy
black area in the middle of the green glass boxes that was taking a long time
to go away (where they overlap the most).

I'll let you know if it takes more than 3 hours (using the same setup as for the
above WinOSi image) since after 3 hours I'll have to go to bed and leave it to
go for another 7.5 hours!

Post a reply to this message

Attachments:
Download 'illum2_pt_3h_40m.jpg' (110 KB)

Preview of image 'illum2_pt_3h_40m.jpg'

Severi Salminen wrote:
> You don't have to post the image but it would be interesting to know how
> quickly Kerkythea renders the same image with pure path tracing to about
> the same noise levels as my image.

Rendering now on 3 cores across 2 machines.


> At this point I describe the scene purely in the source code. I compile
> a new program every time I change the scene. But since my renderer has
> 2k lines of code it takes a fraction of a second to compile it :) Yes, a
> parser would be cool but:
>
> 1. I don't know what kind of SDL I want to support/implement.
> 2. I have never done a parser - besides a simple command line parameter
> parse. So this is a bigger learning process :)

I am a software developer by day so chances are I can extract the necessary
information from the section of source code that describes your scenes!

The Kerkythea parser uses XML to store the scene files. It can get pretty
messy.. but it might be a viable alternative (at least in the beginning) for
you? I don't mean the same layout as KT necessarily, but just some kind of XML?
Most languages should have a library for reading/writing XML by now...

As I write this I keep checking the render, even though the first pass is quite
noisy but still not so bad you can't make out the objects very clearly. I don't
know quite how long it will take to reach the same level as your image, my only
fear is that my bedtime might arrive before that time, and that the extra 7.5
hours it gets will take it well past that point.

We will see :)

Post a reply to this message

Attachments:
Download 'kuva11_pt_first_pass.jpg' (26 KB)

Preview of image 'kuva11_pt_first_pass.jpg'

Severi Salminen wrote:
>>   It's horribly ugly C code. I have made a clean C++ implementation if
>> you are interested.
> 
> Actually I'm interested.

http://warp.povusers.org/IsaacRand.zip

  If you want to increase the cryptographical strength of the RNG,
increase the value of RANDSIZL in the IsaacRand.hh file. According to
the author, values between 4 and 8 should be ok. The larger the value,
the (cryptographically) stronger the results (and the larger the cycle),
at the cost of the class taking more memory.
  (One instance of the class requires 4*4 + 4*2*2^RANDSIZL bytes. For
example with RANDSIZL 4 the amount of space required is 144 bytes, while
with RANDSIZL 8 it requires 2064 bytes.)

  According to the author, a value of 4 for RANDSIZL should be enough
for your purposes. You could try 5 or 6, though.

  (Curiously, as I found out recently, increasing this size actually
makes the RNG slightly faster. For instance, increasing RANDSIZL from 4
to 8 makes the RNG approximately 10% faster in my computer.)

> Do you know how it compares to Mersenne Twister speed-wise?

  Unfortunately I don't. However, I believe this RNG to be very fast,
especially taking into account the high quality of the results.

> I don't need 100% cryptographic robustness but fast
> generation and decent randomness for (say) 1280x1024x10x10000 numbers.
> (resolution * rays/pixel * passes). So the cycle must be a lot larger
> than that :)

  Increasing RANDSIZL increases the smallest cycle, but even with 4 I
think it's pretty large.

Post a reply to this message

Warp wrote:
>   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.

  Btw, I compared it to the std::rand() provided by gcc (in identical
conditions), and it could only produce about 33 million numbers per
second. This means that the isaac rng is over 4.5 times faster.

Post a reply to this message

sooperFoX wrote:

> Now I will try your scene again Severi with just Path Tracing (no MLT). I
> already tried it using BiPT overnight (8 hours) and still there was a noisy
> black area in the middle of the green glass boxes that was taking a long time
> to go away (where they overlap the most).


Naive question here, but do any of the existing unbiased renderers out 
there have any method that either a) kicks in at a certain point to try 
to detect noise and send a disproportionate number of rays into noisier 
parts of the image, or b) takes optional user input (even mid-render) 
and doing likewise?
Charles

Post a reply to this message

Warp wrote:

>> Do you know how it compares to Mersenne Twister speed-wise?
> 
>   Unfortunately I don't. However, I believe this RNG to be very fast,
> especially taking into account the high quality of the results.

Thanks for the code! Quick test shows that the two RNGs perform almost
identically. So I don't think I have a strong need to change the RNG.
Also the SFMT looks very promising:

http://www.math.sci.hiroshima-u.ac.jp/~m-mat/MT/SFMT/index.html

It should be a lot faster than basic MT which I'm using. But most likely
the random number generation is not a bottleneck anymore.

Post a reply to this message

Charles C wrote:
> b) takes optional user input (even mid-render) and doing likewise?

  That would be cool. If some part of the image is extra noisy, click
there and the renderer will then send more rays near that point. :)

Post a reply to this message