UE3 code reading needs to know

Transferred from: http://www.cnblogs.com/hmxp8/archive/2012/02/21/2361211.html

Master a huge engine, to grasp the real hard at once, slowly from the editor,script, the details of each module, and then to the source code, step by step must be solid, but also, must learn to warm so know new, have a lot of things at the beginning of a read and past, thought simple, actually otherwise, today, I don't want to learn a lot from the most basic codeorientation.

Here is a summary of the relevant information:

Read a 3D engine's method memo (turn from civilian program-Linghuye's blog)

To read with the problems shared by the engine system, do not be led by the implementation of the specific engine, to think about how the engine implements or bypasses (for example, low-end machines) these inevitable problems.

First of all, the most important thing to do is to debug a home View program in debug mode, then walk a few times along the code stream, wander through the code, generate a first impression, pay attention to the basic tools facility class (such as String memory Management), about 3 hours.
Then take each of the following questions (in no particular order) to go through the process, take the logic, understand the engine business processing methods.

The 1.setstreamsource,setindices,drawindexedprimitive call is where (which CPP which class is which function), the whole project has several drawindexedprimitve, Drawprimitveup,drawxxx, is the unified management, or fragmented distribution in each CPP class?

2. How is texture resource managed, handle, ID, pointer, by usage time, by usage count? How are the model vertex resources managed and are there optimizations on buffer allocations (such as vertex buffer consolidation)? How does the rendered instance data be managed and differentiated from the resource concept? How are pure 3D resources managed, such as Shader/rendertarget?

3. How is scene management structured, and how does it include differentiating node instance data from resource data? How are the lenses accessed by each module? Where is the line of code that excludes invisible objects? Is it compatible with a variety of algorithms, and what are the specific algorithms? Regardless of the algorithm used, does the scene management module provide a clear requirement definition interface?

4. Where is the skeletal animation calculated, and how exactly is the vertex multiplied by the matrix which is in which CPP's line of code? Where is the socket implemented? If there is a high-level animation system, where is the skeleton, what is the function? What is the line between the matrix transitions of the action fusion?

5. How asynchronous data loading is done, in which CPP, which module is managed? Load of each resource read CPP code line where?

6. How does the rendering pipeline provide a depth map for shadowmap, how to provide scene rendertarget for cubemap, surface reflection? How do I manage fixed pipeline status Rasterstate?

7. How the Material Management system works (usually technique + multipass), how to integrate the pipeline, how to theoretically ensure that all kinds of effects can be achieved? How to abstract compatible fixed and programmable pipelining? If it's abstract management, how do you abstract different data under different technique? Is there an independent post-production effect in the pipeline, or is it expressed as a material? Can the material be scripted? The material is to be grouped, where is the sorted code snippet in which CPP?

8. What drawxxx is the effect of the particle system in the end? is the particle system a dynamic formula calculation (regardless of the specific formula) or frame animation?

9. Interface 2D How is Texture draw supported? How is text rendering supported, especially how to support Chinese, and how font resources are managed? Do you use FreeType to support East Asian text?

10. How does the interface of the physical system define the needs of the engine? or just use it in a messy way.

architecture diagram for an engine

Not necessarily the same, but can be very well referred to

(http://blog.csdn.net/Jaredz/article/details/4411614):

• Code explanation for Unreal Engine 3
  • Overview
  • Directory structure
  • Engineering structure
  • Game/Engine Code
  • Unreal C + + standard
    • Object naming rules
  • UnrealScript file
    • Option modifier for Class
    • Auto-generated header file using the native option modifier
    • Noexport option modifier
  • Uobjects
  • Aactor
  • Serialization of
  • Configuring the System
  • Main tick (update) loop
  • Conclusion

Overview

This document is provided for programmers who are starting to develop with the Unreal engine. It simply explains the various aspects of the underlying code. It's definitely not a complete guide to the engine, but a good preparation after you compile the engine code. If you have not compiled your project yet, visit the first access: Getting Started Guide or QuickStart page.

Directory structure

When the UE3 base code is synchronized from perforce, there should be a directory called UnrealEngine3 in the root folder of your Perforce depot (warehouse).

The following directories are available in the "UnrealEngine3" folder:

• Binaries -This file contains a binary object. For example, the compiled engine/game version, the DLL file required by the UE3 (Direct X, WX runtime system, etc.), the Editor resource file (icon image).
• Development-This is where the source code of the engine really exists, in this folder there are:
  • Build  -Here stores batch files that are used to start various types of compilation on our Continuous Integration Server (CIS) [Continuous Integration Server]. CIS can check the compilation for us and capture compilation errors as much as possible.
  • Documentation  -the folder where the document files are stored. Our auto-generated Windows Help documents are stored here (unrealengine3.chm). This help document is a great resource to help you quickly navigate through the Unreal source code.
  • External  -All library source files that are not epic companies are stored in this folder. such as Libpng, WxWidgets, zlib, CG and so on. The
  • Intermediate  -All intermediate compilation files are stored here. obj files, precompiled header files, and so on.
  • Src  -source files and project makefiles. The primary UNREALENGINE3 solution exists in the folder. The folder for each project is also included in this solution. An instance project can be subdivided into directories like this:
    • Game folder (game folders)
      • in the Project home folder is the project file for the project Visual Studio.
      • Classes  -the folder where the. UC (UnrealScript) file is saved.
      • Inc  -the folder where the. h file is saved.
      • SRC  -the folder where the. cpp file is saved.
  • Tools  -Save all Source-code folders for various engine-related tools, such as Ude, vistual Studio Macros (Vistu AL Studio Macros) and some command-line tools.
• engine/game Folders -after the binaries and Development folder is the folder engine, then is the folder for each game that uses this engine.
  • Config -contains the. ini file that is used to save the game settings.
  • content -the folder that contains the game content pack.
  • Localization -a folder that contains any localized text for that game.
  • Logs -Contains the folder of log files that were generated when the game was run.
  • Script -Contains the compiled UnrealScript code (. u file) for that game.

Engineering structure

To separate the system and help maintain cross-platform compatibility, UE3 is split into multiple projects.

The basic structure is as follows (from the layer code to the high Level code):

• Core
• Engine
• Editor
• UnrealED

Note that all of these projects have to be built on each other, which means that the engine relies on core, editor relies on engine, unrealed relies on editor.

• Core: Core is the lowest level class, which refers to something like a string class, an array class, a memory manager, and so on. Here is where the core script and the loading code exist.

• Engine: The engine folder is where rendering and gameplay code exist. It also includes actors, collision detection, and many other subsystems. This is where most of the ' Game Interface ' code is located.

• Editor: Editor consists of classes and programs that are used only when the editor is running. These classes allow the user to manipulate polygons, brushes, terrains, and other actions that are normally not performed in the game.

• UnrealED: UnrealEd is the real UI implementation of the editor, which is where the editor application code exists. We currently use Wxwidgets as our UI toolset. Any wxwidgets code that needs to be written is put into the unrealed. The idea here is that the ' editor ' project contains the functional code for all the editing tools, while UnrealEd is only the UI wrapper for those features.

There are also a number of specific features for other platforms, such as D3DDRV (the rendered direct 3D implementation), Windrv (creating Viewports, Windows implementations that handle events, and so on). If a project is a specific platform implementation of a cross-platform interface, it is likely that it will require additional suffix DRV.

Game/Engine Code

Unreal Engine typically divides the game code and engine code into 2 different programming languages:

• Engine Code:
  • Write in the C + + language.
  • Use the ". H" and ". cpp" extensions, which are stored in the project's "Inc" and "SRC" folders, respectively.

• Game code:
  • Use Unreal Engine's unique language: UnrealScript. This language is similar to Java in many ways. Please refer to the UnrealScript reference page for more information.
  • Use the extension ". UC", which is stored in the project's "Classes" folder.
  • Compiled prior to execution.

Unreal C + + standard

• Unreal has defined its own set of data types (,,, and so on) throughout the engine INT FLOAT UBOOL . These data types should always be used, rather than standard C + + data types, to ensure cross-platform compatibility.
• Unreal uses a wide character () for the string TCHAR . All string literals need to be encapsulated in a TEXT() macro to ensure that they are correctly converted to wide characters.

Example:

Const tchar* teststring = TEXT ("My Test String");

For more information about the Unreal encoding specification, refer to the Coding Specification page.

Object naming rules

It is important to append a letter prefix to the class and struct, because Unreal uses these prefixes to let programmers know what to do with an object.

• Fclassname
  • Example: Fstring, Fvector
  • application: any object with a character prefix ' F ' is a standard C + + struct (struct) and class, and these objects do not have to inherit any other special thing.

• Tclassname
  • Example: Tarray, TMap
  • application: any object with a character prefix ' T ' is a template class, and these objects do not have to inherit any other special thing.

• Uclassname
  • Example: Uobject, Uengine, Ugameengine
  • application: any object with a character prefix ' U ' is a class or struct (struct) inherited from Uobject. Uobjects are special because they can be automatically garbage collected by the engine. This means that uobject will never be deleted! when there are no references to them, the engine will automatically garbage-collect them. This also creates another problem that needs to be handled by the programmer: How to store a reference to a uobject. We solve this problem by serialization, and the serialization will be discussed later in this document.

• Aclassname
  • Example: Aactor, Abrush, Apointlight
  • application: any object with a character prefix ' A ' is a class or struct (struct) inherited from Aactor. Aactor is the basic ' Actor ' class. Actors and general Uobject are different as they are in the game world by actual location and real projects. Only actors can replicate on the network and use the UnrealScript state. Actors can also inherit Uobject, and likewise follow the rules that cannot be deleted that apply to objects with the U prefix.

UnrealScript file

This document only briefly addresses some of the issues that a new programmer needs to deal with when using the Unreal engine.

For a comprehensive description of UnrealScript, please refer to the UnrealScript Reference guide page.

Option modifier for Class

When declaring a class, you can specify some options for UnrealScript classes. For a detailed description of this feature, refer to the UnrealScript Reference guide: Unrealscriptreference#class_overview.

In this tutorial, we'll briefly cover one of these options because it's easy to make a mistake for a programmer who knows the Unreal engine.

Auto-generated header file using the native option modifier

If you specify an option for a class native , the UnrealScript compiler will automatically generate the corresponding C + + class declaration for that Urealscript class. These header files have the suffix word "Classes", which is generally related to the name of the project. such as "EngineClasses.h", "EnginePhysicsClasses.h", "EditorClasses.h" and so on.

Because native UnrealScript will automatically generate C + + classes when specified, programmers should be careful not to modify the auto-generated header files, but instead modify them in the. uc file.

Noexport option modifier

Some classes native also specify options at the same time as specified. noexport These classes cannot automatically generate the appropriate C + + sections, but still expect C + + declarations to exist. So programmers have to write a header file themselves. There are many examples of this situation in the engine (refer to Ueditorengine in the Development/src/editor/inc/editor.h file).

noexportThe UnrealScript class needs to be ' synchronized ' with their C + + counterparts. Therefore, the programmer should be careful when modifying the UnrealScript file.

For more information on compiling the native class, refer to compiling the native class.

Uobjects

Because Uobjects is automatically managed by the engine, there may be some unique, subtle differences that new programmers are unfamiliar with:

• Uoject never use new to create, but use ConstructObject template functions.
• Uoject never use delete to delete. The garbage collector will automatically handle deleting uobjects.
• UObject::StaticClassCan be used to get a pointer to any uobject static instance.

Aactor

The Unreal World object contains a list of all the actors within it.

• new ConstructObject You should use a function if you cannot use or to create aactors– SpawnActor .
• To destroy an actor, use the function defined in Uworld DestroyActor .
• Aactors can contain a set of uactorcomponents. These are useful objects that provide the functionality of a smaller, orthogonal unit. This can make a light source, particle system, sound effect and so on.

Serialization of

A powerful feature of the Unreal engine is that it can automatically serialize all the properties of uobjects defined in a. uc file according to the name. This allows you to change the order of attributes, add new properties, move properties in the class hierarchy, and do not break backward compatibility.

Because the Unreal garbage collection system uses serialization to determine which Uobjects is available , you need to make sure that you have a serialized reference to any uobjects that you do not want to clear. Creating a tool in the editor is a situation that can cause problems. We generally inherit the tool from the Fserializableobject interface, which provides a =serialize= function that can be saved to a reference to the uobjects created in the tool by implementing this function.

void Fsometool::serialize (farchive& ar) {    ar << someuobjectpointer;}

If you use the native serialization tool to serialize persistent data, you need to explicitly support older versions of serialized data. To enable this feature, two version numbers are stored in each package, one for use by the engine and one for authorized users. When an authorized user is making a serialization change, it can be updated and GPackageFileLicenseeVersion will be checked during deserialization Ar.LicenseeVer() to determine which version of the sequence is being stored for data exchange.

Configuring the System

UE3 uses a hierarchical configuration system, which means that default values will be passed down from the base (base class) configuration file, and subclasses can overwrite the configuration files of those base classes.

All the configuration files are. INI file, followed by a special naming convention:

• The base class configuration file is placed in the Unrealengine3\engine\config folder, and the file name has the prefix word Base .
• Each file has its own Config folder and a group. INI configuration file. These files are prefixed with the name of the game that owns them.

For example, the structure of the editor configuration file would be:

• Engine\config\baseeditor.ini
  • INI file for "Examplegame": Examplegame\config\defaulteditor.ini
    • INI file for "Examplegame": Examplegame\config\examplegameeditor.ini

This system is powerful because it is also used to populate the data for the attributes defined in the script, and these script properties can be configured very quickly for any part of the game.

Main tick (update) loop

The main tick loop of the engine can be found in the LaunchEngineLoop.cpp file: FEngineLoop::Tick() . This function calls the function of the Uengine class Tick so that it will update the game World (Uworld) and monitor other subsystems of the update engine.

If you want to get information about how the actor ticking (update) loop function works, please refer to the Actor Update page

Conclusion

Unreal Engine programming is daunting at first glance, but over time you will begin to understand that some complex design decisions make it what it is today. Now that you've learned the first quick tutorial on Unreal Engine programming, take a look at the other technical resources available to programmers on UDN.

Here are some useful pages for beginners:

Unreal Engine Coding Specification:
Coding specifications

How to create a new game project using Examplegame:
Examplegame Guide

How to track your memory usage in UE3:
Memory use

How the actor update loop works:
Actor update

UnrealScript Reference Guide (this is a must-read page):
Unreal Script Overview:

For more information about compiling a class labeled ' Native ':
Compiling the native class

Common technical issues in Unreal Engine (FAQ):
Common technical issues

Classificationform
Relevant topics	Unrealscripttopics, Gettingstartedtopics, Technicaltopics
Engine Build	None/all
Applicable platforms
Document availability	Ue3licensees
Access Required
Origin	Codeorientation
Revision	1.11
Language	Zh

UE3 code reading needs to know