Slashdot Mirror
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."
Freecache link. This should hopefully be faster. Anyone have a torrent?
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 :)
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.
I Browse at +4 Flamebait
Open Source Sysadmin
Because raytracing point-samples the scene, so just like polygon rendering you'll get jaggies all around your objects if you don't antialias.
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.
-WolfWithoutAClause
"Gravity is only a theory, not a fact!"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.
May we never see th
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.
May we never see th
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.
May we never see th
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.
The ______ Agenda
> 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.
Cut that out, or I will ship you to Norilsk in a box.
The real-time curved reflective surfaces (true reflection, not cube mapping) and displacement surfaces currently cannot be done on 3D cards.
ed2k link (It sucks that Slashcode is broken WRT ed2k direct links.)
May we never see th
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.
You like splinters in your crotch? -Jon Caldara
Heres a mirror of the movie.3 rt.avi
http://mirror.openbarr.com/20040509_egoshooters_q
"The road from legitimate suspicion to rampant paranoia is very much shorter than we think." - Picard
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).
That isn't redundant.
What is featured in the article IS a beowulf cluster.
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.
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...
> 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.
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.
_________________________
Spelling and grammar mistakes left as an exercise for the reader.
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.
There's a prototype of a ray tracing GPU. Small, but fast.
Pixar used raytracing for the first time in Nemo (sparingly.) Then released a version of Renderman that has ray tracing this year.