Ray Tracing in Games: A Story from The Other Side
Recently, there has been quite some discussion about the possible future use of ray tracing in games. Industry veterans such as John Carmack (ID Software), Tim Sweeney (Epic Games), Cevat Yerli (Crytek) as well as graphics experts such as David Kirk (NVidia) and Daniel Pohl (Intel) gave their opinion on the subject. With Intel’s Larrabee, their acquisition of Offset Studios, and references to FarCry 2 subtly linked to ray tracing, there is plenty of food for thought. NVIDIA is also involved: The takeover of Mental Images and RayScale indicate that they also keep their options open.
Whether or not ray tracing will take over rasterization in the foreseeable future remains unclear. Some emphasize the benefits of pure ray tracing, others expect a hybrid system, where ray tracing is ‘just another feature’. Game developers are reluctant to take the plunge: There is little actual data, no ‘killer demo’, and no proof of concept.
Compared to rasterization, ray tracing promises a simplified production process, both on the art side and the programming side; it promises more realistic graphics, and better scalability. At the same time, ray tracing is simply slower: It is generally associated with low resolutions, simple meshes, and poor shading, because of this. It would be interesting to look at the development process of an actual game, to see what really works as expected, and what doesn’t.
A ray tracer is simple, compared to a full-fledged GPU based 3D engine. Traditional engines need to stack together a large array of algorithms to approach realism; a ray tracer does most advanced effects using the same code. Also, the fact that all features of a ray tracer work effortlessly together, reduces the need for lots of special cases.
A hybrid renderer, on the other hand, makes sense since the most common task of any rendering algorithm, namely finding the ‘first hit’ (the parts of the scene that are directly visible from the camera) is far more efficient using a rasterizer. The ray tracer could then be used for the parts that a rasterizer doesn’t do well: Correct reflections and refractions.
Over the past year, students of the IGAD course of the NHTV University of Applied Sciences (Breda, The Netherlands) worked on two games using a real-time ray tracer for rendering. This article looks back on the development of these games. The aim of this article is to contribute to the discussion from a different point of view: Looking back.
An important part of the IGAD curriculum is the GameLab: One full day a week, students work on game projects, putting into practice the lessons learned, and working together as a team on material for their portfolios. Most of the time, we use some existing game engine as a basis for our projects. Starting in the second half of the first year, one of the options is an experimental real-time ray tracer: Arauna. This is an in-house developed high-performance ray tracer, focusing on rendering alone: Game-engine wise, the teams basically need to start from scratch.
Over the course of this year, two groups of students opted for the ray tracer. The first group started working on Outbound, a Myst/Riven type of game. The second team wanted to build an action game, Let there be Light, which is somewhat similar to Descent.