Quake III Gets Real Time Ray-Tracing Treatment

Ozh writes "Did you ever wonder what you could do with a cluster of 20 AMD XP 1800s? Some German students and videogame fans did, and their answer has been what they call 'ray-tracing egoshooters', an entirely raytraced game engine which 'runs about 20 fps@36 GHz in 512x512 with 4xFSAA'. The first game to get this treatment is Quake 3 Arena : the screenshots look slightly better than the original 3D engine but the video (56 Mb, 3'19) is quite dramatic."

Comments

Does it make full use of GPUs?

[reality-bytes]

Its a bit hard to tell from the page whether this makes full use of the GPUs per box in the cluster like Chromium

They do also mention that it can render entirely in software over the network at 20FPS - not bad considering that each fram portion of the data has to pass across presumable 2 machines before it is passed to the display!

36Ghz

[Anonymous Coward]

runs about 20 fps@36 GHz in 512x512 with 4xFSAA'

I want whatever computer they're using to test this.

Kinda cool

[Anonymous Coward]

That's pretty nice. Unfortunately most of the effect can be simulated using tricks and still run on a regular computer. Especially with all the stuff you can do on the GPU now.

They need to soften the shadows also. Either by using tricks or radiosity. Right now it looks kinda meh...

Interesting effort though.

Re:Kinda cool

[Anonymous Coward]

They have realtime soft-shadow rendering in the movie clip, though it's only seen from a character models cast shadow that I noticed.

Re:Kinda cool

[Arngautr]

yeah radiosity, good idea, so how many comps for 20 fps then? One should be able to cache the shadows on the inanimate objects though.

Re:Kinda cool

[Have Blue]

The real-time curved reflective surfaces (true reflection, not cube mapping) and displacement surfaces currently cannot be done on 3D cards.

Re:Kinda cool

[Anonymous Coward]

you sure about displacements? I kinda thought they were emerging on the new cards/progs?

Re:Kinda cool

[xmas2003]

HEY ... when you are done playing games (i.e. leave at night ... if you don't stay up all night playing! ;-) ... can you turn that cluster of 20 AMD XP 1800s to do some processing for a "do-gooder" cause such as Folding@HOME - my Google Compute team would love to get a boost from that type of horsepower! ;-)

Re:Kinda cool

[TheLink]

You want to calculate stuff fast? Maybe you should ask google.

Perhaps Google will have a Google free day, where for the whole day their 100K computers do Folding@HOME or something else other than google search. :).

1800Mhz x 20 = approx 36Ghz

[reality-bytes]

If you read the article on slashdot properly; it tells you that ;)

Re:1800Mhz x 20 = approx 36Ghz

[Anonymous Coward]

Damn, I don't know how I missed that part. I just assumed it was one computer and they forgot a decimal... I'll try to RTFA better next time. :)

Re:1800Mhz x 20 = approx 36Ghz

[Drathos]

Well.. I'm not sure where the summary got it's specs of AMD XP 1800s, but they are not 1.8 GHz processors. They run at 1.533 GHz. That makes it 30.66 GHz (assuming the 20 computers). Looking at the site, there's absolutely no specs on the system aside from the 36 GHz number:

..(about 20 fps@36 GHz in 512x512 with 4xFSAA)

Re:1800Mhz x 20 = approx 36Ghz

[CityZen]

You didn't look at the downloads page:

> This is realtime speed for a virtual intel CPU with about 36 GHz (to be more precise: a cluster with 20 AMD XP1800 was used).

Freecache link for the video

[42forty-two42]

Freecache link. This should hopefully be faster. Anyone have a torrent?

Re:Freecache link for the video

[Vaevictis666]

Just an FYI, it seems that freecache just does a passthrough on AVI files. I tried doing the freecache thing, but firefox keeps showing up as saving it from the original host.

And besides, I'm _still_ getting over 100k/s (it was 115 when story first posted, now at 105) so we're collectively not doing the greatest job of slashdotting them anyways.

Re:Freecache link for the video

[WhatAmIDoingHere]

Usually things posted to Games that doesn't get on the first page don't get /.'ed.. Shame, though.. We should try harder.

Nice links there

[complete loony]

Somebody didn't notice the frameset...
Screen Shots
Downloads (video)

raytracing downsides?

[Ender Ryan]

Ok, so this is pretty neat. The screenshots look pretty nice, and I'm downloading the video(ISDN, bleh), but what I really find interesting is the mention of a hardware raytracing GPU, and a link to a working prototype.

So my question is, for those of us who don't know the first thing about 3D graphics, what are the pros and cons of a raytracing GPU, compared to the polygon pushers we currently know and love.

Re:raytracing downsides?

[xenocide2]

Well, its known to be slower in implementation. It also forces lighting on the rendering. After all, we're tracing rays of light, here. But in theory, raytracing is where the future resides. I'm told, though I don't fully understand the logic behind it, that raytracing should scale to higher poly scenes than rasterizing. The big problem it seems is that its difficult to find hacks to speed up rendering. Most speed enhancements are data restructuring, like subregion partitioning. The idea being that if a ray doesn't intersect a region, it can't intersect anything in the subregion and you don't need to test it.

The real benefit is free occulsion culling, shadows, lighting, reflections, and essentially a physical simulation of how things actually work in life. There's been a few boards prototyped to do ray-tracing. Just google for Real-Time Raytracing. The paper behind it suggests that a hardware raytracer scales nearly linearly with the amount of tracer units behind it. These days its difficult to take a hardware prototype and beat the market standard with a wholly different paradigm, especially when the benchmark is OpenGL based. OpenGL only provides for 4 light sources, and little point. The prototype that exists is incredibly large and not well suited to current small desktop cases. But given the right set of talent, this is an interesting concept that could prove to take over poly pushers eventually.

Re:raytracing downsides?

[0x0d0a]

I have a comment a bit further down with some more explanation.

I remember seeing an SGI demo of real-time raytracing. They used a kinda neat technique -- the application was a modelling app, and so they "faded" the new image in by rendering random pixels. It let them get away with far fewer FPS.

Re:raytracing downsides?

[cgenman]

what are the pros and cons of a raytracing GPU, compared to the polygon pushers we currently know and love.

Raytracing is generally more expensive than traditional polygon based graphics. You get more realistic curvature, far more realistic lighting, (including incidental light, diffuse light, etc), reflections, deflections / transparencies (such as those glass balls everyone loves), etc, etc, etc.

When Pixar goes rendering, Pixar raytraces. When Cameron goes rendering, Cameron raytraces.

The downside is that raytracing is a total resource hog. Essentially, for every pixel on the screen you trace the path of the light backwards, discovering every incidental surface and light source that might be effecting it along the way.

Polygon algorithims put stuff immediately to the screen, only going so far as to cull the faces that aren't visible to the camera. This is a lot more efficient for today's graphics, and will be far into the future.

And every time we get a step closer to using realtime raytracing, we get better polygon altorithims. First we had flat polygons, then we had colored vertexes, now we texture a character based upon averages of the normals of the surrounding vertexts, creating seamless skins. Originally we had no light, then a baked in faked lighting, now we have multiple light sources with multiple faked shadows on a baked environment. Glass and mirrors, once unheard of in a videogame, are now common. We even sample textures over a given area to try and get a more accurate per pixel representation.

So to answer your question, a raytracing GPU would have to be bloody powerful to do what you can do today with a polygon engine in realtime. Again, everyone thinks we'll get there someday, and there is no doubt in my mind that we will, but a realtime raytraced commercial game is such a distant possibility as to be a lifelong aspiration.

Re:raytracing downsides?

[jonadab]

> So my question is, for those of us who don't know the first thing about 3D
> graphics, what are the pros and cons of a raytracing GPU, compared to the
> polygon pushers we currently know and love.

Raytracing requires a good deal more out of your hardware. They're running a
twenty-node cluster and only getting 20 fps, and I bet they're not even doing
some of the fancier tricks raytracing is capable of doing. So the downside is,
raytracing is slower, a *lot* slower on the same hardware.

The advantages to raytracing are threefold: 1. It looks better. 2. It looks
better. 3. It looks better.

For still images, raytracing is definitely the way to go. If you've never had
a serious look at it, go over to www.irtc.org and flip through their gallery.

IMO, it's only a matter of time before games adopt realtime raytracing, but it
may be quite a bit of time yet, perhaps 20 years or so before it really goes
mainstream. Because, let's face it, 20 fps isn't really playable, and they
wouldn't even be getting that kind of speed if they weren't cutting some fairly
significant corners (probably disabled things like refraction and focal blur
and area lights, unless I've missed my guess), and it's going to be a few
months yet (ahem) before the average gamer has a twenty-node cluster.

But it will come in time.

Re:raytracing downsides?

[photon317]

A freind of mine wrote a real time raytracing engine as an assembly demo on an 80386 back in 1993 or so. Doing "real time raytracing" isn't that hard, it's doing it with complex objects, lots of light sources, and high resolution, that becomes a problem. IIRC, his was in 320x240, and was only rendering half the lines on the screen (effectively 160x240), and the scene was just moving through a dullish rocky martian landscape with a setting sun as the only lightsource.

My point being, it's not a great feat to do realtime raytracing, it's just a great feat to harness enough hardware power or come up with enough optimization tricks (without cheating and make it of lesser quality than a real raytrace) to do big nice-looking things with it.

Re:raytracing downsides?

[jackbird]

When Pixar goes rendering, Pixar raytraces. When Cameron goes rendering, Cameron raytraces.

No, they don't. At least not when they can help it. Renderman didn't even have raytracing capabilities last time I looked, which admittedly was a while ago - for scenes that absolutely need it, "frankenrenders" using mental ray or BMRT were the order of the day.

You can do a hell of a lot with reflection mapping and custom shaders in a lot less time.

Re:raytracing downsides?

[Anonymous Coward]

If you're only rendering a heightfield (e.g. a martian landscape) you can make a number of assumptions that you can't make in a general-purpose raytracer. This is going to improve performance significantly.

Re:raytracing downsides?

[j1ggl3x]

People have been giving good pros and cons to ray tracing, but I haven't seen a comment explain what it is. Now it's been awhile since my graphics course (so this may be terribly wrong), but from what I remember raytracing works something like this:

1. Imagine a ray shooting out of your eye through each pixel on your screen. So ray shoots into the 3D world and it might hit an object. The purpose of the ray is to collect light information.

2. If it hits an object, it will bounce off at a certain angle (depending on the object). After it bounces around a couple times, it might eventually hit a light source or you might set a limit to how many times it can bounce. Each time it bounces off an object, it might lose some intensity depending on the surface of the object.

3. After all the bouncing, it collects light information (depending on what it hits, the surface, the lighting) and now that pixel now has more accurate light info for rendering.

What this allows is much more realistic mirrors, reflections, lightings, shadows, etc. but as you can imagine, bouncing off all those rays takes lots and lots of computation. Radiosity was mentioned, and that's basically shooting millions of rays FROM the light sources first (instead of from the users eye to each pixel). But again, lots of calculations.

If you're wondering how current games look so good without raytracing, it's due to lots of clever hacks and simulations for lighting/shading. Raytracing is kind of a brute-force/realistic method. Hope that helps someone...

Re:raytracing downsides?

[kiza]

Have a look at this real time RT demo (http://www.pouet.net/prod.php?which=9461) from 10 years later. Breakpoint'03. :)

Re:raytracing downsides?

[Belisar]

> Radiosity was mentioned, and that's basically shooting millions of rays FROM the light sources first (instead of from the users eye to each pixel). But again, lots of calculations.

Actually, that would be light tracing, which is rather different from radiosity. In radiosity, the scene is divided into small surfaces (patches) of approximately the same size, then the lighting distribution by diffuse interreflection is calculated. This does not have anything to do with ray tracing (ok, you can do it stochastically with ray tracing, but the base algorithm actually solves a large system of linear equations).

Since the output of an radiosity algorithm is lighting data, it can well be used as a precalculation step for a normal scanline renderer (that would be the one you know). As a matter of fact, many games already do this for realistic lighting on the static scene.

Re:raytracing downsides?

[mr3038]

[Raytracing] also forces lighting on the rendering. After all, we're tracing rays of light, here.

Umm.. no. In practice, no raytracer traces rays from the light source because very few of those rays would ever hit the camera. Instead, all raytracers do it backwards: backtrace the ray that would come from the top left pixel orientation towards the camera lens. When the ray hits an object (say, a wall), compute backtraces from that location. If you don't need realistic lightning, hitting a wall could always return preset amount of light (mixed with the object texture, of course) from that wall and no scattering of the ray.

The problem with full hardware raytracers is that the hardware should be able to hold whole scene or there'll be problems with some ray directions. GPU and the board on which it recides would limit the complexity of the scene, unlike with OpenGL which may render as complex scenes as the whole system can store (part of the scene can be streamed from the hard drive...)

I think the future will be a mix of both systems. Raytracer for curved, reflective surfaces. Multipass raster engine for everything else.

After looking through the video clip, it seems clear to me that the most important improvement in current games is better shadows. How many reflective surfaces there're in your environment? I'd say the glass is only one I'd miss reflections from and if that makes the difference between 2fps and 200fps, the lets forget the real reflections and use environment cube mapping instead.

Re:raytracing downsides?

[Anonymous Coward]

Because, let's face it, 20 fps isn't really playable

I've been playing UT for two years online with 10-15 fps (iMac DV with a lowly ATI Rage 8). It's playable.

Re:raytracing downsides?

[NoMercy]

20 years, in that time if mores law holds the average processor will be 2^(20/1.5) times more powerful, which is to say 10321x more powerful than today, even if it doesn't hold true, I suspect were more likely to see ray-tracing in 10 years, after all 10 years ago, were talking 1994... we'd only just got Doom from ID, no one had dreamed yet of looking up in a FPS :)

Re:raytracing downsides?

[jonadab]

> 20 years, in that time if mores law holds the average processor will be
> 2^(20/1.5) times more powerful, which is to say 10321x more powerful than today

Yes, but meanwhile expectations (regarding resolution, object complexity, and so
on and so forth) also keep going up, as existing game technology develops. It
is not enough to have the processing power to raytrace something that would
look very impressive today.

20 years could be longer than is required, but it's very hard to tell ahead of
time how long it will be. My point is that the time isn't here yet, though
experiments like this are interesting anyway of course.

Re:raytracing downsides?

[Anonymous Coward]

The whole scene doesn't need to reside in the RAM of the GPU. Have a look at the virtual memory architecture for ray tracing.

Re:raytracing downsides?

[Anonymous Coward]

There's a prototype of a ray tracing GPU. Small, but fast.

Re:raytracing downsides?

[Anonymous Coward]

Interesting. Could you try to remember the name of the prod? Was it on Amiga or PC? From the year I should guess the former..
I mean, the first RTRT I know of was 4k 'chrome' and it was released in 1995 and it wasn't much of realtime either. (I had one around as well but it wasn't in release shape back then. Finishing took about half a year;)

Re:raytracing downsides?

[Anonymous Coward]

In practice, no raytracer traces rays from the light source because very few of those rays would ever hit the camera. Instead, all raytracers do it backwards

Actually modern raytracers do it both ways, otherwise most of your rays would end up black for not hitting the light sources;)
So basically you first shoot a number of random rays from the light sources, store them on a tree-like structure and then render the scene backwards as usual, approximating the light from nearby 'photons'.

Re:raytracing downsides?

[Anonymous Coward]

that might be effecting it along the way

"affecting".

Re:raytracing downsides?

[Have Blue]

I can see reflections right now from a can of soda, a glass plate, 2 monitors, the mouse, the individual keys on the keyboard, and the side of my computer (all of it Apple hardware, so it has that smooth plastic finish), the spines of several dozen CDs, a framed painting, and my watch. The real world is still a vastly more complex place than a game engine.

Also, FWIW, there are more advanced (and expensive) forms of ray tracing that do involve tracing rays from light sources into the environment, to simulate effects like light bouncing off mirrors.

Re:raytracing downsides?

[Anonymous Coward]

Pixar used raytracing for the first time in Nemo (sparingly.) Then released a version of Renderman that has ray tracing this year.

Re:raytracing downsides?

[3rdParty]

compromise. Word of the day in gaming hardware.

Re:raytracing downsides?

[SamNmaX]

No, they don't. At least not when they can help it. Renderman didn't even have raytracing capabilities last time I looked, which admittedly was a while ago

From what I understand of Renderman (haven't used it personally), I believe it breaks up your scene into polygons that are of subpixel size, rendering with that. A major attraction of it is its shader language, whose flexibility we are starting to see to some extent in hardware now.

Re:raytracing downsides?

[The Only Druid]

You're somewhat incorrect. I'm unaware of anyone doing forward raytracing, but I am aware of quite a few people doing something related, via photon mapping. PM is mathematically seperate from raytracing though, i.e. the techniques to simulate it are extremely different.

Re:raytracing downsides?

[photon317]

Don't know if you're still reading this AC, but I'll go search around a bit if you bookmark this spot. The guy was a high school freind of mine, I doubt it was published in the demo scene, but I think he might still have a copy on a website of his.

Re:raytracing downsides?

[photon317]

Ok a couple minutes later here I did find a trace of it (pun intended). In '98 the guy made a crappy homepage, and one of the sections was on his "landscape raytracing". See web.archive.org url here (site is long dead): http://web.archive.org/web/20000420045611/www.leid ich.com/raytrace.htm

The program itself isn't there on that site, but web.archive.org captured some of the resultant artwork. You'll notice he claims he generated them with a raytracer he wrote in assembler in less than 4000 bytes, and the only image that archive.org managed to grab (http://web.archive.org/web/19991103074008/www.lei dich.com/kora0.jpg) has a dateline of "1994" on it. The version of this software I saw was probably a year or two before that time.

I still have some contact info for him if you wanna set up a junk hotmail account to receive it or something if you want more details for historical purposes.

FSAA?

[Anonymous Coward]

Why would they need FSAA on if it's ray traced?

Re:FSAA?

[bobbozzo]

Why would they need FSAA on if it's ray traced?

Probably because they're only rendering to 512x512.

Re:FSAA?

[frantzdb]

Because raytracing point-samples the scene, so just like polygon rendering you'll get jaggies all around your objects if you don't antialias.

Re:FSAA?

[Guspaz]

But they'd be using supersampled AA... if they're doing true FSAA on every pixel, then the slowdown would be 4x.

They could be rendering it at nearly 1280x1024 at the same speed without AA... I'd take that over 512x512.

I've seen "games" that use realtime raytracing on ONE computer. If they need 20 computers to do the same thing, I have to wonder. Is their program just unoptimized/poorly coded? Or have they turned on many questionable quality gimmicks?

Re:FSAA?

[metalhed77]

Ummmmmm, care to link to these games?

Re:FSAA?

[Guspaz]

Bah, google it. I'm talking about games I saw years ago, I don't memorize the URLs of every page I visit so I will have instant access to it many years down the road.

A quick google search turned up http://www.realstorm.com/ which is a realtime raytracing engine. A very impressive one might I add. It is able to render at 512x512 in realtime on a single machine, and looks better than Q3RT to boot.

Re:FSAA?

[John Harrison]

Castle Wolfenstein and Doom were both done using raytracing, though it was 2-D raytracing. They didn't use fancy lighting or complex models either, so maybe it they don't count.

Re:FSAA?

[Guspaz]

They weren't raytracing engines, they were raycasting engines. Big difference there. Raycasting just calculates if a 2D ray would hit a wall, and how far away it is. It's just simple trig.

Re:FSAA?

[John Harrison]

I stand corrected! You are right.

Radiosity!

[BRSloth]

Man, I can't believe they didn't used radiosity to render those images. Yes, I know it takes a lot more of CPU power, but I would surely steal other people computers just to play Quake that way :)

Re:Radiosity!

[j1m 5n0w]

Radiosity would dramatically increase the computational complexity.

Polygonal rendering: O(N), where n=number of triangles
Ray tracing: O(log N), where n=number of objects (assuming a good bounding volume heirarchy)
Photon mapping: O(P log max(P, N)), where P=number of photons, which generally must be inserted into a kd-tree, and N=number of objects
Radiosity: O(N^2), where n=number of triangles

Ray tracing could conceivably make a game faster, if the scenes are complicated enough. Radiosity, on the other hand, is very very slow. Photon mapping might be a better choice - it traces rays from the light source, and stores photons at the object intersection points, which are then used by the ray tracing step to approximate global illumination.

-jim

Re:Radiosity!

[styrotech]

It been a while since I've had anything to do with graphics and rendering etc, so this might be a dumb thing to say...

I was under the impression that ray tracing and radiosity weren't exclusive techniques, and using both produced excellent results.

ie ray tracing is excellent for reflections and refractions but tends to look too harsh when dealing with soft shadows and ambient light which is where radiosity works well.

Corrections welcome :)

Re:Radiosity!

[notsoclever]

Polygon rendering is also log(N) if you give it the same affordances for visibility preprocessing that you're apparently providing for raytracing, or use a hybrid approach like raycasted visibility for polygon rendering.

IMO, the best approach would be a hybrid of polygon+raytracing; use polygon rendering with shaders (and subdivision surfaces or some other form of arbitrary-precision surface tesselation) for most things, and then raytracing for reflections/refractions. There's a lot of things which pixel shaders make easy which are still damned difficult in raytracing, such as painterly/cartoon/etc. rendering, even if you do allow for programmable surface/illumination/etc. functions (which is what shaders boil down to anyway).

Also, a lot of photon mapping renderers are hybrid forward/backwards raytracers (pure photon mapping would be purely forward tracing, while traditional raytracers are backward tracing I know you probably know this, I'm just defining the particular instance of the terms I'm using since some people use them the other way around!) where they do direct and reflected illumination with backward tracing and caustics with forward tracing. IIRC, even Henrik Waan-Jensen's original photonmapping tracer did it this way.

Then to make things even more fun, there's path tracing which (again, IIRC) does a backwards trace from the screen to the lightsource then does a forward trace from that, which also produces pretty nice results, much more quickly than a traditional photonmapper.

Also, there has been some work on realtime radiosity, where basically it just iteratively solves the global illumination in parallel to a traditional polygon-pusher. When I was a grad student I implemented something like that and it produced pretty okay results. I was also going to eventually adapt it for lumigraph rendering (which is an adaptation of radiosity which can also handle reflections and refraction, by basically storing an environment map per vertex) but I never got around to implementing anything.

Re:Radiosity!

[Anonymous Coward]

The engine is able to do global illumination. Just follow the links and read.

Re:Radiosity!

[Anonymous Coward]

Let's make it somewhat more accurate by introducing another variable S, the screen size in pixels.

Polygonal: O(max(S, N))
Ray tracing: O(S log N)
Photons: O(max(S, P) log max(P, N))
Radiosity: O(max(S, N^2))

Note that if N ~= S polygons keep linear behaviour while ray tracing becomes linearithmic.

Re:Radiosity!

[j1m 5n0w]

I was under the impression that ray tracing and radiosity weren't exclusive techniques, and using both produced excellent results.

Yes, radiosity and photon mapping are both usually used to calculate indirect lighting. Usually they're used in conjunction with ray tracing or polygonal rendering.

-jim

Lan party upgrade

[complete loony]

Great so now I have to lug 20 pc's to a LAN party to get a decent frame rate?
And I was just thinking about my next upgrade for HL2/Doom3.
Imagine a cluster... oh wait.. um, so is it running linux? and where is the source code?

Soon...

[eyeball]

According to Moore's law, we should get this power in our desktops in about 4 and a half years from now.

Re:Soon...

[0x0d0a]

No.

20 computers running.

You have one computer.

log(20)/log(2) * 1.5 yrs = ~6.5 yrs

A bit longer, if you want a full 75 fps (or 60, if we're all using LCDs in 7 years).

Plus, technically Moore's law relates to transistor count, not processing power.

I'm interested in when we can do this in a game in real-time. l(2hrs*3600secs/hr*60fps)/l(2) * 1.5yrs = 28 years before we see this in real-time (though that's using Pov-Ray, which could probably be sped up a lot if it's made into a game engine rather than a general purpose graphics architecture.

Re:Soon...

[RedWizzard]

I'm interested in when we can do this in a game in real-time. l(2hrs*3600secs/hr*60fps)/l(2) * 1.5yrs = 28 years before we see this in real-time (though that's using Pov-Ray, which could probably be sped up a lot if it's made into a game engine rather than a general purpose graphics architecture.

That didn't use Pov-Ray, it used 3D Studio Max.

Re:Soon...

[Pluvius]

20 computers running.

You have one computer.

log(20)/log(2) * 1.5 yrs = ~6.5 yrs

Yeah, but those 20 computers are only 1.8 GHz each. Desktops can currently go twice that fast, so take off 1.5 years or so from that total assuming that you go with the best commercially-available desktop technology.

Rob

Re:Soon...

[zipwow]

Keep in mind, this is all just rendering in real-time. If you want the reactions to feel right, you've got to be modeling the physical interactions as well.

Doom and Quake aren't bad, but they still leave a lot to be desired.

And don't get me started on how corny the sounds are...

Re:Soon...

[0x0d0a]

Keep in mind, this is all just rendering in real-time. If you want the reactions to feel right, you've got to be modeling the physical interactions as well.

[clip]

And don't get me started on how corny the sounds are...

Aureal tried commercializing "wave-tracing" at the consumer level via A3D -- actually tracing out the paths of sound waves.

Unfortunately, they got hijacked by the incumbent (Creative, who didn't have a lot of incentive to get involved in a research war) who introduced a small reverb model as an alternative.

Re:Soon...

[zipwow]

wave-tracing's a nice start, but it's still just recorded clips.

I can't find it now, but I've seen at least one gradschool project on generating a new sound from an interaction, based on things like the interacting materials, the speed and location of the impact, etc etc. It was darn cool stuff.

-Zipwow

Help?

[Walker2323]

Can someone please dumb this down for us, well... dummies?

Re:Help?

[WolfWithoutAClause]

For each pixel (little dot) on the screen they projected a ray into the scene until it hit something. Then they bounced off at the appropriate angle until they hit something else, and so on until they hit a light. This can take quite a few reflections.

And they did this for every pixel on each scene, 20 times per second.

It's a slow technique but it gives good results. They managed to do this fast by using hardware and 20 computers all running in parallel and transfering the results over the network in realtime; 20 times per second.

Previously used techniques to draw the graphics for Quake III involve drawing little perspective adjusted triangles on the screen; with stuck-on texturing and they use some clever techniques to approximate lighting and shadow; but these techniques generally aren't as good as ray tracing; but they are easy to design graphics cards to do quickly.

Re:Help?

[0x0d0a]

Someone put a lot of computers together to make a powerful distributed system that is capable of rendering Quake using ray-tracing.

Here is an example of a (not real time) raytraced image (one that doesn't use radiosity -- just straight raytracing). In theory, given enough CPU power, they could pull this off.

Ray-tracing uses a method of 3d rendering that is currently beyond dedicated 3d hardware and must be done in software.

The main benefits of ray-tracing from a quality perspective are:

* True, accurate shadows from *everything* (most games, even stuff like Neverwinter Nights have hackish shadow engines that don't realistically display what lighting would look like in real life. These are calculated in real-time, not the precalculated shadows that you'll see in, say, Quake, where the light sources never move. You could throw a flickering lantern across a bar with bottles falling down and have all the bottles cast their own shadows.

* Advanced lighting. Currently, real-time 3d engines are very limited in the types of light they can produce -- generally, only spherical point sources of light.

* Refraction. You can have glass, ooze, or water truly refract light and distort images, not just use some sorta-lame effect to vaguely approximate it. Think of looking through a glass lens or a window in an old house.

* Volumetric fog (where you have "clumps" or "clouds" of fog, rather than just a global constant flag fog covering everything). Quake 3 had some rather (IMHO) impressive hacks to emulate volumetric fog -- ray tracing allows *true* volumetric fog -- people vanishing in swirling clouds of fog and mist and the like, not just a straight visibility dropoff.

* Reflections (there are a lot of hacks to approximate this off with existing 3d engines), but raytracers are *made* for this sort of thing.

* True curved and arbitrarily-shaped surfaces.

* Light projections (with shadowing and all that). They show a bit of this in the demo -- you could have, say, two people having a swordfight in a theater and the picture washing over them, or a scene in a church, with dusty light from the stained glass windows washing over the characters.

Basic ray-tracing does have some flaws. The shadows are sharp and hard -- sharper and harder than in real life. There are hacks to do soft shadows, but there isn't a particularly good an efficient way to pull them off.

It's hard to deal with things like laser beams or light beams coming out of a prism in ray-tracing. You need to do forward raytracing/photon mapping for this, which I suspect that they aren't doing.

Ray tracers tend to look a bit "eerie", for lack of a better word. They tend to leave shadowed areas very dark -- in real life, light will bounce around in corners and things a bit (even surfaces that don't look "reflective" to us will do so). So if I shine a flashlight, a raytracer will show a perfectly accurate cone of light (unlike existing 3d engines) that will spill properly over all surfaces. However, that cone of light will be a *cone* -- normally, when I shine a flashlight in a room, it lights up the entire side to some degree because of light bouncing off of objects.

There are some really nice things about ray tracers. They tend to parallelize really well, so you can theoretically put lots of computers together to do renders (as these folks did), or have lots of chips in parallel to theoretically make a custom piece of hardware.

Re:Help?

[kusanagi374]

Dumb it down? This is /.!

Let me put it this way: it's geek stuff, and there's nothing interesting to see here. Move along.

Re:Help?

[prockcore]

Ray tracers tend to look a bit "eerie", for lack of a better word. They tend to leave shadowed areas very dark -- in real life, light will bounce around in corners and things a bit

That's what radiosity is for. Now a realtime radiosity package would be tres amazing.

Re:Help?

[TelcusFreshbreeze]

You can add a photon mapping pass to a ray tracer to simulate light bouncing indirectly on to other objects. I believe this is part of what is called Monte Carlo ray tracing, which adds a whole swathe of extra goodies to traditional raytracing.

Re:Help?

[Belisar]

No, photon mapping is different from monte carlo ray tracing.

Photon mapping basically is tracing light particles from the light source over multiple bounces (for indirect illumination). The resulting hit points and other light data are then stored in a structure and used later on for lighting.

Path tracing in a way is like normal ray tracing, but you spawn new rays even for all kinds of reflection (that is *lots* of rays, which is why it's damn slow) and calculate the resulting color by weighting and adding the results of all the rays (recursively).

Essentially both "solve" an integral formulation for lighting known as the rendering equation, but in different ways.

Re:Help?

[Anonymous Coward]

Ray tracers tend to look a bit "eerie", for lack of a better word. They tend to leave shadowed areas very dark -- in real life, light will bounce around in corners and things a bit

I think that it is not the graphic engine that gave that look to the movie. It was all those person exploding, firing rockets at each other. Yuk

Re:Help?

[spectral]

What is considered the "right angle" for a forward raytracer? You can't do it based on the surface angle, unless the thing is absolutely reflective. If it's not, then there's a decent chance to not run in to any light source.

Imagine a piece of paper. Shine a laser (or any light) at it. Assume the light and your eyes are a 90 degree rotation about the center of the point apart, and both looking down at the paper at an angle of 45 degrees. If you raytrace the rays from your eyes, they hit the paper, bounce off along a line between your eyes and the light spot that's on the paper, and continue off in to the darkness. Now, in real life, that light does something.. but if I were to trace physically the light source, I'd not see that spot of light on the paper?

Perhaps I'm missing something, but it seems purely backward or purely forward raytracers couldn't work? You'd have to trace forward any light, to illuminate the surface, and trace backwards to see what ones are in view. If everything was perfectly reflective, however, the light wouldn't be absorbed/scatter in such a way that this would be a problem. But how often is everything in the room a perfect mirror? :)

Re:Help?

[WolfWithoutAClause]

Yes, that kind of thing is partly why it is slow :-)

Most surfaces scatter the light, so you can bounce off in any direction chosen at random. You generally have to do quite a few bounces before you bounce into a light source or the sky.

Incidentally, perfectly parallel mirrors can be the worst case; imagine a beam of light at a small angle- how many times would it bounce between them before making it out the other end?

You are right though- generally a mixture of forwards and backwards techniques are used. There's also a matrix technique for precalculating the reflectivity of surfaces. If you use raytracing for the first few bounces, and the reflectivity after that, scenes are going to generally look pretty darn realistic.

Oh yeah; there is one problem with raytracing- it can't usually handle refraction (prisms and lenses) of colours very well... one or two experts claim that this is a bug in reality, and that raytracing is perfect :-)

Stop the Insanity

[superultra]

Dammit, don't give Carmack any ideas! I'll barely be able to run Doom 3!

freecache

[pizza_milkshake]

freecache link to the 60MB movie posted to /. frontpage. sheesh.

pulling down at about 200kb/s

Wow.

[ikkonoishi]

Imagine what you could do with a beowulf cluster of these things... oh wait... nevermind.

It seems my question is already answered.

Re:Wow.

[Anonymous Coward]

That isn't redundant.

What is featured in the article IS a beowulf cluster.

Re:Wow.

[Anonymous Coward]

A cluster was mentioned earlier in the third line of this post, so yes, it was redundant.

Looks worse to me

[Jerf]

Is it just me, or did that look much worse than standard Q3?

Q3 isn't designed, let alone optimized, for raytracing, so that's not a major surprise, but I still expected an improvement, not a downgrade.

I think a custom demo is called for.

The tech sure is hella cool, though.

Re:Looks worse to me

[YrWrstNtmr]

Looks much jerkier as well. In the AVI, the gun seems to jump around way too much.

Re:Looks worse to me

[NanoGator]

"Is it just me, or did that look much worse than standard Q3?"

Yes. The reason why is they turned off one of the texturing passes. Q3 uses an extra drawing pass with B&W textures to make 'shadows' on the walls. Why'd they do this? I imagine because of the lighting effects in the game. If a flash goes off, you don't want the shadowed area staying dark. Just don't draw that shadow texture, and you get nice brightly lit wall caused by a rocket. (I apologize if that doesn't make sense. For a clearer idea, go into your video options and set the lighting effects from shadow maps to vertex only. You'll get similar looking visuals to what's in the video.)

So, to summarize, because they turned that feature off, the rooms don't look so dramatic. As a 3D artist, I can tell you that from a technical point of view, what they did is damn cool. However, this is a technical achievement, not an artistic one. So it is not surprising that they weren't able to make up for what they turned off.

That's the problem with tech demos, sorry.

Re:Looks worse to me

[schotty]

Yeah, it should --- Its running at 20fps. anything below 60ish and you see jitter and skippiness. Hell I am pretty bad at noticing crap like that. My bottom is around 40fps. OTOH, I have a bud whose eyes are so finicky, anything less than 75-80, and he can see.

I have to say ...

[bergeron76]

That video is one of the most impressive things I've seen (as related to PC video/games). The scene that looks like a night club is astounding, and the scenes with the mirrors are extremely cool.

I can't wait to see this technology in production.

Re:I have to say ...

[redfcat76]

Was just waiting for him to start firing rockets :)

ed2k link

[0x0d0a]

ed2k link (It sucks that Slashcode is broken WRT ed2k direct links.)

GRADE:C minus - not very well traced.

[CaptainCheese]

It's a okay as a technology demo, but it's ugly and what's more it's terrible coding for a raytracing engine.

They have used point sources, presumably to cut down on the ray-tracing required and show obviously ray-traced lighting, but it's the wrong sort of lighting...

Most of the light sources in Quake 3 are not point sources, but would in fact be slightly diffuse and should be rendered as such. You only get shadows like that from a very bright light far away. nearby light sources produce diffuse shadows - for example my lightbulb at 4 metres produces noticably diffuse shadow edges.

Using point sources on obviously diffuse light sources may give crisp, clear shadows, and a faster render speed, but it makes the raytrace less realistic and less impressive than the original.

If they wanted to show off their real-time raytracing using point-sorces they should have designed some levels that matched the ray tracing to the visible lightsource.

Re:GRADE:C minus - not very well traced.

[NanoGator]

"Using point sources on obviously diffuse light sources may give crisp, clear shadows, and a faster render speed, but it makes the raytrace less realistic and less impressive than the original."

Give them a break. As it is, it took them 20 cpus to make this work. Area lighting (you were calling it Diffuse lighting, area lighting is the cg term usually...) requires an array of point lights to make the soft shadows you want. Yep, they're more realistic, but they are an order of mangitude harder to compute.

"If they wanted to show off their real-time raytracing using point-sorces they should have designed some levels that matched the ray tracing to the visible lightsource. "

I'd love to hear of what you'd think would be a good example of a level that utilizes lights that have a physical size of 0 by 0 meters. This is not an "f-u!" challenge, but a genuine curiosity. As a 3d artist, I've yet to make something that wouldn't benefit from area lighting.

Re:GRADE:C minus - not very well traced.

[CaptainCheese]

Area lighting (you were calling it Diffuse lighting, area lighting is the cg term usually...) requires an array of point lights to make the soft shadows you want. Yep, they're more realistic, but they are an order of mangitude harder to compute.

first of all I called it a "diffuse light source", not "diffuse lighting" - a critical distinction between the source and the product. What's more "diffuse lighting" is a cg term too, albeit one you don't seem to know, and "area lighting" is subset of it. If you select "spotlight" instead of "area light" in your copy of lightwave or 3DStudio Max it's still a diffuse light. Pretty much everything but a laser is a form of diffuse light.

and secondly I'm glad you agree with me that they're more realistic but harder to compute. that was my point. they should have put a few sources in each lighting object instead of scattering loads of individual ones around. If that was the sort of level they wanted to use.

I'd love to hear of what you'd think would be a good example of a level that utilizes lights that have a physical size of 0 by 0 meters.

The names escape me, but of the stock levels any of the ones that are floating in space. y'know, space - where all the lights are really far away and cast hard shadows. For example, this effect is why the moon doesn't have a dawn or dusk, just a terminator line.

Re: ed2k, try this (OT)

[OldMiner]

Submit a patch or a feature request. You're capable enough from what I've read. If no one posts even a requests in such a forum, there's no way to reasonably expect the code to get changed.

The site's still up?

[NanoGator]

They're hosting screengrabs and a big video file, and the site's still holding up? Well now we all know what they did with all those machines they used for the demo!

Re:The site's still up?

[Anonymous Coward]

hmm.... this is a good idea... we're thinking about that... but a properly configured webserver helps a lot, too :)

Ray traced games on consoles

[Mekabyte]

And some people 10 years ago thought that ray traced games were going to be on LAST generation CONSOLES.

Slow already?

[sean1121]

Heres a mirror of the movie.
http://mirror.openbarr.com/20040509_egoshooters_q3 rt.avi

An interisting debate on Real Time Raytracing...

[Repran]

... can be found here.

alienware

[Flunitrazepam]

I guess I'll start saving for that alienware system after all..

Re:alienware

[Laetor]

That's about the very last thing you want to do, at least for their mobile systems.

20xAMD compared to 1 intel?? weird comparison!

[Roman_(ajvvs)]

This is proof positive that marketing is everything. Here we have a behemoth of a computer with twenty AMD processors and what are they comparing it to? a single intel processor. It shows how far AMD has yet to go to be bigger than intel when, in the minds of such obvious techheads such as these, measurements of a chip involve comparing to someone only peripherally involved.

The only reason I can think of them consciously doing this is to up the speed numbers, since 30GHz is in our minds not as impressive as 36Ghz, despite the fact we all know AMD is faster per MHz than intel.

Missings some things

[The Moving Shadow]

Okay i know raytracing provides far more realistic visual representations of a 3D modelled scene than actual scanline polygon rendering. But - and here comes the but - i miss a lot of things in this raytraced Quake movie. All the shadows are really really crisps, one would expect that when light bounces off walls and objects a few times its reflected light would soften those crisps shadows. E.g. it would result in softened gradual shadows.

I guess they limited the path of the ray they calculated so it bounced only two or three times off an object before they stopped calculating it. (If they stopped after one pass you wouldn't have seen those reflective glass balls like you did, which need multiple passes to look like they do).

I also miss colour bleeding on the surfaces. E.g. when you have - let's say - a white surface next to a red surface, some of the red will bleed on the white because light coming from the red surface will fall on the white surface and light it in a red hue. You would have seen this with a proper raytracing engine where the light bounces multiple times from an object and where the colour of the light is affected by the colour of the object.

I think those are the main reasons why the video doesn't look as realistic as i hoped for. (Then again how realistic is walking through a building where they have decorated the place with gruesome wallpaper taken from a horror movie and gigantic brains on mechanic spider legs walk around... ;) )

10-15 fps

[vasqzr]

You were probably one of those masochistic bastards that installed Windows 95 on a 4MB 386SX, weren't you?

Re:10-15 fps

[spectral]

You mean there were others than me?

God that was awful. But after doing that, I made my father use the computer. He realized how slow it was, and two weeks later I had a spiffy 133 w/ 32mb ram. :)

Ahhhh, yes.

[Ayanami Rei]

many games already do this for realistic lighting on the static scene.

For example:
Quake (1, 2 and 3)

You use radiosity...

[Ayanami Rei]

to compute global illumination levels ahead of time (as opposed to using ambience). Then you can use raytracing in realtime to capture dynamic effects.

Re:You use radiosity...

[j1m 5n0w]

[you use radiosity] to compute global illumination levels ahead of time (as opposed to using ambience). Then you can use raytracing in realtime to capture dynamic effects.

Where's the fun in that? I'd like to see dynamic global illumination (It might take awhile before computers are fast enough, and people figure out the right algorithms, though).

Photon mapping can be precomputed as well, and can simulate a number of effects that can't be simulated with radiosity (subsurface scattering, caustics off of shiny objects).

-jim

None of those things...

[Ayanami Rei]

are provided by a straight raytracer (soft shadows, color bleeding, etc.)

Because when a ray hits a surface, it only spawns a reflection ray and rays to any (point) light sources. Therefore shadows will have sharp edges, either a particular light at a particular point is visible or it is not.
Moreover, the contribution of non-light sources to a surfaces' illumination is not modeled (light from OTHER surfaces).
To accomplish this, once must create a large number of trial rays in a pattern around the reflection normal that roughly model the diffuse-ness of the surface in question. These can then "view" other nearby surfaces and pass on their illumination. Soft shadows can be achieved in this manner, by having rays intersect light sources which have volume, like real lights would.
But this sort of technique is much, much slower.

So....what?

[nullvector]

This looks worse than the original engine. I've played Q3 since it came out, and those screenshots are crappy compared to what the game really looks like... So big deal, someone used tons of processors and some good coding to create graphics that look worse than the original, for a few thousand times the CPU and $$ cost! Sometimes I wonder why people get excited over this stuff.

POVRAY

[markh1967]

As no-one else has mentioned it I'll be the first to point out that if you want to try raytracing for free on just about any platform you'll want POVRAY.

Raytracing101

[Mahrtian]

Feel free to mod me as redundant, but I'm sick of all the incorrect assumptions regarding rendering.

Raytracing overview. (a simple implementation)

Raytracing involves the casting of rays from the camera's eye, through a pixel in the screen. For each object in the scene (assuming no partitioning optimizations) we calculate whether the ray intersects the object. If it does, we determine the distance from the 'screen' to that object (consider it the Z depth) and save this for later. Once we have checked every object we find the object with the shortest distance (Z depth) and we caluclate the color of the pixel at that point.

To do this we get all the light source in the scene, and we cast a ray from the point on the object to each light source (assume point lights for now). We then determine if any objects intersect the ray. If there is a intersection then the point on the object is in shadow (at least partially, we won't handle translucent objects for shadows) so there is no light reaching the object from that light source. If there is no intersection, we calculate the color based on the material of the object (ka, kd, kn, ks), the angle of the camera to the points normal and the angle of the light source to the points normal as well as any reflected/refracted components.

The reflected/refracted components are where the coolness of raytracing is found. If the object has reflective properties, we cast a ray from the point on the object along at the angle determined by the original rays angle of insidence to the normal. We then use the same logic as the ray from the camera to determine what object it intersetcts with and the color of that point on the object. This is the recursive nature of a raytracing. This color value is then incorporated into the caluclation of the original point's color based on its 'reflectivity'. The same is done for refraction except that the ray is determined based on the refractive index of the object and snells law.

This is the extreme basics of raytracing. There are many subtilties that I have glossed over as well as many optimizations that can be done. For further enhancements there are better light models (spot lights, box lights, area lights, etc), distributed raytracing (which provides many features such as soft shadows, depth of field, motion blur, hazy reflections/refractions, antialiasing) and many others.

Re: ed2k, try this (OT)

[0x0d0a]

I actually did sit down to patch Slashcode after you pointed it out, but Slashcode apparently requires blowing away FC2's Apache and mod_perl installation, which I'm just not willing to do.