3D Engine design architecture Author: Luke Hodorowicz translation: Chenguang music (2001/9/28) I do not quite understand in 3D, is a translation of motivation due to the content of cheering, two exercise skills in English translation. It is limited by the level and experience, and there is absolutely no shortage of misunderstandings and misunderstandings. Goodwen must be rewarded, you also welcome everyone to reprint:) Introduction (Introduction) Let us talk about how you have written a 3D engine that provides elegant performance. Your engine needs to provide: curved surfaces, dynamic lights, volumetric fog, mirror, portals, SkyBoxes, Node Shadow (Vertex Shaders) , Particle Systems, Static Mesh Models, Grid Model Animation (ANIMATED MESH Models). If you already know how all the functions described above, you may be able to put those Dongdong to a engine. and many more! You must first conceive your engine before you start writing code. In most, you must be eager to be eager to make a game, but if you start writing a code for your engine now, you will feel very uncomfortable, you may be a new special effects and control in the post-development Musou have to rewrite a lot of local code, even to give up ending in failure. It takes a little more than a little more than a long time, which will save you a lot of time, and a little bit of headache. You will not be anxious to architecture a giant project; Maybe you will simply give up it when the engine is not completed, then do something else. Ok, when you master the way you need to know what you need, maybe you can't complete those things. Will the design really complete the same thing, for you, you will feel better, you will be dazzling! Let us analyze which basic components of the 3D game engine with full functionality. First, this is some information for developers who have the corresponding 3D experience but still need some guidelines. This is some of the content entries that are not difficult to master, but you must apply. In order to make your work better, here will give a total of "How much workload" and "how much" into a game engine. I refer to these ingredients, console, support, rendering / engine core, Game Interface, and Tool / Data (Tools / Data) . Tools / Data (Tools / Data) During the development process, you always need some data, but unfortunately this is not as simple as writing a text file or defining a cube. At least, you have to need a 3D model editor, a level editor, and a graphics program. You can purchase some free programs online to meet your development requirements. Unfortunately, you may need some more tools, but you can't get (still don't exist), then you have to write it yourself. Eventually you are likely to design a level of level editor because you can't get what you need. You may also write some code to make a package for a large number of files, and it is very painful for the whole day. You must also write some converters or plugins to convert the model format of the 3D Model Editor into your own format. You also need some tools for machining game data, such as visibility estimates or light maps. A basic criterion is that you might want to set a code that is equal to or even more than the game itself.
Start, you can always find ready-made formats and tools, but after a while, you can realize that you need your engine with a lot of features, then you will give up the previous writing method. Perhaps the current popular use of third-party tools to assist in developing, so you must always pay attention to your design. Because once you publish your engine as OpenSouce or allow modification, then some people will have some people to apply your development results, they expand or do some modifications. Perhaps you should also spend a lot of time to design art, level, sound, music and entity model, which is the same as your design writes games, tools, and engines. The System System (System) is a component that is a communication interaction with the machine itself. When a excellent engine is placed in the platform, its system is the only place that needs to be mainly changed (expanded). We divide a system into several subsystems, including: Graphics, Input, Sound, a Timer, Configuration. The primary system is responsible for initialization, update, and close all subsystems. Graphics Sub-System "is very intuitive in the game. If you want to draw something on the screen, it (the graphic subsystem) does this. Most of us, graphic subsystems are implemented using OpenGL, Direct3D, GLIDE or software rendering (Software Rendering). If you can more ideal, you can even support these APIs, then abstract a "graphic layer" and put it on the API, which will give the customer developer or player more choices. To get the best compatibility, the best performance effect. Input Sub-System requires all kinds of input devices (keyboard, mouse, game board [GamePad], game handle [Joystick]) to do unified control reception processing. (Transparent treatment), in the game, in the game, the system should detect if the player's position is moving forward, directly detects each input device directly, but also transmits the request to the input subsystem to obtain input information, and input sub- The system is really working after the scene (each input device is detected), which is transparent to customer developers. User and players can switch to the input device very free to get unified behaviors through different input devices. Sound System is responsible for loading and playing sound. The subsystem is very simple, but many games support 3D sounds, which will be more complicated. A lot of excellent performance in the 3D gaming engine is based on the Time System. So you take a while to make a good idea for time subsystems. Even if it is very simple, (in the game), anything is triggered through time trigger, but a reasonable design will let you avoid a lot of minimalid control code over and over again. ... (Configuration) is located at the top of all subsystems. It is responsible for reading configuring files, command line parameters, or implementing modification settings. All subsystems will always be communicated with it during system initialization and running.
Switching Image Resolution, Color Depth, KEY BINDINGS, Sound Support Options, and even loaded games, which makes these implementations simple and convenient. It will be more convenient for your engine to design more, which will bring more convenience to debugging and testing; players and users can easily choose his (she). CONSOLE (Console) Ha! I know everyone is happy to do a console system like Quake. But this is indeed a very good idea. By command line variables and functions, you can change your game or engine settings while running without restarting. Output debugging information during development is very effective. Many times you need to test the value of a series of variables, and output these values to the console. It is obviously much better than running a debugger. Your engine is running during the run, you don't have to quit the program immediately; through the console, you can do some lightweight control and print this error message. If you don't want your end user to see or use the console, you can very convenient to disable, I think no one can see it. Support will be used anywhere in your engine. The system contains all mathematical components (points, faces, matrices, etc.) in your engine, (inner) storage manager, file loader, data container (if you don't want to write, you can use STL). The module task looks very basic and underlying, and you will be reused to more other items. RENDERER / ENGINE CORE (rendering / engine kernel) Ha ~ Yes, all people love 3D image rendering! Because this is a very variety of 3D world rendering methods, it is necessary to make a summary description for a 3D graphics pipe with different working methods. It is also almost impossible. Regardless of your renderer's work, the most important thing is to create your renderer component (based) and clean (Clean). First, you can determine that you will have different modules to complete different tasks, I will split the renderer as the following part: Visibility, Collision Detection and Response, the camera ( Camera), static geometry, dynamic geometry, particle system (Particle systems), Billboarding, Meshes, Skybox, Lighting, fog (Fogging ), Node Shadow (Vertex Shading) and Output.
Each of them has to require an interface to easily implement the change setting, the position, orientation, and other properties that may be related to the system. One of the main defects that will be revealed is "characteristics bloated", which will depend on what characteristics you want to achieve during the design. But if you don't put a new feature into the engine, you will find that everything will become more difficult, and the way to solve the problem is very inferior. There is also a meaningful thing to let all triangles [triangles] (or face [faces]) eventually pass through the rendering pipeline. (Not each triangle every time, discussing the triangle list [Triangle Lists], Sector [Fans], Strips], etc.) How to make some work makes all objects of all objects can pass the same light, fog And the shadow code, so it can be very convenient to have different rendering effects that have different rendering effects only by switching the material and the texture ID. This will not hurt the points that are drawn by a large number of rendered, but once you are not your heart, it may result in a lot of redundant code. You may eventually find that all of these you need can only account for only about 15% of the code or even less. This is of course because most game engines are not just graphical performance. Game Interface (Game Media) A 3D (game) engine is important part is ------ it is a game engine. But this is not a game. Some components required for a real game will never contain it into the game engine. The control medium between the engine and the game makes the code design clearer, and it will be more comfortable. This is some additional code, but it enables the game engine to have very good reuse, and the development of the game logic (Scripting Language) can also make the development change easier or more. The code is placed in the library. If you want to embed your game logic system design in the engine itself, a lot of questions and a lot of modifications will definitely let you disperse the idea of this engine. So, you are likely to think about this problem: contacting the engine and the game's media layer provides. The answer is Control. Each part of the almost the engine has a dynamic attribute, and the engine / game media layer (Engine / Game Layer) provides an interface to modify these dynamic properties. They include camera, model, particle system physics, PLAYING Sounds, playing music, input operation (HANDLING INPUT) , The switching level, collision detection and response, and the top of the 2D graphical interface display, title screens, etc. related things. Basically, if you want your game to achieve these elements, it is essential to the interfab in the engine. The Game here, I can't tell you how to write your game. This is a turn to play. If you have designed a good media layer for your favorite engine, I want to be more relaxed in the process of designing the game. 3D Game Engine Design is a huge software engineering.
