|
An Interview With Dave Eberly by Kurt Miller 
For starters, please tell us a bit about yourself as well as a bit about your career as it relates to graphics and the gaming industry... At 45, I am a tad bit older than many in the games-graphics industry. My net persona and writing/presentation styles are generally viewed as unexciting, but I assure you that is only a facade. After all, how exciting can you really make mathematical topics? Join me some time for a couple of pints of McEwan's to find out about the real me. I *never* talk math while at the local pub. Some things are sacred... My background is as strange as any. I flunked out as a pre-med student in my first undergraduate school, worked on a cemetery, worked at a fast food restaurant for a few years, worked the graveyard shift doing piecework in a knitting mill, and worked for quite some time on a farm. I managed to graduate from my second undergraduate school (Bloomsburg University in Pennsylvania), earned a couple of advanced mathematics degrees (University of Colorado at Boulder), then obtained an academic position (University of Texas at San Antonio). I played the standard tenure game, my first role-playing game!. Got it, not important, gave it up. I then retrained at the University of North Carolina at Chapel Hill in medical image analysis, got a few more advanced degrees, this time in computer science. I stayed on as a research faculty member for one year, worked at SAS Institute on statistical graphics for a little over a year, then finally ended up at Numerical Design Limited to work on NetImmerse for almost four years. I left in August to concentrate all my efforts on Magic Software. This entire process only took 25 years for me to finally figure out what I want to do with my life! While at UTSA a couple of faculty members got me interested in computer graphics. I learned how to program graphics on a DEC GIGI with a Vax 730 back-end. You know, the kind of programming where you send escape strings to the device to get it to light various dots on the screen, sort of like a printer language. Well, maybe you don't know. Am I *that* old? I purchased my first personal computer: an IBM XT running at 4.77 Mhz, 1 Meg of memory, an EGA graphics card, and a 20M hard disk that took me two years to finally install enough stuff to fill it up. I taught myself Turbo Pascal and wrote some basic graphics programs with a SetPixel primitive. I became curious about how to draw the images faster, so I learned assembly language and studied the CGA, EGA, and Hercules graphics architectures. I enjoyed working with the hardware so much that I decided to teach computer graphics to the engineering students and tortured them by making them write device drivers for the various cards. While at UNC I did not get involved in the graphics program. My real introduction into games is attributed to a visiting graduate student from the Netherlands who stayed at my place. He liked to play computer games; I never had. He bought Myst for me. My wife and I played that for hours. What a fabulous game! (Heh heh, why are you making the gesture of putting a finger down your throat. Hey, I liked Riven just as much.) My exposure to games for the next few years was solely through playing. When I left SAS Institute, the company had just formed Southpeak Interactive, but I had already made up my mind to head to NDL. Since then, my life/career has been predominantly focused on computer graphics in the games industry. Your Magic Software site is a pretty well known and valuable resource for graphics enthusiasts. What was your motivation behind getting this going, and what's your overall goal for the company / site? At UNC, I was pretty ignorant about 'practical' computer science. I did not know what the 'web' or 'news groups' were. My first 'post' to a news group was by proxy. I wanted to build a basic volume rendering tool for 3D medical images. I had a friend ask how you go about extending Bresenham's 2D line drawing algorithm to 3D. He posted to a group called comp.graphics.algorithms; I got a sketchy answer that was enough to help me figure out the pattern. I learned how to use 'rn' and subscribed to c.g.a. That was in 1991 and I am still active in the group. Folks asked a lot of questions that interested me. I have always liked developing algorithms and implementing them. Once I learned how to set up a web page, I started making my source code available so that other folks could benefit from it. Most of the source in the early days was related to the image analysis I was doing, but once I left UNC, the emphasis shifted to geometry as it pertains to computer graphics. The goal of my company was to provide me with an environment where I am my own boss! Okay, met that goal. Seriously, though, my ideal goal is to spend my working hours developing and implementing algorithms and making them freely available. In order to have enough of an income to live comfortably, I do contract work and write books. I keep two active customers at a time (filled up at the moment), am writing my next book for Morgan Kaufmann, and spend my remaining time maintaining my web site. Perhaps all this does not answer the intended question: Why are you making nearly all your code available for free? I believe that if there is any one thing that should be given freely, it is knowledge. Your teachers and professors were kind enough to impart knowledge to you. Do the same for your successors. Lets talk games for a bit... If you were to start from scratch today, designing a game engine for modern hardware with support for multiple platforms, where would you begin? After a couple of versions of NetImmerse on the PC that worked out a lot of the performance issues and got the architecture about the way that I wanted, along came the Playstation 2--high performance, small memory, no tools support. The NDL engineers took a lot longer than we had hoped for porting NetImmerse to the PS2. The problem, as you well know, is that a lot of algorithms that are designed to run on a standard CPU/memory architecture do not map well to a specialized architecture like the PS2. All of a sudden it looked like NetImmerse needed to become an API specification with the back-end components implemented for each supported platform (this API-ish view is what I believe is Intrinsic's concept). When you get to this point, you begin to have nightmares that only software engineers have, the main problem being that the design of the original API itself might have an implicit dependence on the standard CPU/memory architecture. Specifically, this happened in NetImmerse with the matrix class. The constructors and member functions were implicitly dependent on matrices being stored in row-major order in PC memory. PS2 uses column-major, so interfaces had to change. And with information hiding via interfaces, you have to start looking at how well your compiler is at inlining functions. Which means looking at assembly listings. The reality is that hardware manufacturers want to be a step up on their competitors. They need to design the next generation hardware to be different than that of their competitors. For specialized hardware, this will invariably mean recoding your libraries to make effective use of the new hardware. Get ready for the age-old trade off. If you want a platform-independent API, you have to exchange performance to get it. This is good for companies that want to reuse the game engine as a way to minimize costs by reducing engineering man-hours for the next game. On the other hand, if you want every component of your game to use the minimum number of cycles, write your engine for each platform of interest. You get your performance goals, but development costs increase. My opinion? I prefer the platform-independent API solution with the hope that the API is generally a good one for the multiple platforms and that the back-end components have a good chance for being optimized per platform. Consider OpenGL as a case study, albeit at a somewhat lower level than scene graph management, that appears to work reasonably well in a multiple platform environment. What items in your design notes would have big flashy stars next to them and why? Better visibility determination and occlusion culling. The rule for real-time drawing is *still* not to draw anything if you do not have to. The SurRender folks have that right with Umbra. Eliminate polygonal models and build everything with surfaces to give you "infinite" continuous level of detail that can be adjusted based on intrinsic surface properties and on screen space metrics. Of course, you still send triangles to the renderer, but the triangle generation is all done by the engine, not the artist. A drawback to choosing a surface environment is that visibility algorithms will be more difficult to develop than for polygonal environments. And finally, I would not have the engine attempt to provide a *general* collision detection system. It would provide a geometric query library for computing distances and intersections. The collision detection/response needs for a game appear to be specific enough to the game that it should be specifically implemented for that game. This specific system should take into account as much knowledge as possible that is known about the game and world environment. What features would you be sure to include? Well, all of them. I am a firm believer in providing every possible feature to consumers of the game engine, even if that means sacrificing some performance. In fact, integration of features to properly interact with each other is quite an important goal. An example from NetImmerse. We had support for skinning and support for continuous level of detail meshes. Customers requested support for skinned, continuous level of detail meshes. So we added it. Now consider that you want such a character to be involved in collisions, for example, preventing the character from passing through a wall. The collision system needs to support skinned, continuous level of detail meshes. You might even envision such a character being partially controlled by key frames and partially controlled by inverse kinematics. Another example is integration of game physics with collision detection. A few customers were/are attempting to use NetImmerse with physics engines such as MathEngine or Havok.com. Not always an easy match. Integration is key to a successful commercial engine. (But don't forget the tools support, too.) What are your thoughts on visibility systems in game engines today? What sort of approaches do you favor, and why? I believe that general visibility determination on current machines is still not possible in real-time. Just as with collision detection, the visibility system should make every attempt to use specific information about the world. Preprocessing should be used, if possible, to allow for "look ups" at run time. The design of the world itself needs to take into account what the plans are for use of the world. If you build a world such that the camera can be in a location for which a dozen alpha-blended trees are stacked up along the line of sight, you are only asking for performance troubles. My experience in dealing with some NetImmerse customers is that artists are generally unsupervised about such issues. They want it to look good. Depth complexity is generally ignored. How about lighting? Dynamic versus static (lightmaps, etc) for example... I think the application of light maps and shadows to a scene are generally a solved problem. The more important issue is providing tools to generate light maps. For example, tools to support radiosity calculations for a given indoor environment with static lights are needed. You spent some time working on NetImmerse, which is now a well-established commercial game engine. How long has this engine been in the works, and what features or design decisions are you particularly proud of (and why)? I started at NDL in January 1997. The NetImmerse source code was about six months old at the time and originated from an unnamed company. Lars Bishop (still at NDL) wrote a Direct3D renderer to go with that code (it had an OpenGL renderer) and Mark Finch was the de facto project lead. Mark and Lars had a quite nice morphing terrain algorithm and demonstration that showed off continuous level of detail ideas. NDL's goal in hiring me was to help make the transition from a contract company to a product-based company. After six months, Mark left to work for HeadSpin, a local company consisting of many ex-NDL employees (HeadSpin was later acquired by Cyan). I took over as Director of Engineering and started the conversion of the source to adhere to stricter software engineering principles. When I started, source control consisted of informing your office mates that you were going to be working on a file, tagging the blocks you changed, then at some point having someone manually merge the changes. Needless to say, the software engineering changes occurred and NetImmerse evolved into a top-quality game engine adhering to the principles that a large library should. What I am proud of most is not any specific features or design decisions that I made, rather that I had a talented group of engineers that were willing to believe in my software engineering goals and helped evolve the product to what it is today. You recently wrote a book entitled 3D Game Engine Design: A Practical Approach to Real-Time Computer Graphics. What audience is this book written for, and what makes this book unique? I intended the book to be for folks with a strong mathematics and computer science background that either are working in computer graphics or games, or have a desire to do so. What makes this book unique is also what has generated some interesting negative reviews. This is a "no-bull" book (to quote Peter Lipson of Broderbund/Mindscape from a preliminary review). Yes, it is heavily mathematical, but it is not entirely mathematical. The negative reviews indicate there is too much emphasis on mathematics. More amazingly is that some of the reviews indicate that you can write a 3D game engine without that emphasis. Wrong on both accounts. A lot of what is described in the book is really based on my experience in building NetImmerse, a commercial engine. I think the confusion is that some folks think that a 3D game engine is just a 3D renderer. The renderer is just the component of the engine that is fed by a scene graph management system. Now the positive reviewers appreciate the emphasis on mathematical issues. Ahhh.... The source code that goes with the book is quite significant, over 1100 files. I call this a "baby" game engine. By no means is it a commercial game engine, but there are thousands of hours I put into this code. That is less time than spent on NetImmerse, estimated (by me) to be about 20 man-years. The code alone justifies the price of the book. A commercial engine will cost you on the order of at least a hundred thousand dollars. What advice do you have for aspiring game developers and 3D engine authors looking for their spot in this rapidly expanding industry? Learn as much mathematics as you can. 3D games naturally involve 3D geometry and 3D graphics, neither of which can be properly understood without mathematics. Learn as much software engineering and object-oriented design as you can. 3D engines are large libraries and, as such, require the principles of the two aforementioned topics. All the other necessities such as code optimizations, cache issues, assembly tuning, transfer of data over a bus, and other low level architectural issues will come by experience. If you do not get the high-level architecture right, there is no point in spinning your wheels on the low-level architecture. Any other comments, advice, or links you'd like to share with all the flipCoders out there? Buy Tomas Moller's and Eric Haines' book "Real-Time Rendering". It is well written and has a lot of good references. Buy "Game Programming Gems", edited by Mark Deloura. A reasonable collection of ideas. Buy David F. Rogers "An Introduction to NURBS: With Historical Perspective". A book that is written from an engineer's perspective. And after all, someday game engine's will only care about surfaces... Many thanks to Dave for sharing with us some of his experience and knowledge! |