Raytracing: Theory &
Implementation Part 1, Introduction
Jacco Bikker
06/10/2005
Introduction
Hello and welcome to a new series of articles (or column, if you wish)
on the topic of raytracing.
For those that do not know me: My name is Jacco Bikker, also known
as 'Phantom'. I work as '3D tech guy' at Overloaded, a company that
develops and distributes games for mobile phones. I specialize at 3D
Symbian games, which require highly optimized fixed-point,
non-HW-accelerated 3D engines, crammed into 250Kb installers. So
basically I'm having fun.
As software rendering used to be my spare time activity, I was looking
for something else. I tried some AI, which was great fun, and recently
I dove into a huge pile of research papers on raytracing and related
topics; such as global illumination, image based lighting, photon
maps and so on.
One document especially grabbed my attention. It's titled:
"State-of-the-Art in Interactive Ray Tracing", and was written by
Wald & Slusallek. I highly recommend this paper. Basically, it
summarizes recent efforts to improve the speed of raytracing, and
adds a couple of tricks too. But it starts with a list of benefits of
raytracing over rasterization-based algorithms. And one of those
benefits is that when you go to extremes, raytracing is actually faster
than rasterizing. And they prove it: Imagine a huge scene, consisting
of, say, 50 million triangles. Toss it at a recent GeForce with enough
memory to store all those triangles, and write down the frame rate. It
will be in the vicinity of 2-5. If it isn't, double the triangle count. Now,
raytrace the same scene. These guys report 8 frames per second on a
dual PIII/800. Make that a quad PIII/800 and the speed doubles.
Raytracing scales linearly with processing power, but only
logarithmically with scene complexity.
Now that I got your attention, I would like to move on to the intended
contents of this crash course in raytracing.
Series Outline
- 1
- 2
前往页