Introduction to the principles of 3D game engines

Author: Luke hodorowicz

Translation: le chenguang)

I don't know much about 3D either. The motivation for translation is content-based high spirits, and exercise NLP skills. Due to my limited level and experience, there are definitely a lot of misunderstandings and misinterpretations in this article. I also ask the readers to point out that they can be improved together.

Jia wenshu will share with you, and you are also welcome to reprint them freely.

Introduction (Introduction)

Let's talk about how you write a 3D engine that provides elegant performance. What your engine needs to provide: curved surfaces, dynamic lighting, volumetric fog, mirrors, and portals), skyboxes, vertex shaders, particle systems, static mesh models, and animated mesh models ). If you already know how all of the above functions work smoothly, you may be able to put those things together into a single engine.

Wait! Before you start writing code, you must first think about how to build your engine. In most cases, you must be eager to create a game, but if you start writing code for your engine immediately, you will feel very uncomfortable, after development, you may have to overwrite a lot of local code multiple times to place new special effects and controls, or even give up after failure. Taking the time to think deeply about your engine will save you a lot of time and reduce your headaches. You will not be eager to construct a giant project; maybe you will give up the engine when it is not finished, and then do anything else. Well, you may not be able to do that before you know how to learn what you need. It is indeed a good thing to really complete the design. For this, you will feel better and you will be dazzling!

Let's analyze the basic components required for a complete 3D Game Engine. First, this provides some information for developers who have corresponding 3D experience but still need some guidance. These are some content entries that are not difficult and can be quickly mastered but must be applied. To make your work better, here we will give you a general idea about how much work you put into a game engine. I call these components system, console, support, Renderer/engine core, and game media layer) and tools/data ).

Tools/data (tools/data)

During development, you always need some data, but unfortunately it is not as simple as writing a text file or defining a cube. At least, you need a 3D model Editor, level editor, and graphics program. You can purchase or find some free programs on the Internet to meet your development requirements. Unfortunately, you may need more tools, but you cannot get them (they do not exist yet). You have to write them by yourself. In the end, you are likely to write a level editor by yourself, because you are not likely to get what you need. You may also write some code to pack a large number of files. It is very painful to deal with hundreds of files all day. You must also write some converters or plug-ins to convert the model format of the 3D model editor into your own format. You also need some tools to process game data, such as visibility estimation or light textures.

A basic principle is that you may want to design tools with an equivalent or even more code than the game itself. You can always find the ready-made formats and tools at first, but after a while, you will be able to realize that you need a great feature for your engine, and then you will give up on the previous writing method.

The 3rd-party tool, which is currently very popular, can be used for development. Therefore, you must always pay attention to your design. Because once you publish your engine as opensouce or allow modifications, some people may apply your development results in a certain day, And they will expand or make some modifications.

Maybe you should spend a lot of time designing art, levels, sound effects, music and entity models, just like designing and writing games, tools, and engines.

System)

A system is a part of communication between an engine and a machine. When a good engine is to be transplanted to the platform, its system is the only place where major changes (Code extension) need to be made. We divide a system into several subsystems, including: graphics, input, sound, timer, and configuration ). The primary system initializes, updates, and closes all subsystems.

The graphics sub-system is very intuitive in the game. If you want to draw something on the screen, it is easy to do. In most cases, graphics subsystems are implemented using OpenGL, direct3d, glide, or software rendering. If it is more ideal, you can even support these APIs, and then abstract a "graphic layer" and set it above the implementation API, this gives the customer developers or players more options to get the best compatibility and performance.

The input sub-system must trigger the input of various input devices (keyboard, mouse, Game Board [gamepad], game handle [Joystick]) for Unified Control and receiving. (Transparent processing) for example, in a game, the system should check whether the player's position is moving forward, instead of directly detecting each input device, it is better to send a request to the input subsystem to obtain the input information, while the input subsystem is actually working behind the scenes (detecting each input device separately ), all this is transparent to customer developers. Users and players can switch the input device very freely. It is easy to obtain unified behavior through different input devices.

The sound system is responsible for loading and playing sounds. The sub-system features are concise and clear, but many games currently support 3D sound, which is somewhat more complicated to implement.

Many of the outstanding performances of the 3D game engine are based on the "Time System. Therefore, it takes some time for you to think about the Timer sub-system. Even if it is very simple, everything in the game is triggered by time for mobile changes, however, a reasonable design will prevent you from writing a large number of identical control code for implementation ......

The Configuration System is located at the top of all subsystems. It reads configuration record files, command line parameters, or implements setup ). During system initialization and operation, all subsystems will keep communicating with it. Switching the resolution, color depth, key bindings, sound support options, and even loading the game, the system makes these implementations extremely simple and convenient. Make your engine more configurable, which makes debugging and testing more convenient. gamers and users can also easily choose their preferred running modes.

Console)

Ha! I know that everyone is happy to build a console system like quake. But this is indeed a very good idea. Through command line variables and functions, you can change the settings of your game or engine at runtime without restarting. It is very effective to output debugging information during development. Many times you need to test the values of a series of variables. It is much faster to output these values to the console than to run a debugger. When your engine is running, once an error is found, you do not need to exit the program immediately. Through the console, you can perform some lightweight control and print out the error information. If you don't want your end users to see or use the console, you can easily disable it. I don't think anyone can see it.

Support)

The support system will be used anywhere in your engine. The system contains all the mathematical components (points, planes, matrices, etc.), (internal) Storage Manager, file loader, and data container in your engine (if you do not want to write it yourself, you can also use STL ). This module task is very basic and underlying, and you may reuse it in more related projects.

Renderer/engine core (rendering/engine kernel)

Ha ~ Yes, all people love 3D image rendering! Because there are many different types of 3D world rendering methods, it is almost impossible to make a brief description for all kinds of 3D graphics pipelines with different working methods.

Regardless of how your Renderer works, the most important thing is to make your Renderer components base and clean ).

First, you can determine that you will have different modules to complete different tasks. I split the Renderer into the following parts: visible cut (visibility) collision detection and response, camera, static geometry, Dynamic Geometry, particle systems) billboarding, meshes, skybox, lighting, fogging, vertex shading, and output ).

Each part requires an interface to conveniently implement settings, position, orientation, and other system-related property configurations.

One of the major defects that will be revealed soon is "bloated features", which will depend on what features you want to achieve during the design. However, if you do not place new features into the engine, you will find that everything will become very difficult and the solution to the problem will be particularly inferior.

Another thing that makes sense is to make all triangles [triangles] (or faces [faces]) pass through the same point in the rendering pipeline. (Not every triangle. The list of triangles [triangle lists], slice [fans], and strip [strips] are discussed here) more work is required to allow all objects to pass through the same light, fog, and shadow code, in this way, it is very convenient to make any polygon have different rendering effects by switching the material and texture ID.

This will not hurt the points drawn by a large number of rendering, but once you are not careful, it may lead to a large amount of redundant code.

You may eventually find that the cool effects you need to achieve all of these may only account for about 15% of the Code. This is of course because most game engines are not just graphic representations.

Game interface (game Media)

A very important part of a 3D (game) engine is that it is a game engine. But this is not a game. Components required by a real game should never be included in the game engine. The control media between the engine and game production can make the code design clearer and make the application more comfortable. Although this is some additional code, it can make the game engine very reusable, by designing a script language (scripting language) enough for the game logic) it can also make development easier, and also store game code into the database. If you want to embed your game logic system design in the engine itself, a lot of problems and a lot of modifications will surely eliminate the idea of reusing the engine.

Therefore, you may be thinking about the question: what the media layer of the connection engine and the game provides. The answer is control ). Almost every part of the engine has dynamic attributes, and the engine/Game media layer provides an interface to modify these dynamic attributes. They include camera, model properties, lights, particle system physics, and playing sounds) playing music, handling input, changing levels, collision detection and response) and the top display and Title Screen of the 2D graphic interface. Basically, if you want your game to implement these elements elegantly, it is essential to set this media layer (Interface) in the engine.

The game)

Here, I cannot tell you how to write your game. It's your turn to play. If you have already designed a set of excellent media layers for your amazing engine, I think it will be much easier to design and write the game.

3D Game Engine Design is a huge software project. It is not impossible for a person to complete the design and writing independently, but this can be done in a few nights. You may write several megabytes of source code. If you do not have a lasting belief or passion, you may not be able to accomplish it.

Of course, don't expect your first attempt to write a complete engine and pick a small-scale engine for a small project. If you work hard in your way, you will be able to succeed.