Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 



Forgot your password?
typodupeerror
×
Graphics Software First Person Shooters (Games) Intel Technology

How Quake Wars Met the Ray Tracer 158

An anonymous reader writes "Intel released the article 'Quake Wars Gets Ray Traced' (PDF) which details the development efforts of the research team that applied a real-time ray tracer to Enemy Territory: Quake Wars. It describes the benefits and challenges of transparency textures with this rendering technology. Further insight is given into what special effects are most costly. Examples of glass and a 3D water implementation are shown. The outlook hints into the area of freely programmable many-core processors, like Intel's upcoming Larrabee, that might be able to handle such a workload." We mentioned the ray-traced Quake Wars last in June; the PDF here delves into the implementation details, rather than just showing a demo, and explains what parts of the game give the most difficulty in going from rasterization to ray-tracing.
This discussion has been archived. No new comments can be posted.

How Quake Wars Met the Ray Tracer

Comments Filter:
  • by robvangelder ( 472838 ) on Monday January 26, 2009 @03:51AM (#26605057)

    When looking at the before/after pictures, was anyone else surprised when they read which was the raytraced version?

    To me, the ship in the water looks better with the bump map.

  • by 91degrees ( 207121 ) on Monday January 26, 2009 @05:22AM (#26605345) Journal
    since I'm pretty sure I read that the original quake (or was it doom?) traced a ray or two for some mapping reason, back when the source code was released.

    Not sure about those two, but I'm pretty certain Wolfenstein 3D did. That was for visibility and texture coordinate calculation, rather than light and shadow. Since the map was 2D only a handful of rays were needed.
  • They're still taking the wrong approach to raytracing. If Philip Slusallek was able to get 30 FPS in a raytraced game in 2005, using a single Pentium 4 behind a raytracing accelerator that was roughly equivalent to a Rage Pro in terms of gates and clock speed, it seems silly to me to ignore the possibilities of adding an "RPU" to the mix instead of just adding more general purpose CPU power. Yes, I know that's Intel's thing, but even for Intel... a raytracing core would be a tiny speck in an I7.

  • by TheBracket ( 307388 ) on Monday January 26, 2009 @11:38AM (#26607635) Homepage

    Wolf3D used raycasting, rather than tracing to give a pseudo-3D rendering of what was basically a 2D grid map.

    It's pretty clever how it worked, I remember having a LOT of fun cooking up my own similar renderer back in the day (Turbo Pascal with inline asm was fun!). If I remember rightly:
    First, the ceiling and floor were drawn in, covering everything (intersecting in the middle, vertically). Then, they took your location on the map, and cast a ray for each row of pixels (320 of them, I believe). This ray went forward until it intersected a wall - and the distance to the wall was measured. It then did a quick calculation (lookup table) to determine the height of the wall at that distance, subtracted half that height from the center of the screen, and plotted a vertical line in the color of the wall. I seem to remember the wall color was retrieved from a small texture and scaled.
    That gives surprisingly good results, albeit with no lighting or shading.

  • by 0xABADC0DA ( 867955 ) on Monday January 26, 2009 @12:44PM (#26608511)

    4. Scene complexity is inherently limited by 1 other major factor that you've completely ignored. Memory speed. As your data set increases, rendering performance degrades to the speed at which you can feed the processors - i.e. the speed of the memory. Again, this is another reason why we seperate the scene into render layers.

    What's neat about raytracing is that the memory access can be divided into millions of separate 'threads' that are not dependent on each other. So, with a processor (such as Tera MTA) where threads run in the order that memory is available you achieve maximum memory bandwidth.

    On 'modern' processors where memory is read in the order that threads run you get massive pipeline and cache stalls when using a software raystracer. So when you are comparing the 'vs' of rasterization and raytracing you need to consider that raytracing currently has thousands of hands tied behind its back.

    Raytracing never really made the in-roads into the FilmFX world that the early 80's/90's evangelists predicted - And i predict that it will never make the in-roads into Games that you seem to believe.

    I think it's exactly the opposite. 'FilmFX' world isn't using raytracing because it hasn't been used in games. Games drive this tech, and if we get fast hardware for raytracing then movies will use it exclusively.

    It's really been a hardware issue... designing an asynchronous CPU with millions of thread AND getting it to interface efficiently with a PC card bus is basically impossible. But, move the renderer into the CPU itself and it's far, far easier and faster on all fronts. For that reason I see raytracing soon getting it's first real chance to compete head-to-head.

The rule on staying alive as a program manager is to give 'em a number or give 'em a date, but never give 'em both at once.

Working...