shown in other instead.
This article describes in detail the steps taken by the UNIGINE engine when the Engine::init() function is called. For other steps and general information about execution sequence, see the Execution Sequence article.
The engine initialization starts when the main executable application (64-bit version of the .exe file, debug or release one) loads the corresponding UNIGINE library (.dll, .so, or .dylib). From this point on, the following steps are performed:
- The UNIGINE memory allocator is initialized for faster and more optimal allocations compared to the default system allocator. In the engine code, it is set via the USE_MEMORY directive.
- Four (4) threads are created: a sound, a world, a render, and a file system thread.
If you pass a project name via the command line or on engine initialization, all data (such as log files, cache, and configuration files) are stored in the user's home directory as follows:
- On Windows, in the C:/Users/<username>/<project_name>/ folder
- On Linux, in the /home/<username>/.<project_name>/ folder
- Otherwise, data is stored in the application folder (<UNIGINE SDK>/bin/ with the binary executable file).
- A log file is created. If not specified in the command-line options, the default log file is placed in the application directory under the name log.txt.
Remaining command-line options are parsed (the ones that haven't been parsed previously). These options specify basic video settings, such as a graphics API to be used for rendering (DirectX or OpenGL; also you can disable the graphics API), size of the application window, and so on.
- A path to the project *.cache files is set. Usually cache files include compiled shaders, system and Editor Logic.
- A custom plugin library can be loaded at any moment of UNIGINE run time.
- The File System is initialized. If project files are packed into UNG or ZIP archives protected by a password, the engine checks if the password coincides with the password set for the binary file (if any) and loads these archives.
- The dedicated asset management subsystem of the Engine's file system is initialized and performs scanning for all run-time files.
- Render and sound managers that will automatically organize and handle rendering and sounds are initialized.
- The Boot screen is shown based on the default.boot configuration file.
- If the materials_loading_mode console variable is set to 2, all shaders in the application are compiled and cached.
- The application window is created based on the specified settings.
- All engine subsystems (such as visualizer, physics, sound, render, pathfinding subsystems, and so on) are created.
- Sound and file system threads are run.
- External definitions passed in the -extern_define command line option are set.
- The init() functions of all loaded plugins are called.
- Console commands from the command line are queued for further execution.
- The Splash screen is shown if it is enabled.
The System Logic is loaded and started. Basically, the System Logic performs housekeeping necessary to start and keep the UNIGINE-based application going. It stays loaded during the whole UNIGINE run time.
The default system script, when initialized, does the following:
You can replace the default system script located in the data/core/unigine.usc with a custom one. In this script, you can set your own loading screen for the project, specify custom modules to be loaded, and so on. For large projects, it makes sense to specify the world you want to load right in your system script.
- Loads a localization file.
- Initializes the main menu.
- Sets the Loading screen, if necessary. It is better to set the loading screen before loading a world. In this case, displaying a loading screen will give the engine time to load resources and compile shaders. By default, a standard UNIGINE screen is shown.
If you use a custom system script, it performs the logic you implemented.
Console commands from the command line that were queued previously are run.If you want to run console commands from the system script, they are run after the queued console commands.
If the render_shaders_preload console variable is specified in the command line, shaders used in the world to be loaded are compiled and cached.However, a shader cache file is large and its loading on engine initialization drops performance.
If the initialization is completed successfully, a non-zero value is returned, and the execution process continues.