 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
William Tracy wrote:
> Oh, cool.
Thanks, I think it's cool too!
> Are you going to make the program available (e.g., Sourceforge) at some
> point?
>
I don't know. At this point, no. It is still too immature and lacks some
important features for any kind of release. And there are a lot better
open source brute force renderers available, like Luxrender, or PBRT.
My goal is to learn (good) C++ programming, to learn how (brute force)
ray tracing works and to implement it from scratch. If I have a fully
working program at some point I might even release it under GPL.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> 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.
Oh my gawd.
I'd have a new wallpaper if it wasn't because the image is too small for
my screen.
...bad excuse.
Scratch that. I have a new wallpaper.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Severi Salminen wrote:
> 4. Some kind of bounding box hierarchy acceleration system is needed.
Yeah, that's one of the biggest problems in raytracing, and rendering
in general.
Making a simple raytracer is a piece of cake. Making one which is fast
even with hundreds of thousands of objects is a lot more laborious.
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.
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.
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).
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> It's horribly ugly C code. I have made a clean C++ implementation if
> you are interested.
>
> 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).
How do the ugly C code and your clean implementation compare in terms of
performance? Pure curiosity.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Severi Salminen <sev### [at] NOT THISsaunalahtifiinvalid> 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.
What does POV-Ray use for random number generation? When I finally opened up
the source code, it looked like there were just arrays of tabulated numbers,
but then I plotted them and they certainly weren't random. Something like a
fractal. Still, would it be possible to precompute some random numbers, or is
the dependence on 'good' random numbers too strong? Oh, and GSL, the GNU
Scientific Library has a plethora of random number generators, but I haven't a
clue how fast they are. Perhaps possible to 'try before you buy' and test them
out before implementing them though.
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.
- Ricky
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Amazing to see your progress, man. How about implementing polygons already and
test it against known models like the Standford Bunny? :)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Severi Salminen wrote:
> My goal is to learn (good) C++ programming, to learn how (brute force)
> ray tracing works and to implement it from scratch. If I have a fully
> working program at some point I might even release it under GPL.
<digression>
I'll need to do a senior project next year for school. One of the things
I have been thinking about is building my own raytracer.
Since my raytracer would probably never see use in the Real World, it
would be interesting to push in some different directions that don't
make sense in the Real World.
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).
Actually, if I broke down and wrote the darn thing in Java, I might have
enough time to implement animation and clustering support before the
project ends. Then I could try to bribe the lab monitor to let me turn
all the computers in the labs into cluster nodes. ;-)
</digression>
--
William Tracy
afi### [at] gmailcom -- wtr### [at] calpolyedu
These may involve hunting down whoever added whichever thing it is and
torturing information out of them.
-- from the GCC Documentation Project's web page
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"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
|
|
| |
| |
|
|
|
|
| |
