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

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