Slashdot Log In
Quake III Gets Real Time Ray-Tracing Treatment
Posted by
simoniker
on Mon Jun 07, 2004 06:58 PM
from the looking-smooth dept.
from the looking-smooth dept.
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."
This discussion has been archived.
No new comments can be posted.
Quake III Gets Real Time Ray-Tracing Treatment
|
Log In/Create an Account
| Top
| 116 comments
| Search Discussion
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.

Does it make full use of GPUs? (Score:5, Interesting)
(http://www.clickonstore.net/)
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!
Kinda cool (Score:5, Interesting)
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 (Score:5, Informative)
(http://www.seizurerobots.com/)
Freecache link for the video (Score:3, Informative)
(http://slashdot.org/ | Last Journal: Tuesday July 24, @05:09PM)
Re:Freecache link for the video (Score:4, Informative)
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.
Nice links there (Score:2)
Screen Shots [uni-sb.de]
Downloads (video) [uni-sb.de]
raytracing downsides? (Score:4, Interesting)
(Last Journal: Monday November 27 2006, @04:43PM)
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? (Score:5, Informative)
(http://dugger.notsoevil.net/)
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? (Score:5, Informative)
(Last Journal: Sunday October 03 2004, @04:03AM)
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? (Score:5, Insightful)
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? (Score:5, Informative)
(http://www.jyu.fi/~mira/index.html)
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? (Score:5, Informative)
(http://www.chriscanfield.net/)
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? (Score:5, Informative)
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...
Radiosity! (Score:2, Informative)
(http://juliobiason.net/ | Last Journal: Sunday July 31 2005, @12:36PM)
Re:Radiosity! (Score:5, Informative)
(http://syn.cs.pdx.edu/~jsnow | Last Journal: Sunday July 11 2004, @08:36PM)
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 [ucsd.edu] 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
Lan party upgrade (Score:4, Funny)
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... (Score:4, Insightful)
(http://www.spacehaven.com/ | Last Journal: Thursday November 14 2002, @03:08PM)
Stop the Insanity (Score:5, Funny)
(http://www.beelerspace.com/)
freecache (Score:2)
(http://www.parseerror.com/)
pulling down at about 200kb/s
Wow. (Score:1, Funny)
(Last Journal: Friday May 27 2005, @08:11AM)
It seems my question is already answered.
Looks worse to me (Score:3, Interesting)
(Last Journal: Saturday August 18 2001, @11:04AM)
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.
I have to say ... (Score:2)
I can't wait to see this technology in production.
ed2k link (Score:3, Informative)
(Last Journal: Sunday October 03 2004, @04:03AM)
The site's still up? (Score:2)
(http://www.ferion.net/ | Last Journal: Monday May 06 2002, @02:16AM)
Ray traced games on consoles (Score:2, Interesting)
(http://kontek.net/)
Slow already? (Score:2, Informative)
(Last Journal: Thursday July 28 2005, @01:08PM)
http://mirror.openbarr.com/20040509_egoshooters_q
An interisting debate on Real Time Raytracing... (Score:2, Interesting)
(Last Journal: Saturday February 11 2006, @07:16PM)
alienware (Score:1)
(Last Journal: Wednesday August 13 2003, @07:35PM)
Missings some things (Score:4, Interesting)
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...
So....what? (Score:1)
POVRAY (Score:2)
Raytracing101 (Score:1)
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.
1800Mhz x 20 = approx 36Ghz (Score:2)
(http://www.clickonstore.net/)
Re:FSAA? (Score:2)
Probably because they're only rendering to 512x512.
Re:FSAA? (Score:5, Informative)
(http://benfrantzdale.livejournal.com/)
Re:Help? (Score:3, Informative)
(http://slashdot.org/)
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? (Score:5, Informative)
(Last Journal: Sunday October 03 2004, @04:03AM)
Here is an example of a (not real time) raytraced image [irtc.org] (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? (Score:5, Insightful)
That's what radiosity is for. Now a realtime radiosity package would be tres amazing.
Re:GRADE:C minus - not very well traced. (Score:2)
(http://www.ferion.net/ | Last Journal: Monday May 06 2002, @02:16AM)
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.