flipCode - Tech File - Nicholas Vining [an error occurred while processing this directive]
Nicholas Vining
Click the name for some bio info

E-Mail: vining@pacificcoast.net



   06/04/2000, Being John Carmack


OK: time to update the old tech file again, with a few rants on matters technical. In reference to a recent film offering, I'm going to call it "Being John Carmack". <grin>

First off, I should mention that I'm working this summer and beyond as a contractor for Loki Entertainment Software! Wahoo! I start work at the start of July, and I don't know exactly what I'm doing, but it should be fun. Everybody just.. kicks arse there. I want to take a little bit of time and effort to publically thank Sam Lantinga, Michael Vance, and Scott Draeker, for the time, effort, and legal fees, that they've pumped into making this happen. Now that I've said that, the views expressed here and in future tech file updates are not those of my employer.

Now, down to technical stuff.

I read John Carmack's .plan file on Thursday with a good deal of interest. (Anybody who knows me will tell you that I put far too much stock in his writings). While I think that Doom III, as it is being called (even though we really don't know...) will be fun to play, and that Paul Steed's departure was really, really stupid, I think that the bit that interests me is the fact that the Doom III engine will "use brand new technology in almost every aspect of it".

I think Mr. Carmack may have found a holy grail.

I'm calling it the "holy grail" based on Paul Nettle's way of describing his visibility system, which, judging by the screenshots and the movie, kicks arse. Way to go Paul.

However, Carmack's "holy grail" more likely than not has to do with lighting and shadowing as opposed to PVS determination. (He has yet to deviate from BSP trees) Here is my prediction, formally declared here: John Carmack's next engine will have fully dynamic lighting and shadows. And whatever technology he uses will be the "next big thing".

I think it's possible; the engine that I'm currently working on is questing after this eventual goal. (What's more, it's questing after doing it on a V3/3000. Anybody want to buy me a V5/6000?)

First off, I don't think that he will use the "lighting" aspect of hardware T&L. Carmack uses OpenGL, and the lighting system is _not_ clean. In fact, it's lousy. It just sucks. If hardware T&L is going to catch on, that system needs a cleanup, a rewrite, and a new set of extensions.

Two more likely candidates are either the lighting algorithm he described in a .plan file of last year involving taking slices of three dimensional textures (if somebody wants to resend that my way, I'd appreciate it, BTW), or the 12/6 pass orthogonal illumination mapping technique that showed up on a whole bunch of gaming sites at once and then faded away into obscurity.

The 3D slice lighting algorithm, while not viable now, will be soon, as we start to see next-generation cards having support for 3D textures in real time. (In particular, the next offering from ATI, the Radeon, which IMO is the best card of the lot "on paper") The average engine development time at ID software is approximately two years, by which time it'll probably be a de facto standard. The orthogonal illumination mapping technique is fantastic; for those who haven't seen this puppy in action yet, it's a nifty form of per pixel lighting. The only catch is that it requires something in the range of eight texture "applications". The good bit is that you can easily extend it to as many diffuse lights as you damn well please, and still only have to do those eight applications[1].

Doing this realtime is quite realistic, believe it or not. The ATI Radeon has three TMUs instead of two, which reduces the number of "extra" passes down to two-and-a-bit, which is really not that far fetched. The NVidia GeForce purports to be able to perform seven operations on a pixel for a two TMU unit, but that's stupid garbage... we may all like register combiners, but... (As a reference: Quake 3's "best" lighting algorithm does 2 passes of two TMUs each, plus extras for each extra rendering pass that the shaders do). The cards being offered by 3Dfx and NVidia after the current range (V5/GeForce2) can easily handle OIM, but I can't talk about them. NDAs. Presumably Carmack knows a lot more than I do about the next batch of hardware (and may even have his hands on some prototypes, something that I'm trying to obtain), and is willing to use them to his advantage. A smart engine developer designs ahead of schedule.

For those of you who don't know, OIM is basically doing diffuse lighting on a per-pixel basis. (this is VERY generalized) Because OpenGL doesn't support signed textures, you fake it by performing six passes, one which darkens, one which adds. Then you blop on an ambient pass and your texture, and wham. A good overview is at http://www.opengl.org/News/Special/oim/Orth.html -- and if you see it in use, it's spectacular. (There's an update as well, which indicates that they've expanded the technique to ambient, diffuse, and specular lighting; local lights, multiple lights, and a local viewer. The results are _indistinguishable_ from a GeForce with full extensions)

Shadows are a more complex topic. Shadow volumes have been, for the longest time, the "best we can do" -- and until recently, a lot of cards didn't even support it. Now, all the offerings from the big three (3Dfx, ATI, NVidia) do. (I don't know about what's next from Matrox...) The problem with shadow volumes is that if you get into "complex" situations (which, incidentally, most engines ignore!), you start getting into nasty kludgie bits.

The distinction between shadows and lighting is important. An "unlit" area is not the same as a "shadowed" area. An unlit area is one where light does not hit it because there is no light; a shadowed area is one where light does not hit it because there's something large in the way.

At this point, there isn't really a good answer. The Radeon purports to have hardware accelerated shadows, which is very cool if ture, but I can't think of a good algorithm. I'm still working on this one as I'm starting to design the 3D engine for my current project. Anybody have any thoughts, send 'em my way. I'm always interested.

I'm going to sign off for now; it's nearly midnight. I'm not saying that any of the technology I've vaguely mumbled about here will be what he's using, although I'm inclined to say that OIM is the best technique I've seen for a while. Who knows about the shadows.

Bedtime.

OH yeah! Watch for a VERY cool press release coming from me very soon. Amateur game makers, rejoice... you'll like this, I promise.

Cheers,

Nicholas





  • 06/19/2000 - Tech File Update
  • 06/04/2000 - Being John Carmack
  • 05/08/2000 - Tech File Update
  • 04/11/2000 - Tech File Update
  • 03/07/2000 - Introduction

  • This document may not be reproduced in any way without explicit permission from the author and flipCode. All Rights Reserved. Best viewed at a high resolution. The views expressed in this document are the views of the author and NOT neccesarily of anyone else associated with flipCode.

    [an error occurred while processing this directive]