This page has been translated automatically.
Recent news:
Table of contents:

UNIGINE 2.7: New Voxel GI Solution, Synthetic Terrain Generation, Improved Assets System, Refactored Properties, More Dynamic Environment

Key Changes

  • Updated SDK editions
  • Voxel GI solution, which doesn’t require UV mapping
  • Improved assets workflow for both artists and programmers
  • Major update of UnigineEditor 2
  • Refactored and extended properties system
  • FBX import in runtime
  • Dynamic destruction of trees and grass in runtime
  • Cross sections visualization
  • Improved anti-aliasing
  • Automatic screen space bevels
  • Easy configuration for multi-channel rendering, including templates (dome, wall, CAVE, etc.)
  • Improved performance profiler
  • Arbitrary terrain generation using non-georeferenced data
  • Procedural generation of buildings (2.5D)
  • ObjectTerrain to ObjectTerrainGlobal migration tool
  • General performance optimizations

This release was aimed at making your experience with UNIGINE 2 even better by improving the UI and functionality of the Editor and tools and adding more useful and long-awaited features to make the work of artists and programmers easier and more efficient.

Design by Eugenia Bulatskaya

Updated SDK Editions

SDK editions and prices were updated, detailed information is available at

  • UNIGINE 2 Entertainment (previously Starter)
    • Enabled custom splash screens
    • Added advanced performance profiler
  • UNIGINE 2 Engineering (previously Professional):
    • Added support for geo-coordinates
    • Added Landscape Tool
  • UNIGINE 2 Sim is kept as it is (the most complete edition of the SDK)

New Voxel GI Solution

Voxel Probe Lights

Introducing a new GI system which does not require UV layouts for models. So, there’s no need to create UV channels for this purpose anymore. Moreover, creating high-quality UV layouts for the most of the content used in architectural visualization (high-poly models) is a very difficult task.

This solution worked good for our Oil-Refinery demo having a high density of high-poly 3d models, as making UV layout for the whole scene would be next to impossible.

The workflow is as follows:

  1. Import your content to the Editor,
  2. Place it on the scene,
  3. Place a new Voxel Probe Light that enables you to bake global illumination within its volume
  4. Click Show Bake Lighting specify necessary parameters and click Bake.

That’s it! You’ve got realistic lighting that has very modest hardware requirements doesn’t depend much on screen resolution, works perfectly with multi-monitor setups and even in VR.

The fact that Voxel Probe Light is implemented as a separate object offers you a number of advantages. You can enable/disable it at run time changing the lighting of your scene. You can smoothly blend GI from several Voxel Probes to add more details at certain areas of the scene. Moreover, dynamic objects moving along the walls, for example, will receive GI from them without any extra lights required.

It is very important that this technology works with any object in the scene, be it a decal or a light source (including light volumes), fog, vegetation, or even custom materials, that you create. To simulate a light source you can just enable emission for the object’s material.

In case if your scene requires dynamic change of lighting during the day-night cycle, you can use the Use Sun Color option to enable it.

For more information on baking GI and using Voxel Probes, please follow the links below:

Listed below are the drawbacks and benefits of this technology for various applications.


  • Gamedev: GI solution that works with both static and dynamic objects. Does not require UV. High performance, working even in VR. Scalable quality, baking for preview or final baking with the highest quality. Easy to use: place the Voxel Probe, click a button, get the result. Any object in the scene can become a light source, just enable emission option for its material.
  • Archviz: Does not require UV. Works with high-poly 3D models. Ability to enable/disable lighting per object changing the lighting of the scene (e.g. turning the lights on and off). Ability to bake a large number of GI bounces up to tens of them, increasing the required rendering time just twice. Any object in the scene can become a light source, just enable emission option for its material.
  • BIM: Does not require UV. Works with high-poly 3D models of any complexity including CAD models. Does not depend on the number of polygons in the scene. High performance, working even in VR.

Design by Eugenia Bulatskaya


  • This GI is pre-baked. Works only for a certain scene. Changed the scene - re-bake lighting similar to lightmaps.
  • High-quality GI requires a lot of time to be baked, up to several days. Previews can be baked in several seconds depending on the scene.
  • Highly-detailed baked GI may consume gigabytes of disk space, however, moderate quality will require ten times less.

UnigineEditor 2

It is already the third release having the UnigineEditor 2 as the main tool to create and manage your virtual worlds. We’ve used our experience and your feedback to resolve issues and add new features to facilitate your work and make it more intuitive and efficient.

The time has come to say goodbye to the old Editor1. From now on, UnigineEditor2 is the one and only.

Improved Assets Workflow

Refactored and improved Assets System simplifies control and provides strong synchronization between assets and runtime files. Moreover, it is easier now to access your files via code.

The assets folder was removed: all assets of your project are now stored in the data folder. To avoid data duplication, runtime files are now generated only for certain types of assets. If an asset is in UNIGINE’s native format, no runtime files will be generated. Such an asset will be treated and used as a runtime file. All generated runtime files are stored in subfolders of the data/.runtimes folder and have constant GUIDs.

This approach offers the following advantages:

  • All operations with assets including creation, deletion, copying, and relocation become simple and clear.
  • No more garbage files in your project’s folder: orphan runtime files with no assets linked to them will be removed in a timely manner.
  • Name collisions are avoided.

The structure of the data folder is shown in the figure below:

Multi-Threaded Assets Processing

Performance increased due to optimizations of the assets workflow gets a significant boost from multi-threaded processing. Different assets are processed in separate threads, so, importing a lot of textures and materials, or a bunch of heavy CAD models in fbx format will be much faster now.

New Placement Tools

New Placement tools with advanced snapping options and hotkey support facilitate the process of assembly of complex modular objects (e.g. buildings, pipelines, etc.).

Now you can use arrow keys to move, rotate, and scale the nodes in the world. Using arrow keys while holding a Shift key pressed will clone and place a node with the selected step in the specified direction. You can also quickly change elements to be placed (node references or static meshes stored in a certain folder of your project) with the mouse wheel. This speeds up the whole process, as otherwise you would have to find the desired asset in the Asset Browser every time, drag it to the scene, and adjust its position.

Other improvements were made for this release:

  • Significantly improved content validation, which is especially important for projects with large number of assets (over 50k). Validation time for such projects reduced from minutes to seconds.
  • Added support for per-node property modification.
  • Added editing of physical joints.
  • Added advanced filter for nodes in the World Hierarchy window. Managing nodes in a large world is much easier now. You can select which node types to display in the hierarchy. You can temporary show all objects by clicking Enable All (your current filter settings will be preserved).

  • You can now drag a whole folder to the Asset Browser instead of selecting all files in it.
  • Changed format of the guids.db file from binary to text, now "file path - GUID" pairs are represented in human-readable form for convenience
  • Reduced snapping step (snap by grid, snap by scale) for higher precision when building scenes
  • Double-clicking on a *.landscape asset in the Asset Browser will automatically open it in the Landscape Tool.
  • Improved UI of the Environment Probe Light
  • Added hotkeys for console commands: shaders_reload (F6) and materials_reload (F7)
  • Fixed single screenshot grabbing by the VideoGrabber with render_post_materials enabled
  • Fixed bug with object's local transform error accumulation
  • Fixed issue with missing custom properties when loading a world via the world_reload console command
  • Fixed undo for objects with a complex hierarchy
  • Fixed various issues with hotkeys
  • Fixed Editor crash on FieldShoreline texture grabbing
  • Fixed bug with incorrect node removal from a World Clutter
  • Other bugfixes and UI improvements.

Refactored Properties System

We refactored the Properties system, for a cleaner API and easier hierarchy management. All properties used in the project are now loaded on the engine start-up. You don’t have to worry about including property libraries anymore. Loading order of properties does not matter as well. All changes to a property file are tracked by the Editor.

The main changes are as follows:

  • Removed property libraries. Now each property is stored in a separate file.
  • Now there are 2 main types of properties:
    • Manual properties implemented and modified manually by programmers. A manual property at the top of the hierarchy is called a base property. There are 2 built-in Read-only base properties: node_base and surface_base.
    • User properties inherited from the manual ones and adjusted via the UnigineEditor by 3D artists.
  • Properties hierarchy is based on GUIDs.
  • Reparent operation is now available for user properties via API.
  • Multiple properties can now be assigned to a single node.
  • Live edit of properties.
  • Properties can be used by the Experimental Custom Component System to implement application logic.

Accessing Assets via Properties

Every resource (asset) used in your project, be it a node, a mesh, a material, a texture, or any other, has a unique identifier (GUID). A GUID identifies a path to the asset (i.e., location of the asset in the project). GUIDs are used to keep all links and dependencies between the assets, regardless of their name and location within the project.

Using GUIDs to link your assets is safer than using file names, as you don’t have to worry, that your material will lose a texture when you change its name. However, managing GUIDs directly is rather confusing.

Property is a convenient way to link certain assets to a node via GUIDs without even thinking about them, giving you easy access to these assets. There are a number of property parameter types making it possible to do so:

  • node - for nodes
  • material - for materials
  • property - for properties
  • file - for all other files (textures, meshes, sounds, etc.)

For more information on using properties for this purpose, please refer to the article Accessing Nodes and Files via Properties.

Experimental Component System

Introducing new experimental Component System, that allows you to implement your application’s logic via a set of building blocks - components, and assign these blocks to nodes. A logic component integrates a node, a property and a C++ class containing logic implementation.

The basic workflow is as follows:

  • Inherit a new C++ class representing your component from the ComponentBase Class.
  • In the header file determine and declare the list of parameters to be used by this component. All of these parameters with their default values (if specified) will be stored in a dedicated property file.
  • Implement component logic inside the certain functions (init(),update(),render(), etc.), that will be called by the corresponding functions of the Engine's main loop.
  • Register the component in the Component System.
  • Assign the created property to a node to give it the desired functionality.

Each time a property registered in the Component System is assigned to a node, an instance of the corresponding component is created. This instance will be deleted when the corresponding property is replaced with another one or removed from the node’s list, or when the node is deleted.

The logic of a certain component is active only when the corresponding node and property are enabled. Thus, you can enable/disable logic of each particular component at run time when necessary.

You can assign several properties corresponding to different components to a single node. The sequence in which the logic of components is executed is determined by the order of corresponding properties in the list.

Components are assigned to nodes by property name (so beware not to create user properties having the same name as the component's property).

You can also create components for existing properties.

Components can interact with other components and nodes.

The Component System is extendable and can be easily modified to add the desired functionality if necessary.

Application logic of the VR Template Demo project is now implemented using the new Component System.

For more information on the Component System please check out the sample and follow the links below:

Dynamic Destruction of Trees and Grass

Improved runtime modification of grass and clutters is now available, enabling you to modify the environment in your application - cut down trees in the forest or stamp the grass flat when driving a vehicle, simulate forest areas ravaged by fires and a lot more to add interactivity and realism to your virtual worlds.

Runtime terrain modification will give you even more power to control the environment: dig trenches or make shell craters.

You can check out some of these features in the extended Tank Demo included in all SDK editions.

Cross Sections Visualization

Now it is possible to render cross-sections of complex CAD models. This feature is available via the new Cross Section state added to the mesh_base material.

In order for cross sections to be rendered the Two Sided Common option, as well as Emission and Cross Section states must be enabled. A sample illustrating this effect called Cross_Section can be found in the Samples demo package, included in the SDK.

Improved Generation of Grass and Clutters

Added the ability to cut out the grass in the areas of intersection with objects and decals (e.g. can be used to remove grass under houses or from the surface of roads projected using decals). The grass will be cut out by objects and decals that have their intersection mask matching its Cutout Intersection bit mask (one bit at least). Cutout Inverse option allows you to determine whether the grass should be rendered inside or outside the areas determined by the cutout intersection mask. Both these options are available via the Grass tab in the Parameters window. You can also manage grass cutout via API.

The same options are available for Mesh Clutter and World Clutter objects.

The list of API improvements includes the following:

Improved Anti-Aliasing

Both TAA and FXAA implementations have been improved.

Blur effect of the TAA can be significantly reduced by enabling the Fix Blur option, resulting in a sharper image. New TAA Samples and Pixel Offset parameters are available for adjustment to help you reduce flickering of small elements on the screen.

Rewritten FXAA now offers better results and can be used over the TAA to obtain even smoother image.

Both TAA and FXAA parameters can now be adjusted via the common Antialiasing section of the Rendering settings, that you can open by selecting Windows -> Settings -> Render -> Antialiasing

Screen Space Bevels

Introducing a new effect beveling edges of arbitrary geometry without the need to bake normal maps and any extra polygons. Ideally suitable for various high-poly engineering CAD models, where baking normal maps is difficult and beveling by adding more geometry is unacceptable due to a significant impact on performance. This feature can also be useful in various architectural visualization applications for buildings, furniture and other such geometry required to have smooth and neat beveling. The performance of this effect is is absolutely independent of geometry complexity. It can be adjusted per material and even modulated using a custom texture if necessary.

A sample illustrating this effect called SSBevel can be found in the Samples demo package, included in the SDK.


As the Global Terrain object evolves and can now be generated using non-georeferenced data, the old Terrain object should be considered deprecated and will be removed in future releases.

You will not be able to create or edit a Terrain object via the Editor, as it will only be supported as a run-time object.

A migration tool is available to convert your Terrain object(s) into a Global Terrain.

ObjectTerrain to ObjectTerrainGlobal Migration Tool

Terrain Migration Tool enables you to migrate your Terrain object or multiple objects into a Global Terrain keeping all its details and visual appearance.

To perform migration do the following:

  1. Open your project in the UnigineEditor.
  2. Select the Terrain object(s) that you want to migrate. It is recommended to select all Terrain objects in the scene: they will be migrated into a single Global Terrain.
  3. Open the Terrain tab in the Parameters window and click Migrate. Enabling the Automatic option will launch migration process in fully-automatic mode.
  4. Selected Terrain(s) with all details will be converted into a single Global Terrain named migrated_terrain, the old Terrain(s) will be disabled, but not deleted from the World hierarchy.
  5. Generate the Global Terrain by clicking OK in the Steps window of the Landscape Tool that opens. If the Automatic option has been disabled, you will need to click the Generate button in the Landscape tool window first.

    As a result, the migrated_terrain node will be updated. Values of the albedo, roughness, microfiber and material mask parameters of the ObjectTerrain material will be copied to the ObjectTerrainGlobal material. If several ObjectTerrains are migrated, the material parameters of the first selected one will be copied.

  6. After making sure everything looks as it should, you can click Remove files to remove old Terrain objects from the scene and clean up all associated runtimes. Skip this step, if you are going to repeat migration.

If you want to repeat migration of the ObjectTerrain(s), remove the ObjectTerrainGlobal generated during previous migration to avoid issues.

The Terrain Migration Tool produces the following folders:

  • In the <terrain_name>_migration_project folder, the generated terrain data is stored.
  • In the root of the data folder, texture arrays are stored: they are copied "as is".
  • In the <terrain_name>_terrain_migration_files folder, the data source files (height, albedo, masks sources), height and albedo textures are stored.

Migration to ObjectTerrainGlobal gives you the following advantages:

  • Optimized data streaming, no more spikes
  • Ability to modify your terrain via the Editor using brushes
  • Ability to create limitless terrains
  • Merging several old Terrain objects into a single Terrain Global object to represent large terrains
  • Flexible LOD system with variable number of LODs to tune for best performance
  • Support for insets, - you can create high-detail areas within the low-detail ones
  • Support for triplanar and displacement mapping for more realistic visual appearance
  • Ability to make the terrain curved (available in Sim edition only)

However, there are also a number of things you should be aware of:

  • Shading of the ObjectTerrain and ObjectTerrainGlobal objects differs, so, their visual representation may also differ.
  • LOD settings can be adjusted to increase performance.
  • Some detail materials may require additional adjustment after migration: tiling of detail textures and detail masks blending should be readjusted.
  • ObjectTerrainGlobal doesn't store information about holes of the migrated ObjectTerrain.
  • Current terrain modification API is a little bit more complicated, but it is currently being refactored. Improved simple and clear API will be available in the upcoming releases.

For more detailed information on terrain migration, please refer to the ObjectTerrain To ObjectTerrainGlobal Migration section.

Improved Terrain Material

Improved the terrain_global_base material by adding several new parameters for fine tuning of geometry optimization, shadows and LOD blending:

  • Subpixel Polygons Reduction parameter determines the minimum polygon size (in the screen space) relative to the area seen in the viewport, to remove too small polygons that are barely visible, in order to increase performance.
  • Back Face Culling parameter is used for culling of the tessellation patches that have their back faces turned to the camera. The number of polygons can be significantly reduced (e.g. culling back faces of a large mountain) and increase performance.
  • Frustum Culling Padding parameter is used to control culling of the tessellation patches outside the viewing frustum.
  • Shadow Offset parameter enables to adjust the look of shadows in cases low-poly LODs cast shadows on high poly LODs in areas, where there should be no shadows should.
  • LOD Padding parameter can be used to adjust smooth transitions between terrain LODs and increase performance.

In case if your terrain does not require insets, you can disable this option to increase performance. To do so, just uncheck the Use Insets on the States tab.

Landscape Tool

The Landscape Tool gets a new more user-friendly UI and a set of new features. Landscape Tool now allows you to generate an arbitrary terrain using non-georeferenced data, flexible procedural generation of buildings on the basis of vector data is also available.

Synthetic Terrain Generation

This one is really a long-awaited feature: the ability to generate an arbitrary terrain (ObjectTerrainGlobal) without georeferencing, according to your own preferences is now at your disposal!

You can now create and use any png, tif, jpg, psd, dds, tga image or a set of images (tileset) as a data source for your terrain.

To generate a terrain based on the raster images with no geodata, the Flat mode should be selected. In this mode, no reprojection is performed for the loaded data sources and terrain curving option is not available.

The Flat mode is available for all SDK versions.

You can also mix non-georeferenced data sources with georeferenced ones.

Custom Projection

Added ability to change output projection of the terrain (play area in preview map) from geodetic pivot to a custom one. This option can be used for example to match the generated landscape with existing geometry (buildings etc.) that uses custom projection.

Custom projections should be described in WKT (Well known text) format stored in .prj files. Such files can be generated by Global Mapper.

Procedural Generation of Buildings

Procedural generation of buildings on the basis of shapes contained in vector data sources (2.5D). You can specify a tag to select the data from the source and determine attributes to be used to define building category and the number of floors. You can also customize texturing of generated buildings to add more diversity and realism to the generated landscape.

For more information on procedural generation of buildings please refer to the Generating Buildings article and check out the new Procedural City Generation Demo.

More Realistic Light Scattering

Improved scattering with new default LUT’s generated on the basis of physically correct scattering, provide a more realistic sky color gradient.

Reflection Occlusion for Water

We have improved water rendering to enable simulation of reflection of waves on the water surface removing too bright areas on waves close to the horizon. For this purpose the Reflection Occlusion parameter was added to the water_global_base material.

Water foam visibility distance was made independent of the camera’s far clipping plane to reduce texture tiling at high Beaufort numbers.

Better Sun and Moon

Improved Sun and Moon rendering now allows you to set up custom textures for these celestial bodies via the Environment rendering settings.

Per-light Lens Flares

Added Lens Flares effect for Omni, Projected and World Light sources. This effect is fully customizable - you can set a custom texture, number of flares and fine tune each of them individually. This feature allows you to have different lens flare settings for different light sources at the same time.

You can adjust lens flares for the selected light source in the UnigineEditor via the corresponding group displayed in the Parameters window. Or you can also control this effect via API, using the Light::setFlareEnabled() method and adjust each billboard used for the per-light lens flares effect via the LightFlareBillboard Class

Improved BRDF

Shading improvements include replacement of diffuse BRDF with a more realistic model resulting in reduction of overexposure. Improved diffuse lighting from the environment. Implementation of energy conservation and Glossy Fresnel effect. Now materials, especially glossy ones, will look more realistic. A new Fresnel Opacity parameter was added for transparent materials to simulate the thickness of thin walls, which is useful for glass simulation.

Other Rendering Improvements

  • Increased maximum translucence intensity for a more realistic result. This can be especially useful for vegetation rendering. Please be aware that vegetation may become slightly brighter after the upgrade.
  • Added visibility distance parameter for shadows, that enables setting up smooth fading out of shadows at a certain distance from a light source to avoid cutting them out abruptly. This parameter can be found in the Visibility Distance section of the light source parameters.

  • Added a new Temporal Filtering option for all camera effects to reduce bloom flicker in motion on small and very bright elements.
    Please take note that this feature may cause a performance drop in your project after migrating it to 2.7 due to enabled TAA for post effects. You can disable it at any time via the render_camera_effects_temporal_filtering console command.
  • Fixed incorrect planar reflections and dynamic environment probe reflections of the TerrainGlobal object and DecalMesh'es
  • Fixed incorrect culling of terrain and billboards due to missing world position updates
  • Fixed issue with disappearing tiles of a curved TerrainGlobal
  • Fixed issue with broken static meshes after updating via the addMeshSurface() method
  • Fixed issue with rendering a single cloud layer instead of multiple layers (OpenGL)
  • Fixed issue with manual material inheritance via the parent_name attribute
  • Fixed Parallax effect rendering for rectangular Ortho Decals with rectangular textures
  • Fixed incorrect SSAO rendering for aspect ratios other than 16:9
  • Fixed incorrect mipmap generation for rectangular textures with GPU compression
  • Fixed issue with incorrect texture size when rendering to texture with a post-effect enabled
  • Fixed UV scroll for detail textures of the mesh_base material with Parallax state enabled
  • Added Fade With Haze parameter to clouds_base material to configure blending between haze and cloud layer

Syncker: Easy Configuration

Configuring views for your multi-channel rendering system has become simpler and more intuitive. Improved visual editor, offering advanced configuration of dome screens, calibration patterns, hotkeys, various configuration templates (dome, wall, CAVE setups) out-of-the-box will help you build and adjust the required view configuration quickly and efficiently.

Dome Screen Support

Dome imaging systems are widely used for both entertainment and training. Such systems use multiple projectors. Large domes that can be used for civil and military training create a realistic 360° image, seamless and free of distortions.

Syncker view configuration tool now allows you to create and adjust dome setups quickly and efficiently.

Dome projections are usually built of several layers of projectors from bottom to top. You can use any number of projectors grouped in any number of layers and configure image warping and blending parameters using visual editor, with the ability to control the result in real time using the calibration patterns provided.

Easy Configuration

Configuring views for you multi-channel rendering system has become simple and exciting. Forget about typing numbers in countless fields, or writing code, with an advanced visual editor. You can adjust projection configuration for each slave and build a complex setup almost as easy as making a simple mesh in Maya or 3DSMax. A set of templates available out-of-the-box for dome, wall (flat or surround), or CAVE setups and calibration patterns will make your task even easier.

Extended flexibility allows you to use your old setups or create custom ones with complex-shaped surfaces via importing configuration *.mesh files.

All changes are transferred over the network and applied to the Master and slaves automatically.

For more information on setting up view configuration for Syncker please refer to the Configuring Projections for Syncker article.

Integration with Scalable Display

Introducing a new AppEasyBlend plugin that allows you to render the UNIGINE-based application on multi-projector setups that are stored in the calibration files created via the Scalable Display Manager and set up via the EasyBlend SDK. The setup can have a complex shape, such as dome.

The plugin cannot be used with AppWall or AppProjection plugins and is currently available only on Windows with DirectX 11 API. OpenGL support is experimental.

You can toggle the AppEasyBlend plugin via the easyblend 0/1 console command.

It is possible to change calibration *.ol file and roll at run time via AppEasyBlend plugin API.

For more infomation on using the AppEasyBlend plugin please refer to the Setting Up Projections with AppEasyBlend Plugin article.

Runtime Import of FBX

Now you can import your .FBX, .OBJ, .DAE, and .3DS models and add them to your virtual worlds at run time, or you can write your own custom importer, e.g. for batch-import of a large number of FBX files to be used in your UNIGINE project. All of this is possible via the new flexible Import System and FbxImport plugin, both can be customized and extended to fit your needs.

The Import System is utilized by both the Engine and the Editor and uses the plugin for importing content from FBX scenes (also supporting .obj, .dae, and .3ds file formats).

So, all import options, that you can see in the Parameters window, along with all optimizations, are available out-of-the-box via C++ and UnigineScript API.

Custom importing modules for any file format containing 3D scene data can be implemented as plugins. So, you can consider the FbxImport plugin as an example to build your own custom importing modules.

You can also modify the plugin and rebuild it to use customized FBX importer in the Editor.

To use the plugin, just load it via the plugin_load console command or the following command line option on the application start-up: -extern_plugin FbxImport

In general the workflow may be represented as follows:

Source code (C++)
// create an importer for the imported file ("1.fbx" in our case)
Importer *importer = Import::get()->createImporterByFileName("1.fbx"); 

// set up import parameter "scale" to 0.5
importer->setParameterFloat("scale", 0.5f); 

// add a pre-processor to merge static meshes

// initialize importer with all available import flags
importer->init("1.fbx", ~0);

// import our model to the specified directory

// create a node reference using the .node file generated for our model
NodeReferencePtr noderef = NodeReference::create(importer->getOutputFilepath());

You can also load a model with default settings simply like this:

Source code (C++)
// string to store the path to the .node file for your model
String filepath_node;

// import an fbx file to the specified location and get the path to the generated .node file
Unigine::Import::get()->import("../my_data/1.fbx", "../data/1/", filepath_node);

// create a node reference using the .node file generated
NodeReferencePtr noderef = NodeReference::create(filepath_node.get());

The list of key features includes:

  • Ability to import and use .FBX, .OBJ, 3DS, and .DAE files at runtime
  • Ability to create a custom importer and use it in the Editor
  • Simple and clear C++ and UnigineScript API
  • All functionality and optimizations of the Editor's importer

Take note, that runtime import feature is not available for the Entertainment edition of the SDK.

For more information on the Import System and FbxImport Plugin please follow the links below:

Improved Performance Profiler

GPU Profiling

Microprofiler now enables you to view the detailed information on GPU performance to detect all types of bottlenecks. At any moment you can check how much time was taken to render a certain feature, be it shadows, SSAO or water rendering. Detailed information includes number of dips, triangles, shaders and materials used. Please note that GPU profiling is not available in full-screen mode.

General Improvements

Now you can save profiling dumps to files and then compare them to monitor optimization results or detect wrong settings having significant impact on performance. The number of frames has increased up to 1000.

The microprofiler is available for development builds only (won’t work in debug or release ones). To show the microprofiler choose Tools -> Microprofiler from the main menu, the profiler will open in your default web-browser. Please note, that the profiler shows valid information only after the first 1000 frames are rendered (e.g. at the framerate of 60 FPS, such “warmup” time comprises about 16 seconds).

A set of commands for the Microprofiler was added to the console for your convenience, please see the Console Migration guide.

For more information on using the advanced performance profiler please refer to the Microprofiler article.

File System

The FileSystem was improved to support assets and simplify access to assets and runtime files for programmers along with adding more flexibility. For example, a NodeReference can now be created using the following code:

Source code (C++)
NodeReferencePtr node = NodeReference::create("teapot.fbx");

Accessing Assets and Runtime Files via Code

The way of accessing a certain asset is determined by its type:

  • Native assets are accessed simply by their name:
    Source code (C++)
    ImagePtr image = Image::create(“”);
  • All non-native assets have a primary runtime file. So, when you refer to the asset by its name, this primary runtime file will be actually used. For example, if you specify:
    Source code (C++)
    ImagePtr image = Image::create(“image.png”);

    The generated primary runtime file will actually be used.

    You can also directly access any asset source file (not a runtime file). For example, if you need to specify a .png texture, you should write the following:

    Source code (C++)
    ImagePtr image = Image::create(“asset://image.png”);

    In this case, the runtime .dds file will be ignored, .png source file will be used.

  • Each container asset also has a primary runtime, in case of an FBX asset it is a generated .node file. So, you can use the following reference:
    Source code (C++)
    NodeReferencePtr node = NodeReference::create("teapot.fbx");

    The teapot.node generated runtime file will be used in this case.

    You can access each runtime file of a container asset. For example, an FBX file has .node and .mesh runtime files generated for it. You can access the generated .mesh file in the following way:

    Source code (C++)
    MeshPtr mesh = Mesh::create(“teapot.fbx/teapot.mesh”);

You can also access any runtime or asset in your project using GUIDs. In case if a GUID of a file is specified, the exact file having this GUID will be used:

Source code (C++)
UGUID asset_guid; // GUID of the asset named “1.tga”
const char *asset_path = "1.tga";
ImagePtr image = Image::create(asset_guid);// -> 1.tga
ImagePtr image = Image::create(asset_path);// ->

You can manage assets and runtime files via API using the new FileSystemAssets class. A set of new methods were also added to the FileSystem class.

For more information on using the FileSystem please refer to the File System article.

Leap Motion Support

Introducing a new LeapMotion plugin that enables you to track hands and fingers in your UNIGINE-based application. UnigineScript and C++ API for the plugin is available.

Here is a list of basic features:

  • Easy initialization with minimum code required
  • Automatic creation, modification and deletion of entities; manipulation of views and view groups
  • Tracking of hands and fingers
  • C++/UnigineScript API

Check out a new C++ sample illustrating the basic aspects of working with the plugin:

  • source/samples/3rdparty/LeapMotionVisualizer

To learn more about the LeapMotion plugin please follow the links below:

Refactored Data Containers

We refactored our Standard Template Library to make our containers safer and faster.

The main changes are as follows:

  • Move semantics support. You can use C++11 Move Semantics for all data types now to avoid unnecessary data copying. Here is an example:
    Source code (C++)
    Vector<int> vec;
    // move constructor
    Vector<int> vec2(std::move(vec));
    // assignment
    vec2 = std::move(vec);
    // assigning this way is slower due to data copying
    vec2 = vec;
    // append example
  • Added template parameters for Vector and VectorStack classes. You can define Counter type for length and capacity or a custom allocator, or number of stack elements:
    Source code (C++)
    // Counter
    Vector<int, int> vec0; // sizeof(Vector<int, int>) == 16
    Vector<int, size_t> vec1; // sizeof(Vector<int, size_t>) == 24
    // CustomAllocator
    struct CustomAllocator {
       static char * allocate(size_t size) {
          return (char *)malloc(size);
       static void deallocate(char *ptr) {
    Vector<int, int, CustomAllocator> vec2;
    Log::message("%d\n", vec2.first());
    // 256 stack elements
    VectorStack<int, 256>  vec3;
  • Map and Set classes now have init list constructors - simpler and more convenient implementation.
    Source code (C++)
    Map<int, int> m = {
           {1, 2},
           {3, 4},
           {5, 6}
    Set<int> m = {
           {1, 2, 3, 4, 5}
  • The following new classes were added: VectorStack, StringStack, StringPtr, Hash, HashMap, HashSet, and Pair.
  • New classes contain a lot of methods providing compatibility with the standard C++ STL.
  • Extended functionality of the Map, Set, String, Tree and Vector classes.
  • A new case_sensitive parameter was added for search methods of the String class:
    Source code (C++)
    String str = “Case sensitive Substring search”;
    // case-sensitive search
    int i1 = str.find(“substr”, 1); // returns: -1
    // case insensitive search
    int i2 = str.find(“substr”, 0); // returns: 15

For more information please refer to the API Migration Guide.

Other Engine Improvements

  • Optimized spatial tree performance for cases with large number of nodes (over 30k)
  • Fixed detection of collisions and intersections with a curved TerrainGlobal
  • Fixed intersections in WorldSplineGraph
  • Fixed issues with touch actions in the InterfacePlugin
  • Fixed loading of ObjectMeshSkinned.
  • Added the ability to make billboards curved and flat (can be used for road lighting and other such objects generated by the Landscape Tool). This option is available via make curved / make flat actions for ObjectBillboards in the UnigineEditor (works after Landscape generation)
  • Culled by Occlusion Query option is now enabled by default for all heavy objects (ObjectMeshCluster, ObjectMeshClutter, and lights with shadows enabled). Occlusion query vizualization has changed: culled objects are rendered red, the ones that are not culled - are white. Occluders were optimized with a set of render_occluders_* console commands added.
  • Fixed maximum visibility settings issue for Grass and Clutters.
  • Now it is possible to choose the type of VSync to be used: none (0), regular vsync (1), adaptive vsync (2). You can choose any of these options via the video_vsync console command.
  • File-related error and warning messages will display names and paths along with GUIDs making it easier to find and fix problems
  • Added support for *.mp3 audio files
  • Added a new CUDA usage sample: source/samples/3rdparty/CUDATextureTransfer
  • Added bidirectional text support for ObjectText (for Arabic and similar languages)
  • Fixed issue with displaying unicode symbols for GUI and ObjectText
  • Added wallSetUserProjection() and wallIsUserProjection() to the data/core/scripts/system/wall.h system script
  • Image::info() method now can return image information for .psd files
  • The engine now stores log files for last 3 launches
  • Settings files *.render_settings, *.physics_settings, and *.sound_settings were renamed to *.render, *.physics, and *.sound respectively
  • AppProjection: integration with the Interface plugin: undistorted output to a separate window is now available
  • Added the following methods for automatic camera management to CIGI Client plugin API:
  • API:

Build System

  • Double precision binaries now have the _double postfix (e.g., Editor2_double_x64d.dll).
  • Scons now allows you to re-build the Engine and its components using the vs2017 toolset. SCons 3.0 and higher is required.
  • Updated all SCons scripts. Scons now detects the latest Visual Studio version installed as well as the architecture, it can also use the values specified via options.
  • Renamed the directory with external libraries/includes: externs -> extern.
  • Removed unnecessary auxiliary batch scripts scons_x64.bat and scons_x86.bat from extern/bin.
  • Auxiliary batch scripts nmake/msbuild from extern/bin moved to utils/auxiliary.
  • C++/C# API samples are now built via SCons, makefiles are deleted for consistency.
  • Moved the script from the utils to the source folder.
  • Removed the script as its functions are now implemented in

Procedural City Generation Demo

Procedural city generation demo showcases the Landscape Tool capabilities for procedural generation of buildings on a landscape.

A fragment of the landscape with a city and vegetation was generated procedurally on the basis of GIS data provided by OpenStreetMap with no extra manual editing, in less than 20 minutes!

  • 10×10 km area near Adler city (OSM imagery data)
  • Buildings generated on the basis of OSM vector data containing the number of floors
  • Automatic texturing of buildings using 3 template materials
  • Vegetation generated on the basis of OSM landcover data
  • Global water and a single cloud layer

Extended Tank Demo

  • Added dynamic terrain modification
  • Added dynamic grass removal
  • Added dynamic clutter modification (cutting down and destroying trees)
  • Improved environment content

Other Demos

  • Added the following samples into Samples 2 suite:
    • Voxel Probes
    • Screen Space Bevels
    • Cross Section
    • Airport lights
  • Added static Voxel Probe GI to Oil Refinery Demo
  • Oil Platform Demo:
    • Added static Voxel Probe GI
    • Added terrain with details and vegetation

SDK Browser

  • Extended set of project templates: added C++ SDL2 template for creating a UNIGINE-based application with SDL2 integration.
  • Added an option for choosing the Engine build for the project: Development or Release. The Development build includes additional features that can be useful for project's development. However, they can reduce performance. The Microprofile is currently available for the Development builds only. Configuring your project to use Release binaries ensures maximum application performance.
  • Removed the option for choosing the Editor version for the project. Now only Editor 2 is available for new and upgraded projects.
  • Improved project’s assembling.


Build: ()