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."
A lot of power for some eye candy. IANAG(gamer) but it seems to me that more investment into the story line and playability would go a lot further than raising the system requir --oooh shiny!
If video games influenced behavior the Pac Man generation would be eating pills and running away from their problems.
With enemeies like that, who needs frames.
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.)
I predict that you'll eat those words one day.
Yes, I am a smart ass; it's better than the alternative.
Ray tracing mimicks how real world works.
Raytracing doesn't mimic how real world works. In fact it does exactly the opposite of what happens in real world. In real world you have bazillions of light particles, doubling also as waves, shoot out of many area light sources and bounce/be absorbed by objects around them.
Whatever photons end up hitting your retina, is what you see.
Raytracing instead shoots a ray out of your (virtual) retina straight forward to the scene and may refract/reflect off objects, until it's "absorbed" (means, hits a surface where refraction/reflection isn't calculated).
Rendering a single frame of 3D as it is in the "real world" (with just a fraction of the rays) would mean days on even the fastest hardware out there.
What raytracing gives you is sharp reflections, refractions and shadows, while introducing a bunch of other limitations on the rendering that rasterization doesn't have. It also can't do soft shadows, reflections, refractions, efficiently, nor subsurface scattering, or radiosity.
Best models for rendering in the future will likely be hybrid models similar to what is now used in professional renderers by movie studios. But then again, it's a game, who cares about mathematicaly accurate reflections, when you can fake it close enough with reflection/refraction maps in a fraction of the processing time.
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
Every time ray tracing technology is shown off, I can't help but marvel that the long held dream of games filled with reflective spheres can finally be enabled.
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
I miss the 90's too, when geeks ruled the internet and programming was an art.
Now children rule the internet, and programming is a dead end job.
What a shitty decade this is.