John Carmack on Ray Tracing

Started by
138 comments, last by AndyTX 16 years ago
Which is weird, cause Crysis actually had some original ideas. Contrast this to Far Cry, which was a generic waste of time.
SlimDX | Ventspace Blog | Twitter | Diverse teams make better games. I am currently hiring capable C++ engine developers in Baltimore, MD.
Advertisement
Quote:Original post by Promit
Which is weird, cause Crysis actually had some original ideas. Contrast this to Far Cry, which was a generic waste of time.


Well that's merely one opinion, and a wrong opinion in my own.

Personally I like both games, but enjoyed Far Cry far more because almost all the missions were fun; Crysis became completely unfun once you go into the alien ship. After that it becomes like a cheap console game on rails with none of the stealth and exploration.
Allow me to toss in my 2 cents:

I have been working on real-time ray tracing for several years now, and currently, I am trying to get students (I'm a lecturer) to use it in small games that we develop as part of the course (IGAD, NHTV, Breda, The Netherlands). You can check out my work at http://igad.nhtv.nl/~bikker .

During those years, I have seen ray tracing grow quickly from 'barely interactive' (1-2fps) to 'almost real-time' (20fps and more), for scenes that are close to what we would need for a typical game. The 'dynamic geometry' issue was more or less solved, and performance improved greatly because of better algorithms and faster processors. Ray tracing benefits directly from faster CPUs and more cores; especially the speedup with every new core is almost linear.

As a game developer (Dutch game industry, 10 years), I really like the fact that ray tracing is so elegant. No more stacking of endless arrays of shadowing algorithms, no more algorithms that don't work together, no more tricks in general. Of course, RT does use tricks to speed up the process, but it's a matter of optimization, not a matter of faking stuff that just can't be done using a rasterizer. As other posters mentioned, shadows, reflections and refractions 'just work', and so do (exact) soft shadows and global illumination (not fast enough yet though). A ray tracer is a simple piece of software, it's the optimization that makes it hard. So, from a game developer point of view, I want ray tracing to work out: It will make life more fun, programmers will be able to focus on the game, visual effects will require a look-up in a physics book, instead of a look-up in a pile of tricks. Same for the visual artists: A ray tracer is far less picky about what you throw at it, and the 'effects' it supports will work under all circumstances, not just some carefully selected special cases.

That being said, performance really is a huge issue. RT is not even near GPU performance, although Larrabee may be a major leap in the right direction. Things that will really set RT apart, like GI, diffuse reflections and soft shadows, require way too many rays (but, it's just more rays, not more code!). So perhaps we will first see hybrid approaches. A hybrid engine would be a beast though; after all, the ray tracing would be another trick for the rasterizer.

Frankly I believe ray tracing is not 'impressive' right now because 'we' don't have the asset development resources that the GPU industry has. I believe that's one of the points that Carmack is trying to make: If we can't build a demo that shows why we would want to waste all that performance on a new algorithm that is not supported by any hardware or any API, we better prove that it is worth it.

- Jacco Bikker
I think that we've missed the main point. He was talking about applying the virtualized texturing technology to a voxel grid. This would basically allow modeling of the world down to the millimeter level. I know that poly counts aren't too much of a bottleneck any more, but we still can't sculpt worlds in that level of detail yet. The raytracing was simply the best way of rendering the voxels.
inherently interactive - my game design blog
We're not missing the main point, the guy was interviewed to respond to earlier articles that interviewed Daniel Pohl and that guy from NVidia, on the topic of ray tracing. :)
Quote:Original post by Ashkan

Well they banned me from gamespot after expressing my views on Crysis. It's a free country, yeah I know, but I'd better shut my mouth before I set some moderator's seat on fire as experience has taught me that fat wallets of such companies are not something I want to set my feet on. To this end, I won't discuss such issues any further! I'm here for another purpose.


I hate to drive this further off-topic, but somehow I doubt you being banned from Gamespot had anything to do with your preference in games. Even more unlikely is the idea that it had something to do with some developer's "fat wallet".

Quote:Original post by phantomus
Ray tracing benefits directly from faster CPUs and more cores; especially the speedup with every new core is almost linear.

Of course, RT does use tricks to speed up the process, but it's a matter of optimization, not a matter of faking stuff that just can't be done using a rasterizer. As other posters mentioned, shadows, reflections and refractions 'just work', and so do (exact) soft shadows and global illumination (not fast enough yet though). A ray tracer is a simple piece of software, it's the optimization that makes it hard. So, from a game developer point of view, I want ray tracing to work out: It will make life more fun, programmers will be able to focus on the game, visual effects will require a look-up in a physics book, instead of a look-up in a pile of tricks. Same for the visual artists: A ray tracer is far less picky about what you throw at it, and the 'effects' it supports will work under all circumstances, not just some carefully selected special cases.


I don't see how it's fair at all to say something "just works" when it still requires tremendous optimization just to bring up to interactive levels. I also don't see how it's fair to imply that straight ray-tracing won't have any corner cases where things slow to a crawl if you don't "fake" them. Developers will always have cases where being physically correct won't win over a simplification or a pre-calculated solution, regardless of whether you're using RT or rasterization.


Having spoken with Carmack numerous times (I've shipped 3 games with licensed quake tech) I've formed the opinion that he is a very pragmatic person. The quote from the article that really exemplifies his personality, in my opinion, was the eating your own dogfood quote. Raytracing to him (again, this is just my take) is a simply tool and not the end goal. His point was that raytracing will be useful but not in the context of lighting per se and that rasterization will become better and faster for primary rendering tasks (specifically lighting). Raytracing will have its uses, just maybe not in the "traditional sense" of firing rays from pixels to obtain the pixel color.

Re: Ashkan
I mostly agree but here's the one problem with your take: publishers will probably not greenlight your game unless it looks visually competitive (I'll been on the wrong end of this). We are entering a phase of the industry where some level of graphics is going to be expected. I'm not disagreeing with you, but graphics must get people in the door, gameplay will keep them there. That level of expectation is constantly moving forward. Pixar movies do a good job of pushing the bounds of what we can strive for. Sure you can find exceptions but I think games like Bioshock (good game AND looks great) are going to become more and more expected. Just my opinion of course.
I know this thread isn't about Gameplay Vs. Graphics. But as a few people have tuned in on that I just wanted to post my 2 cents on the subject. Not as a programmer but as a gamer.

In my opinion a good game has both good gameplay and impressive visuals. I don't buy the "remember the good old days" line and never have. The old games were great - and on the whole they looked great too( because we knew no better ). It is rather like saying that old movie of the train hurtling towards the cinema screen that scared the audience( they thought it was actually gonna burst from the screen and hit them - if you can believe that ) would still thrill a modern audience. Quite clearly it would not. There is too much of an emphasis on pushing visual boundaries that does in a lot of cases detract from gameplay, I concur. But there are also exceptions to this. Getting the balance correct is what, in my opinion, distinguishes a great game from an average one.

Anyway, apologies for furthering this sub-topic, but as a few other people had commented on the subject I wanted to post my view.
-...-Squeeged third eye.
Quote:Original post by MJP
I don't see how it's fair at all to say something "just works" when it still requires tremendous optimization just to bring up to interactive levels. I also don't see how it's fair to imply that straight ray-tracing won't have any corner cases where things slow to a crawl if you don't "fake" them. Developers will always have cases where being physically correct won't win over a simplification or a pre-calculated solution, regardless of whether you're using RT or rasterization.


I agree that all but the most trivial features of current 'real-time ray tracers' are either very slow or need hacks. However, there is a difference: In rasterization, many tricks are needed not because of performance, but because it's the only way to achieve the goal in the first place. In my book, a cube-mapped reflection is a hack, but it's the only way to get something like a reflection. A ray tracer could use the same hack, but it doesn't need to; the algorithm can easily do the 'real thing' (we're talking about a dozen lines of code here on top of a basic ray tracer). That means that increasing realism no longer depends on the availability of smart algorithms, it depends on raw performance alone. We can trust the growth of performance (I think I can safely assume that), but algorithms don't generally obey Moore's Law. Combine that with the fact that all 'ray tracer features' (there really aren't that many by the way) effortlessly work together, even recursively, and you have something that is prepared for the future. The problem is the 'now'. :)

By the way, a ray tracer screams for a whole new bag of tricks to solve the performance problem... I added adaptive anti-aliasing (you really would like to just trace multiple rays through every pixel, so that could be considered a hack), ray packet traversal (breaks in recursive situations, so definitely a hack), undersampled GI, normal mapping (replaces real detailed geometry, so it's a hack?), and so on.

This topic is closed to new replies.

Advertisement