William Tracy wrote:

> One idea I've had is using arbitrary-precision numbers for geometry
> (java.lang.BigDecimal comes to mind--I haven't yet looked into
> equivalent C/C++ libraries). The performance hit would make this stupid
> for Povray, but it opens up interesting ideas for massive scenes (Bill
> Pragnell's renderings of Ringworld gave me the original idea).

Hmm. What kind of "interesting ideas" you mean? Do you have any links to
sample images?

But anyway, go for it! You can't beat the feeling (ok, at least with
pants on...) you get from seeing your first rendering. It is so cool to
create worlds.

Post a reply to this message

Warp wrote:

>   POV-Ray is a prime example of a raytracer which has bounding box
> hierarchy optimizations: Render a simple scene with 10 spheres in a
> home-made raytracer and with POV-Ray, and the render times may be
> comparable. Render a scene with 100000 spheres with the home-made
> raytracer and POV-Ray and the Sun will probably die before the former
> gets the job done, while POV-Ray doesn't take significantly longer.

Very true. Now I have to check every single object with every single
ray. That is O(N) and that is way too much. I have to study BSP trees at
some point. And whatever other similar methods there are.

>   Btw, for a very good-quality and very fast RNG, you could also try
> this: http://burtleburtle.net/bob/rand/isaacafa.html
> 
>   It's horribly ugly C code. I have made a clean C++ implementation if
> you are interested.

Actually I'm interested. I remember reading about Isaac a few years ago
but missed it now. Do you know how it compares to Mersenne Twister
speed-wise? 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 :)

Most likely I'll implement my own class but if you care to show me
yours, that would be appreciated!

Post a reply to this message

> 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 don't remember exact figures but it was about a 8h render with some
2500 passes on one core (C2D@3GHz). Pure Monte Carlo path tracing with
no accelerations or fancy techniques. Just brute force :) (And pure
stupidity :)

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.

> 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!

Actually that is a very good replica of the scene! I'm impressed. And
impressed even more with the similarity of the render! Really, they look
very similar in all respects: the caustics, color bleeding, shadows,
everything. Of course your image has a bit more light but still, very
close. On the other hand, that is to be expected with unbiased
renderers. There should be no room for inaccuracies or interpretation.
MLT and Bi-directional are better (ie. faster) techniques and I'll also
try to implement at least the latter at some point.

> 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?

Thanks. I'll sure ask if I need more similar renders!

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 :)

Post a reply to this message

> 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