Yeah! More 3d-shots!!!

(being sarcastic)

Thec

Interesting comment...
(being sarcastic)

A question guys, in which way do you use the cluster to speed up rendering: each PC has it's own geometry or you subdivide the screen and asign a region to each pc?

Seems that if you dubdivide the screen you may end with only 2 computers doing all de work while others only trace "a few rays", since all the geometry is concentrated in one part of the screen.

Oscar Blasco
oscar@asidesoft.com

you need six PCs to raytrace 3 cubes in realtime?

Well, that is why for example Maya hierarchically subdivides the screen into little rects, and using some algo it determines where the most time consuming parts on the screen are. And when just splitting up the work into parts on the screen, you can then still let both computers do first parts on the screen where there is actual geometry.
So that solves the problem you mentioned I think.

- John

You can also break things up in a more "random" way, like by assigning every pixel with an odd y coordinate to one computer and every pixel with an even y coordinate to another. Most graphics cards do something like this in order to evenly distribute the load between their rasterizers.

Max

Yeah, that's a cool idea too indeed.

- John

Why don't you use Athlons to render instead of Pentiums?
They are a lot faster and cheaper :)

The images are cool though, but what will be the purpose of real time ray tracing WITHOUT a 3d accellerator?

Do you have plan to use the Geforce 3 programmable logic for raytracing ?

nice,
louis

afaik there's no practical way to do raytracing in HW, not even with GF3..
but hey..
you should be able to trace that bareass simple scene on a single 400 mhz in realtime.. i can do that :)

Raytracing is a lot more efficient than normal DirectX or OpenGL Rendering (Can't remember the correct expression for that at the moment). I'm pretty sure the future lies in realtime Raytracing and designing an API for that is a very good idea and a step in the right direction :o)

cya,
Phil

One question I have is: how big are the images that are being raytraced in real-time? Times for raytracing are directly proportional to the size of the image. Another question is what's your definition of real-time? Several frames per second? 30 fps? 60 fps?

NeoKenobi: raytracing is really purely mathematical and can't take advantage of a lot of features of 3d hardware such as scan-conversion and what not. Typically, raytracers are implemented without any support from special purpose hardware. There's also practically no coherency between rays cast for different pixels which makes it a trivially parallel task although there are issues to consider such as granularity when dividing up the image.

I'm assuming that this is a fully functional raytracer and not the dumbed down versions that people claim are real-time raytracers. There's been work in the past on creating a parallel implementation of POVRay. Do you have any idea how your work compares to that implementation? Did you make your own special purpose message passing system or are you using something like PVM or MPI?

Well, actually, you dont need to create a new API for raytracing, you could use OpenGL API or DirectX API to render raytracing, since the only difference lies in how you render the poligons, but the api could be the same.

my two cents.

Sarwaz.

Thec, you're the smartest person I've ever known.
(being sarcastic)

Real-time Raytracing, that's catchy ;) But I doubt we'll see it in games anytime soon. Very cool though, good job.

What are you talking about? How do you do reflection/refractions in opengl? and what about perfect spheres?

yes, well. Dont take me wrong. I mean that you OpenGL (for example) could use a raytracer to render the poligons. Of course you would need to add some extensions to take advantage of the things that you can do with raytracing. But, for example, in terms of API you already have things like gluSphere (), which could be used to define "perfect spheres". And for the reflecions you just need a few more parameters in the materials...


Sarwaz.

Why use a raytracer for single triangles? I think that's pointless. The benefit of a raytracer is that you can use it on a whole scene and get things like shadows relatively easily.
OpenGL, as an immediate-mode API, doesn't know about scenes. It has some state, which can be as limited as the framebuffer, some variables to determine how things should be rendered (the matrices, the shading,...), and enough memory to contain all data for just one primitive. Yes, I know that in practical implementations, you can get better performance by grouping primitives, but in principle enough room for one primitive is enough.
OpenGL calls could be translated to scenes, by buffering all primitives into a scene and then raytracing that scene when some command is given. So you translate the scene internal to the program to simple graphics primitives, then translate those to a scene, and raytrace that. Seems like a waste to me.
Of course, this could fail in some cases. For example, an OpenGL program that draws an infinite amount of random triangles can't work in such a system.

awesome... RTRT rules.

can't wait for afrigraph (www.afrigraph.org), ingo wald will show his system there (8m triangle scenes, realtime).

Not trying to rag on anyone, but I distinctly recall having MUCH more complex scenes running at frame rates of about 5-10 fps back in 1996 on a 486dx4/100 .. and I distinctly recall other people doing the same. You'd think with six p3/650s you could do a little more than a box and a plane..

-goltrpoat

ahem, just a point: doesn't having a subdivision scheme hurt performance in rtrt if you have such simple scenes (come on, i can *count* the triangles), because of the overhead? also the networking must be a huge overhead in such a small scene...

i've implemented rtrt myself, and for such scenes it was not uncommon for me to get 15fps at 400x300 on my celeron2 750, so the acceleration structure and hardware supporting it might be slowing you down :)

Why should we discuss this topic now, the implementing of raytracing in games is years away.
Unless Nvidia decides to implement something like that in their new hardware, raytracing is useless for games. By the way, there isn't much difference in the way the details of a scene rendered by a ray tracing engine or an api. What the new Nvidia hardware (Quadro) can do is just amazing!

btw, i've written an article about rtrt, available online here (i think it's valid, not just a shameless plug):

http://www.cfxweb.net/article.php?sid=625

Extensions, of course. ;-)

i want hw accelerated fire before hw ray tracing ;)

Sorry if I offended anyone with my first post, what I really would like is more shots from gameboy advance, gameboy color, software rendering, new cool games there graphics isn't the prior thing, like the previous post befor this one etc.

I'm amazed by the content of the post, but I think we shouldn't start to lift up the bar to high, I would still like to see some less advanced code do some funky stuff, preferably on another platform than the PC.

I didn't mean to offend anyone, sorry.

Albert "thec" Sandberg
ICQ: 9901455, thec@home.se

nice

Just one little hint for those guys who are impressed by these simple scenes being rendered in realtime : Get "Heaven7" by Exceed and "Nature Suxx" & "Nature Still Suxx" by Foundation Against Nature (from the demoscene).

what I really would like is more shots from gameboy advance, gameboy color, software rendering, new cool games there graphics isn't the prior thing

Dude, this is software rendering...

Just a note: Something doesn't have to be the latest, greatest or even the best to be impressive.

It's just have to be at bit funky.

You guys might be complaining about the scenes - but a couple of things - A) They are rendering all these at once. B) They are less hacky than most of the recent demos (A lot of them trace a fair bit of the time at the corners of 8x8 tiles etc). C) The final thing - these are all triangles (not faster primitives) and they are done using OGL commands.

Not bad in my opinion.