My 3D Engine Adventure

I've made 3 versions of a 3D graphics engine with DirectX 8.  The second and third versions provide "compiled vertex and index buffers."  That is, scenes in the scenegraph and singleton graphics (accessed by proxies) can request of the engine what kind of vertex or index buffers they want, and what size they want those buffers to be. The engine keeps an empirical list of those requests and then creates only the buffers needed in just the sizes needed. As requests to draw are fed into the engine, it piles the different graphics into the appropriate buffers...adjusting FVF stride as needed so that buffers can be shared even for dissimilar graphic types.  The reasons for this approach were twofold.  First, I wanted a composition of buffers that would reduce state switches.  That is, I was trying to maximize performance.  Second, I wanted to ease coding by centralizing buffer managment.  That is, no scene in the scenegraph would worry about things like overflowed buffers, setting a "discard" flag for resetting a dynamic buffer, etc etc.

Ironically, however, it was the second version of this engine that had the best performance by far.  In rev 2, I had assumed all graphics would be cached in vertex/index buffers. The engine, on behalf of the scenes, would remember where every scene's graphics were in the video buffers and would redraw those graphics each frame without the need for locking and unlocking buffers. Only if a scene altered the vertices somehow would the engine update buffers with the new material. All the graphics to be drawn were sorted based on avoiding expensive state changes (vertex/index buffer changes, texture changes, vertex shader changes, etc).  But I was convinced by a friend that I was putting too much emphasis on performance, and not enough emphasis on ease of use. Following that advice I did away with all the abilities I've just described. The current engine retains only the "compiled vertex/index buffers" (no more sorting or caching) and so locks and unlocks video buffers for every single draw request...no matter how small. This turned out to be an egregious decision since performance is now suffering terribly, even when displaying small numbers of polygons!!

But what did I use this 3D engine for?  Ironically, I used it for a 2D game under development at Screaming Games.  Put simply, I wanted the free alpha-blending and, given the nature of the game in development, I wanted matrix transformations.

Though I feel I could take my experience and build a much better 4th revision, I'm now more interested in using someone else's 3D engine. There are many good ones available, ranging from the free to the astronomic in cost. I'm likely to use Purple#, a free .net C# graphics engine. Or, I may go the C++ route and make OGRE, another free engine, my first venture into using a 3rd party engine. The present version of OGRE lacks some video game fundamentals, such as collision detection and sound, but its design, feature set, and simplicity otherwise seems to be exceptional - making it a good playground.  It is also, as far as I know, the only fully object-oriented 3D engine available. Incidentally, the AriasAmp logo - the bezier patch, is a demonstration of first generation hardware acceleration rendering of a true curved surface; it was rendered with OGRE!

When I'm ready to move on from OGRE or Purple#, I figure I will use the Torque engine and tool set from GarageGames.  The idea is principally just to see what another engine has to offer, and to gain the benefits of the powerful supporting development tools that come with it (something OGRE lacks).  Torque only costs $100 if it is used non-commercially.

Copyright © 2002-2003 Brent Arias. All Rights Reserved. Please read our Terms and Conditions.