Slashdot Mirror
Intel Shows Off Quake Wars, Ray Traced
An anonymous reader writes "At the Research@Intel Day 2008, Intel showed a ray-traced version of Enemy Territory: Quake Wars. Compared to the original game, a water with reflections and refractions and a physically correct glass shader were added. Also, a camera portal with up to 200 recursions to itself has been demonstrated. To show off this ongoing research in the topic of real-time ray tracing, a four-socket system with quad cores has been used that allowed rendering the enhanced visual effects in 1280x720 at 14-29 fps. Just two years before, early versions of Quake 4: Ray Traced ran only at 256x256 with 17 fps. Even though Intel's upcoming Larrabee will be primarily a rasterizer, the capabilities for also doing ray tracing on it should deliver interesting opportunities."
Actually, I believe real-time ray tracing open up some very interesting gameplay possibilities if people know how to use it.
Imagine a FPS, for example, on which you could notice a sneaking bastard on an unusual angle behind you because you saw his reflection on the doorknob you were about to pull. Or maybe cursing at the newbie because he didn't pay attention to the position of a specific lamp and now your team is screwed because your shadows have been noticed.
Then again, I think the whole FPS genre is saturated. Examples of other types of games are welcome here.
I've always wanted a realtime graphics engine based on something like the POV-ray ray-tracer (or other procedural modeling). The POV-ray syntax is all "exact". Rather than approximating shapes using subdivision into triangles, exact shapes are created by specifying things like "spheres" or "cylinder" or unions, intersections, and differences thereof. More complex objects can be specified by arbitrary mathematical equations, and complex sequences of operations (e.g. take a spline, sweep it along a path, intersect it with another shape, apply a certain matrix transform, ...). Having done some modeling both ways, I much prefer the "exactness" of procedural definitions, rather than approximation. (I inevitably wish I could go back and add resolution to a triangulation, but that isn't easy to do properly.)
The neat thing is that the resulting objects (if properly defined) have "infinite" detail. The roughness on a surface, for instance, can be based on a noise function, so you can zoom into it without ever seeing triangulation or other artifacts.
The obvious downside is that the computation here is intensive. Objects can be arbitrarily complicated. Calculating the intersection of a ray with a mathematically-defined surface involves very complex calculations. Rendering POV-ray scenes on modern hardware, for instance, can take minutes to days (depending on complexity).
One upside is that the rendering can be tuned to available resources. On older hardware, the number of light-sources (or the intersection accuracy, etc.) can be reduced. This would mean that video game graphics would get arbitrarily "better and better" on newer hardware, without any need for someone to change the code. Having said all this... I think our hardware is not yet powerful enough to make this kind of thing practical. (There are some neat examples that have been coded, but as a general technique we're not there yet.)
It's just a first step. Give them some time and I'm sure they'll be producing much more impressive stuff. Though I don't really give a rats ass about the applications real time raytracing has for video games. I'm more interested in what it can do for 3D graphics and animation. As it stands now in 3D you have to render everything out to see what it looks like properly lit. It'd mainly be a workflow improvement, but it'd be a welcome one. It's extremely annoying and time consuming to render out a test image that can take 10 minutes just to see how everything looks. That would also cleave through final render times. As it stands now with most projects it can take weeks or even months to render everything out. In theory with this a single desktop computer could be on par with a render farm. Suddenly all those jerks over at CORE won't be so smug.
I have nothing compelling to say
Fancy graphics don't make a good game, but poor graphics (as relative to the times) does make a game poorer.
every ps3 owner tells me this same thing. Yet they always are at my house playing my Wii.
Self-modifying assembly is a long-lost art. If you have a strong stomach, a long long time ago I used to use QuickBasic as a ghetto scripting tool, loading in various assembler modules to do the dirty work. I later switched to Pascal.
:) The bitches were all over me, dawg!
:)
Back then, most of my hardware-control loops used self-modifying bits and bobs... sometimes to save a byte, sometimes to avoid a fetch. A few times I used true self-modifying code where the outer loops would reprogram the inner loops on-the-fly. It was the most CPU-efficient way to do realtime multichannel sound synthesis on a 486, and of course it gave me the opportunity to refer to it as a dynamic synth compiler
All that lovely code died a quick, silent death when Windows 95 came along. It wreaked all sorts of havoc and Windows would kill the app as soon as it tried to self-mod. It's a shame I didn't keep up with the skills, I could be one rich despicable virus writer today
It's times like this I miss the 90's, I still have that 386 programming manual somewhere safe.
-Billco, Fnarg.com