glass raytracer

Description
Here you can see a pic shot with my glass-raytracer. They are very (VERY!) soon, but my girlfriend likes 'em. Well, I like them, too, that's why I want to show them to you ;)

The colors are the visualized reflection vectors and the scene is made of simple spheres and planes. Recursive depth is, as I remember, 8 or 10. Rendertime on a Athlon XP 1800+, 512 MB DDR is 3-4 seconds in 1024x768. What else should I say at the moment....

A yep, the name is a recur-acro and means "glass of liquid and sour sauce" ( arghhhh...). Such a glass with such ingredients would produce nice reflections and refractions, not?

For more pictures and some additional info please visit http://greenhybrid.net or maybe if you speak german http://de.greenhybrid.net.

looks good.
having a raytracer and a girlfriend...i envy you

This message is sponsored by the Association Against Indolent Raytracing.
Everytime a duelling sphere-and-plane render takes more than a split second, a kitten dies

Seriously, given the amount of available papers/tutorials/source code on the topic there's no reason nowadays to be that slow. Please think of the kitten and use some acceleration structure, at this point anything will do the trick: ie bvh 5380840 spheres, 1024x1024 full 2x2 rgss, 7s, 100 lines. http://ompf.org/ray/sphereflake/

"Premature optimization is the root of all evil."

It sounds like he's only just started developing this and it may well be his first raytracer. Don't be too hard on him for performance...

I may well be obtuse but i totally fail to see how the use of an acceleration structure could be charaterized as premature optimization; it's not optimization even in the loosest acceptance of the term, it's fundamental.

The other point was that it doesn't take 2 gazillion line code to implement.

I've put some smileys in my initial post, but frankly with Jacco's 'Raytracing: Theory & Implementation' hosted on this very same site you could expect people to at least try to match that. No?

Well, I'm not going to argue semantics, and I don't disagree that acceleration structures are a necessity if you want to do anything more than a dozen or so objects; I just don't think he should be judged by the absolute performance of his raytracer, as he may not yet have the expertise needed to optimize it very much. The point of the image of the day isn't to say "hey, look at me, I can do xxx better than everyone else," but to say "hey, look at me, I learned to do something that I didn't know how to do before"...even if what you learned is something that other people with more experience would consider elementary.

Reedbeta: full ack. Apart from that, this is actually a raytracer image which looks different. This alone makes it interesting enough to post in my eyes. (it doesn't even contain a cornell box! )

Still, I consider the AAIR comment to be quite funny. But please don't exagerate it until we get into the late flipcode style..

to be exact, it's my second raytracer, the first one was years ago.
Okay now, I tested a 101-spheres scene in 1024x768 without further optimization of the tracer. it took 20 seconds (a shot of that scene has just been posted on my homepage), no refracts, no reflects, no kd's, no nothing, just putting 786432 rays into the raw scene.
Makes approx 5 spheres a second. Hey, the tracer has just reached the 500 line "milestone", I have not got deep into it yet, but go on, let hear from you, maybe I learn something new!

I'm sorry to insist but i've never discussed absolute performance or optimization, merely orders of magnitude; such a digression happened because of the initial author reported performance figures in the first place: if that wasn't meant to be discussed then what was the point?

I'm certainly not going to contest your IOTD criterion, that's your prerogative, but please there's a fine line between engaging into an e-penis contest and musing about the discrepancy between tutorial-with-source-code hosted on this site and this IOTD's features.

Love the image. Just went to your website and saw the image of the landscape with flowers and remember seeing it somewhere ages ago (was it on here? I don't remember). The way I see it with Ray Tracing is that either you are going for real time or your not. If you are, then optimise away, if not, I fail to see why its so important, if the idea is purely to render realistic images then what difference does it make if it takes 3 seconds or 30 (within reason of course, if it took days it would be no use to most people). Keep up the good work.

Reedbeta: I do know optimization structures (->root-engine, sooner iotd), I'm no absolute newbie (not new but unexpertised on raytracing, yep. I knew such comments will come, why did I just not wait some weeks before posting an iotd....).
Never mind, I just wanted to get some nice feng shui stuff online from a very, very young project.

Originally Posted by ray648

The way I see it with Ray Tracing is that either you are going for real time or your not. If you are, then optimise away, if not, I fail to see why its so important, if the idea is purely to render realistic images then what difference does it make if it takes 3 seconds or 30 (within reason of course, if it took days it would be no use to most people)

Without an acceleration structure intersecting rays is quadratic, so it's not about being realtime or not it's whether or not you'll remain forever secluded to trivial scenes: how many such realistic images can you produce with 3 spheres and a plane before you gouge your eyes?

And it may come as a surprise to you but you could use cycles you could have spared with those premature and useless 'optimizations' to compute an even more realistic image.

I really don't get that kind of argument but it seems the AAIR still has a long way to go

Originally Posted by tbp

Without an acceleration structure intersecting rays is quadratic...you could use cycles you could have spared with those premature and useless 'optimizations' to compute an even more realistic image.

No one's denying these facts. What I disagree with is that you seem to think that the OP's work is near-worthless because it doesn't (yet) include this standard feature of raytracers. Certainly, it's not much to get excited about, and someone with experience in raytracing might justifiably consider this post trivial. But if there are other 'newbies' out there just beginning in raytracing, this could be just what they need, e.g. to show them how to do some simple reflection/refraction. Anyway, if I have misinterpreted your viewpoint, then I apologize.

Also, I'm not really sure where you're going with the comment about Jacco Bikker's raytracing articles. Surely the fact that DevMaster hosts these articles doesn't mean every raytracer posted here should match his in performance?

Originally Posted by Reedbeta

But if there are other 'newbies' out there just beginning in raytracing, this could be just what they need, e.g. to show them how to do some simple reflection/refraction.

But this IOTD doesn't teach them how to do those reflections or refractions at all, there's no source code linked anywhere, no technical explanations. Nothing but a picture.

On the other hand with http://www.devmaster.net/articles/ra...ries/part2.php and http://www.devmaster.net/articles/ra...ries/part3.php those proverbial 'newbies' have a chance to grok what reflections and refractions are about; there's code, pretty pictures and explanations.

Originally Posted by Reedbeta

Surely the fact that DevMaster hosts these articles doesn't mean every raytracer posted here should match his in performance?

The initial author felt the urge to quote some performance figures in his IOTD blurb, again, if that's not meant to be discussed then what was his point? I'm merely putting things in perspective.

I'm not saying the OP's work is worthless, but it certainly doesn't have the virtues you've credited it with and i wish, given the availability of pedagogical material on this topic on this site and the gap between what they teach and what this IOTD acheives, that the OP had done a little bit more work before hitting the submission button.

I think this IOTD is pretty good. It shows an artistic side of the author, since most RT shots I’ve seen were simple box rooms. This screenshot has a nice warm feeling to it. I look forward to seeing it improved, with more objects and textures.

BTW, raytracers and performance is an oxymoron. We all know rasterization is the winner here =P

Originally Posted by TheNut

BTW, raytracers and performance is an oxymoron. We all know rasterization is the winner here =P

Trolling for trolling, on behalf of the AAIR, i welcome you to 2005.
http://www.sci.utah.edu/~wald/Public...d//dirmaps.pdf

Isn't it 2006 already?

I'm with TheNut , some of you ray-tracers are a bit too intense for me!

I spose you'd prefer my raytracer. About 3.5M ray-triangle tests per second. EDIT: On a 1ghz pentium. But honestly people, watching a single triangle go past in real time is not that engaging. The pics cool, lets leave it at that.

Originally Posted by Razor

I spose you'd prefer my raytracer. About 3.5M ray-triangle tests per second. EDIT: On a 1ghz pentium. But honestly people, watching a single triangle go past in real time is not that engaging.

Finding which triangle/primitive to intersect is what's quadratic without an acceleration structure, not intersecting.

I'm unmoved by your numbers because a good ray/triangle intersection test - Wald, Pluecker - would be 3x faster (in the order of 400 cycles for 4 rays) and those intersection tests being an order of magnitude slower than a single traversal step for that same packet you'd really be trying as hard as you can to avoid them, ie by producing a better acceleration structure or smart culling; then you would be sustaining 3.5M fully shaded ray/s against a large scene. Or more.

What i'm really trying to say is the raytracing field wasn't frozen over 30 years ago: you can write a recursive sphere-and-plane raytracer in a few lines, or a bubblesort. The question is, have you used a bubblesort lately?

Originally Posted by tbp

I'm unmoved by your numbers because a good ray/triangle intersection test - Wald, Pluecker - would be 3x faster (in the order of 400 cycles for 4 rays)

I never said it was good, it only took me a couple of days while learning SSE intrinsics (would have used inline asm, but then gcc only liked using 1 register). And I must have been having a bad day, cause I'm getting about 5M now. Probably left the compiler running in the background or something equally dumb. That's still including ray generation and all that. The point is, for a similar amount of time as this guy seems to have put in, going for speed is not nearly as interesting. Not all of us are l33t enough to be at the forefront of realtime raytracing you know. But you seem to know all about it, so how about an iotd?

Originally Posted by Razor

Not all of us are l33t enough to be at the forefront of realtime raytracing you know.

My point is more: what makes you think it should be restrained to the realtime kind?
IE quickly building, or traversing, a decent BVH doesn't take many line code (see earlier post) or cycles and gets you out of the quadratic domain; you still have the option of shooting packets and whatnot, but that's just an option.
And it implies 0 approximations.

Originally Posted by Razor

would have used inline asm, but then gcc only liked using 1 register

You prolly got your constraints wrong, they are tricky to get right. It's damn hard anyway to beat gcc at his own game.

Originally Posted by Razor

But you seem to know all about it, so how about an iotd?

I'm certainly not omniscient. I don't see the point of pretending to an IOTD when it wouldn't exhibit any more features than what Jacco has already demonstrated right here (hey mom! look at me, i'm faster!).
Now if/when i finalize my fast kd-tree compiler i'll think about it.

If you're interested in benchmarking your rt against various implementations, we have a data set and a a set of rules right here: http://ompf.org/forum/viewtopic.php?t=64

i like the pics very much!! _really_ pretty! (now the high-res versions should have some nice antialiasing to make them more smooth.. because thats the nice thing about them: they look very smooth)