Step into Interactive Ray Tracing

I overheard someone commenting recently that ray tracing was the next logical step in interactive rendering. Although this is surely a popular idea, he continued that switching to a ray tracer soon before secondary effects (like reflections and refractions) were practical would be worthwhile. His argument was that since ray tracers can use the same graphical "hacks" like environment maps and shadow maps to match rasterization, when more performance comes down the road the developers could just swap out a given hack with the physically-accurate equivalent. Why not, right? Well, that's a tough pill to swallow.

Games are bottlenecking
The fact of the matter is that interactive rendering--especially in games--is a very performance-intensive medium. As opposed to most applications like a word processor or database, every AAA game title is developed to suck every last drop of performance out of the CPU and GPU. If the developers are only getting 50% CPU/GPU utilitization, they naturally would tweak the game to get more visual quality out of the system. This is natural considering most game players aren't multi-tasking between applicationss while running these programs and can dedicate the hardware to that one game.

This is the problem with transitioning to ray tracing. To move to ray tracing while providing the same quality effects adds more work to an already bottle-necked system. Ray tracing interactive scenes is inherently slower for the same perceptive quality. Optics, BRDFs, and light-transport-related topics have been researched for hundreds of years. Today's ray tracing researchers are focused on speed. Problems include rebuilding dynamic acceleration structures, corralling rays into coherent packets, and getting all the operations to march in lock step on these SIMD-plentiful architectures. It's all about performance. The only time games will implement ray tracing is when they can do the same important effects as efficiently as rasterization. Using rasterization techniques in ray tracers is still slower then rasterization: one still has to build acceleration structures, one still has to do crazy optimizations, and one still has to deal the incoherent texture and geometry accesses inherent in ray tracing. So why on Earth would any developer opt for a ray tracer with half the performance for the same graphics just so fifty years down the road, it's easier to add secondary effects? Blah.

Rasterization's Bang for the Buck
I've stated this before, but many production companies still use rasterization because they care about visual quality. Pixar and Dreamworks, for example, still rasterize the scene first before adding any secondary effects. After all these years these companies are still using basic shadow maps to shade direct illumination. And it's their business to make pretty pictures! The only people saying ray-traced games can do soft shadows interactively are ray tracing researchers and marketers. I could write a rasterizer to do physically-accurate shadows, but it wouldn't be interactive either. That's why I don't brag about it.

With the current growth of processing power, I am guessing that sometime in my life I will see ray tracing become the normal rendering technique in interactive computer graphics, but I doubt it will be in the next thirty years. Rasterization will only fall behind the second it fails to keep improving.

Five-Years Difference
Rasterization is moving at an incredible rate. In a separate article, I compared a screenshot of two games only five years apart: Battlefield 1942 released in 2002, and Crysis released only five years later. This is what ray tracing is competing with. A rapid, cut-throat industry where GPUs are getting more and more powerful and developers are creating more and more dazzling hacks. Years from now when a ray tracer can produce images comparable Crysis, we'll be looking back wondering how we ever tolerated such mediocre graphics.




What's coming down the pipeline?
Interactive rasterization certainly hasn't stopped moving and will continue to provide a lot of one-sided competition for ray tracers in games.

Here are some things coming down the pipeline that we can look forward to that will continue to choke up interactive ray tracers:

• Highly-tesselated subdivision surfaces
  
• Movie-quality anti-aliasing
  
• Realistic hair
  
• Interactive deforming
  

Shortest Ray Tracer In the World (not really)

I saw Andrew Kensler's newest back-of-a-business-card ray tracer. It's some pretty short and simple code to render his initials in reflective spheres. I'm not sure he could find the way to shorten the code even more, without losing any kind of coherence.

This took 2 minutes on my workstation


And here's the code (butchered by my browser)

#include    // card > aek.ppm

#include 

#include 

typedef int i;typedef float f;struct v{

f x,y,z;v operator+(v r){return v(x+r.x

,y+r.y,z+r.z);}v operator*(f r){return

v(x*r,y*r,z*r);}f operator%(v r){return

x*r.x+y*r.y+z*r.z;}v(){}v operator^(v r

){return v(y*r.z-z*r.y,z*r.x-x*r.z,x*r.

y-y*r.x);}v(f a,f b,f c){x=a;y=b;z=c;}v

operator!(){return*this*(1/sqrt(*this%*

this));}};i G[]={247570,280596,280600,

249748,18578,18577,231184,16,16};f R(){

return(f)rand()/RAND_MAX;}i T(v o,v d,f

&t,v&n){t=1e9;i m=0;f p=-o.z/d.z;if(.01

for(i j=9;j--;)if(G[j]&1<,0,-j-4);f b=p%d,c=p%p-1,q=b*b-c;if(q>0

){f s=-b-sqrt(q);if(s.01)t=s,n=!(

p+d*t),m=2;}}return m;}v S(v o,v d){f t

;v n;i m=T(o,d,t,n);if(!m)return v(.7,

.6,1)*pow(1-d.z,4);v h=o+d*t,l=!(v(9+R(

),9+R(),16)+h*-1),r=d+n*(n%d*-2);f b=l%

n;if(b<0||T(h,l,t,n))b=0;f p=pow(l%r*(b

>0),99);if(m&1){h=h*.2;return((i)(ceil(

h.x)+ceil(h.y))&1?v(3,1,1):v(3,3,3))*(b

*.2+.1);}return v(p,p,p)+S(h,r)*.5;}i

main(){printf("P6 512 512 255 ");v g=!v

(-6,-16,0),a=!(v(0,0,1)^g)*.002,b=!(g^a

)*.002,c=(a+b)*-256+g;for(i y=512;y--;)

for(i x=512;x--;){v p(13,13,13);for(i r

=64;r--;){v t=a*(R()-.5)*99+b*(R()-.5)*

99;p=S(v(17,16,8)+t,!(t*-1+(a*(R()+x)+b

*(y+R())+c)*16))*3.5+p;}printf("%c%c%c"

,(i)p.x,(i)p.y,(i)p.z);}}

I'm still waiting for his back-of-a-napkin photon mapper.