Raytracing Myths

I'd love to know where this guy works now.

I've always thought it would be cool to do computer graphics programming but never been sure which sort of companies pay for guys like this to work for them.

All I could find was this: http://c0de517e.blogspot.com/2010/12/leaving-ea.html indicating that he used to work for EA in Canada.

Make sure you read the debate in the comments. It's as fascinating as the article.

While the article is accurate about how one can apply spacial subdivision to rasterization to cull primitives, there's a significant different in the details.

With raytracing, we always know exactly when we're done, because our outer loop iterates over each primary ray, and we trace that ray to its closest intersection.

With rasterization if we want some sort of early exit we have to keep track of what regions of the zbuffer remain unwritten. The problem is, we don't know if a "hole" in the zbuffer is going to be written to later by some primitive, or if it's just a hole to the background far plane in the scene. So a single gap can force us to rasterize all primitives in the fustrum. The natural scheme of coping with this is to subdivide into tiles and render each independently, but it remains a problem that it's difficult to know when you're "done" doing some early exit from rasterization.

Well, I think it's inevitable at some point to switch to ray tracing; it being much simpler. Moore will do it's job in a couple of years, and maybe some architectural changes will help the change. The article talks about primary ray rendering vs. rasterizing, but I'm not sure if secondary rays (reflections) are feasible at all with raster engine. Thus, the complexity figure could also mention number of bounces and the advantages of ray tracing therein.

A path-traced game: http://raytracey.blogspot.com/2011/09/720p-video-of-unbiased...

The blog is pretty sweet too.