Video Game Design: Programming: Framework: 2D vs 3D: 3D Engine: An Open Learning Guide

If the game requires a 3D environment, it signifies that it will use a 3D view that is characterized by the use of polygon based graphics. Polygons are flat shapes and in a low count (low resolution polygon scenes) graphics are often angular.

A good 3D engine should run at a decent speed, no matter what the size of the full world is; speed should be relative to the amount of detail that is actually visible. It would of course be even better if the speed would only depend on the number of pixels you want to draw, but since apparently no one has found an algorithm that does that, we can not do more that attempt to improve upon past work.

This section will attempt to describe the components in the architecture of a 3D Engine. A 3D Engine encompasses a lot of concepts. We will do our best to cover other systems that use 3D engines (such as programs like auto cad, blender, medical programs, etc.) but we will focus in specific in 3D engines for games.

Game engines are a very broad complex topic. They have their own architectures and approaches directed toward the features that are necessary to be in a particular game or game type. The way one engine works is not necessarily how all engines work, or even most, that is to say each is a unique creation.

The 3D nature of the world will require that most of the concept art after approval to be scanned and modeled onto planes in a 3D modeling application such as Maya or 3DsMax.

Basically, a portal based engine permits the 'spatially indexing' of large datasets that usually make up the virtual world: in other words, it can be a simple technique to avoid having to display all that data in every frame and instead only draw what is relevant even permitting to save fast memory requirements.

A basic portal engine relies on a data set that represents the world. The 'world' is subdivided in areas, that I call 'sectors'. Sectors are connected through 'portals', hence the name 'Portal Engine'. A portal-based engine world can be thought of as a variation of a boundary representation (or B-rep) data structure that is very much special-cased to the properties of a gaming world. The rendering process starts in the sector that the camera is in. It draws the polygons in the current sector, and when a portal is encountered, the adjacent sector is entered, and the polygons in that sector are processed. This would of course still draw every polygon in the world, assuming that all sectors are somehow connected. But, not every portal is visible. And if a portal is not visible, the sector that it links to doesn't have to be drawn. That's logical: A room is only visible if there's a line of sight from the camera to that room, that is not obscured by a wall.

So now we have what we want: If a portal is invisible, tracing stops right there. If there's a huge part of the world behind that portal, that part is never processed. The number of polygons that are actually processed is thus almost exactly equal to the number of visible polygons, plus the inserted portal polygons.

By now it should also be clear where portals should be inserted in a world: Good spots for portals are doors, corridors, windows and so on. That also makes clear why portal engines suck at outdoor scenes: It's virtually impossible to pick good spots for portals there, and each sector can 'see' virtually every other sector in the world. Portal rendering can be perfectly combined with outdoor engines though: If you render your landscape with another type of engine, you could place portals in entrances of caves, buildings and so on. When the 'normal' renderer encounters a portal, you could simply switch to portal rendering for everything behind that portal. That way, a portal engine can even be nice for a 'space-sim'...

Sometimes the available offering of 3D engines will not match your game's requirements, the features or licensing. 3D game engines are huge software projects. A single person can indeed write one, but it is not an overnight process. It will probably result in having more than a few megabytes of source code. If one is not to committed to finish it, the attempt will fail and even put the whole game project at risk.

Source and licence

Text adapted from Video Game Design/Programming/Framework/2D vs 3D/3D Engine by Wikibooks contributors under CC BY-SA 4.0. Paragraphs have been selected and abridged, and formatting adjusted. This adapted text is shared under the same licence. Contributor history.