UNIGINE 2.10: New Terrain, Improved C++/C# API, Editor Plugins, Vehicle System

[fox]

 

Key Changes

• New terrain system: more detailed, faster, non-destructive collaborative edits, binoculars support, runtime modification API.
• Improved C++ and C# API: simplified object management, improved thread safety and stability, better code readability.
• UnigineEditor extensions: public API, plugin system.
• High-Level Car Physics System: wheeled vehicle simulation.
• Improved clouds: more types, better visuals.
• IG updates: adaptive quality management, better synchronization, easier configuration, API improvements.
• New Build tool for assembling standalone project builds.
• Texture Profiler tool for assets optimization.

 

New Terrain System

After almost 2 years in development, we have the new terrain system (ObjectLandscapeTerrain + LandscapeLayerMap classes in the API) production ready! Let's see what is special about it.

Proprietary Core Technology

The new terrain system is based on the Sparse Virtual Texture (MegaTexture) approach with a number of improvements and engine-specific tweaks, such as smart details caching, optimized culling techniques, etc. The terrain system is tightly integrated with Engine's advanced streaming subsystem, making it VRAM-efficient, and is designed from the ground up with multithreading approach in mind enabling it to utilize the advantages of multi-core systems and handle up to petabytes of data efficiently.

The technology is available for both DirectX and OpenGL API and can be used even on Windows 7 (which is still being widely used by enterprise although it is phased out by Microsoft). Although terrain rendering can be configured even for computers with a limited VRAM capacity, we strongly recommend using a GPU with at least 4 GB of memory for optimum performance.

Large Scale

The practical limit for the new terrain up to 10000 x 10000 km. If your use case does not require visualization of the Earth's curvature (ground operations or helicopter simulation), the size of your terrain really doesn't matter (meaning it is virtually unlimited).

Game engines try to imitate large landscapes using patches represented by separate terrain objects, which results in noticeable seams between them and makes scaling very problematic. There are no such problems in UNIGINE.

x2-10 Faster

Rendering of the new terrain is really fast, which makes it suitable for use even in VR applications, where every millisecond counts. Depending on settings, the ObjectLandscapeTerrain is 5-10 times faster than ObjectTerrainGlobal on slow camera movements and 2-3 times faster when rapidly moving camera (intensive data streaming).

Binoculars / Scopes Support

The new terrain ensures perfect scaling and seamless experience regardless of its size, with support for binoculars/scopes (up to x20 / down to 1 degree FOV) guaranteeing smooth zooming in and out and making it suitable even for UAV simulations, where cameras have a narrow FOV.

 

Extreme Level Of Details

The maximum level of detail for albedo, normal, and height components of terrain's virtual texture does not depend on the resolution of the original data sources. It is defined by the texel size of the virtual texture and can be up to 1 mm per pixel, providing unprecedented details. The terrain is optimized for use with centimeter-range resolution data (e.g., 10 cm per pixel), coarser data sources (e.g., 30 m per pixel) may require some procedural refinement for optimum result.

The geometry of the terrain is split down to a number of detail levels using adaptive hardware tessellation, enabling you to have highly-detailed geometry generated on the fly. Even more geometry details can be added via displacement mapping making your landscape look even more natural. Geomorphing support makes transitions between two tessellation levels seamless without popping up or disappearing hills or mountains.

 

Displacement: Disabled

Displacement: Enabled

 

The ObjectLandscapeTerrain offers you an unprecedented number of variations to create a landscape with virtually any degree of diversity. How is that possible? You have 20 multi-purpose masks, which you can use to define areas for stones, sand, mud,etc.with up to 1024 details used to add color, size, displacement variations (e.g., make stones vary in size, color, and roughness across the area defined by the mask). Not enough? Add to that the ability to use albedo color of the terrain as a mask (giving you plus 24 million variations) and additional masking by height to limit the range of heights within the mask, in which a detail is visible (e.g., for snow on mountain peaks).

Dynamic Streaming

Asynchronous streaming of terrain data to the virtual texture with adaptive fetch algorithms taking into account occlusion, camera settings, etc., ensures stable performance, rendering only necessary data at a full level of detail, regardless of the camera's field of view with multiple cameras supported. Flexible streaming settings enable you to configure terrain rendering even for computers with a limited VRAM capacity. Fine-tune rendering and streaming settings to match your memory amount, required number of cameras, and quality balance to achieve the desired performance and fit your project's requirements.

By the way, we have also improved streaming of all textures, reducing lags on loading small portions of data.

Fast Intersection Testing

Intersection testing is fast (several times faster than for ObjectTerrainGlobal) and accurate, with a number of optimizations, enabling you to avoid excessive checks by ignoring certain layers used just to add minor details and having a very slight variation from the heightmap of the basic layer. You can also choose to process your requests in a forced mode when an immediate response is required, or asynchronously to balance out load and maintain stable performance.

Non-Destructive Layer-Based Pipeline

Terrain data (heights, albedo, and masks) is stored by layers, represented as separate objects - Landscape Layer Maps, which can have different density, orientation, and practically unlimited size. They can be arranged in the scene and blended with each other in various combinations offered by a wide range of options (additive, multiplicative, etc.). So, you can mix layers with different density to create high-resolution insets at any location, or perform non-destructive modification of the terrain surface by adding a new “modifying” layer atop of the base one (e.g., to create wheel traces). You can add as many layers as you need.

 

Initial Landscape

Landscape With Flattening Inset

 

It's easy to use Landscape Layer Maps for runtime modification via API - simply spawn a new layer to modify terrain appearance at any location. In case the modification is no longer needed - just disable or remove the layer restoring the previous state.

 

One Layer

Two Layers Blended

 

Team Collaborative Editing

The fact that each layer's data is stored independently in a separate file, makes the terrain system VCS-friendly and suitable for collaborative editing. A team of 3D artists can design separate layers or sets of layers simultaneously (e.g., one of the artists generating terrain data procedurally using third-party software, another one creating flat areas on the terrain while their teammate sculpts a mountain). Thus together, they can create a large landscape piece by piece, simultaneously iterating on manual edits and procedurally generated data, without any conflicts.

Check out this quick video guide below to learn how to create and edit a Landscape Terrain.

Support For Holes

Arbitrary-shaped holes can be cut out from the terrain surface using the decal-based technology. You can use holes to replace terrain geometry with arbitrary meshes (e.g., to create caves or tunnels), ensuring accurate and seamless blending along with per-pixel details. These options are especially useful for digging holes and trenches in excavator simulations.

Multi-Purpose Masks

There are 20 multi-purpose masks, which can be used to add details to the terrain surface (such as stones, sand, mud, etc.), giving a huge number of variations in combination with up to 1024 details and color-based masks (see above). Another use case is to define areas for grass, trees, and other objects, establishing a unified workflow to be used across all related subsystems of the Engine, thus reducing the number of required masks and optimizing memory consumption, as the same mask can be used for multiple purposes.

On top of that, these masks can be used to create land cover classification maps, define various physics parameters, like surface friction to simulate various road surface conditions, or even for sensor data classification such as temperature, magnetic fields, as well as data of other non-visual channels.

Runtime Modification API

All the things described above are available via API. You'd like your vehicles to leave tracks while moving, or create shell craters after series of explosions, want to have an excavator digging trenches or a bulldozer leveling the ground - no problem! Real-time terrain CPU- or GPU-based modification via API is as simple as 1, 2, 3:

• Set the desired area, and the Engine shall copy a part of terrain data for this area to a buffer.
• Modify the buffer as you want (height, color, masks, or all of them at once).
• Upon completion the Engine shall paste the buffer back to the terrain replacing old data.

Implementation of custom brushes for your own terrain editor also won't take much time, just modify existing Brush materials, or create your own, even with your own shader code if you wish. The new Unigine Language Object Notation (ULON) enables you to do that. The stack of undo/redo operations is supported.

Another simple way to modify terrain's appearance is to spawn custom layers having their own height, albedo, and masks data and adding them above existing ones. Each layer is a separate node, so you can control each modification separately. Undo is simple for this approach too - disable or remove the modifying layer restoring the previous state.

Rover tracks seen above demonstrate real-time modification of terrain surface. For more details on configuring and using the new terrain system please refer to the Landscape Terrain article.

You can check out new Landscape samples from the Art Samples suite (SDK Browser -> Samples -> Demos -> Art Samples), as well as a C++ Samples illustrating runtime API modification and getting terrain data for an arbitrary point: (SDK Browser -> Samples -> Demos -> C++ Samples -> Landscape).

Too Many Terrains, Help Me Choose!

Just to avoid confusion, there are 2 terrain systems available with 2.10:

• ObjectTerrainGlobal - useful for large-scale multi-inset terrains, supports curved mode, natively works with geo-coordinates, can be generated with Landscape Tool from raw GIS data, has a practical limit of up to 10000x10000 km.
• ObjectLandscapeTerrain + LandscapeLayerMap (the new one) - useful for very detailed terrains, doesn't support geo-coordinates for now, can be created directly by UnigineEditor from a tileset made with 3rd-party software, supports collaborative editing, supports runtime modification, faster intersection testing, binoculars-friendly, has a practical limit of up to 10000x10000 km.

Legacy ObjectTerrain (which was considered as deprecated since 2.7) is finally removed with this release. The same is true for the WorldOccluderTerrain. After migration each of them shall be converted to a NodeDummy.

In further releases the new terrain will also get support for geo-coordinates and ability to be generated from GIS data, together with Landscape Tool integration (which is to be heavily upgraded as well). As for the future of ObjectTerrainGlobal, it will still be there for some time (it will be phased out only when currently developing ObjectPlanet will be completely production-ready).

To sum up, we would recommend to keep using ObjectTerrainGlobal for large-scale flight simulation purposes (especially fixed wing) on georeferenced scenarios, while use ObjectLandscapeTerrain for ground operations (especially with scopes/binoculars required or where runtime modification is a must) or projects where extreme level of details is required (including helicopter simulation).

Improved Volumetric Clouds, More Types

UNIGINE's volumetric clouds system is extendable and enables you to create various types of clouds. But that requires adjustment of multiple settings as well as creation of custom textures. To make artist's life easier, we've added a number of new ready-to-use presets for the following cloud types: altocumulus, cumulus, stratocumulus, stratus, nimbostratus.

We have added an option to use a 3D detail distortion texture for clouds rendering instead of a previously used 2D texture, eliminating vertical extrusion of clouds that could occur at certain detail size settings. The new mode can be set via the Render -> Clouds section of the Settings window or via render_clouds_distortion_texture console command. By default, the old mode is used.

 

2D Detail Distortion Texture

3D Detail Distortion Texture

 

To make clouds adjustment even more flexible we've added the ability to control dynamics of moving clouds, i.e.,how much clouds change their form as they move. This option is available via the Wind Deformation slider of the clouds_base material.

 

Particle Systems Update

Refactored Particle Systems have got more deterministic behavior significantly improving image consistency for multi-channel rendering use cases. So, when a particle is spawned on one IG/PC, it can travel to another screen (a view from another IG/PC) seamlessly, which is very important for multi-channel image generators.

More Rendering Improvements

• Shaders cache should now be generated for float- and double-precision builds separately, as each of them uses its own shader cache (i.e., cache generated for float precision is not suitable for a double-precision build). In case your application is released with both builds float and double, you'll have to generate shaders cache twice.
• Fixed shader compilation for Windows 7.
• Improved visualizer with reduced wireframe flickering, the new option is enabled by default and can be controlled via the visualizer_fix_flicker console command.
• A number of changes were introduced to the Unified UNIGINE shader language (UUSL), for more information please refer to the API Migration Guide.
• There were also a number of changes introduced to the material file format, for more information please refer to the Content Migration Guide.
• Fixed noise artefacts when rendering Mesh Decals on NVIDIA and Intel GPUs.
• Use Sun Color option of the Voxel Probe now takes into account Ambient and Reflection settings of the Environment.
• Removed artefacts that sometimes appeared when enabling SSRTGI along with Bent Normals.
• Removed shadows flickering artefacts during camera movement for impostors having the grass_impostor_base material with enabled Jitter Transparency option assigned. Fading was also improved and became smoother.
• Fixed shadow cascade artefacts for grass.
• Fixed shadow rendering artefacts and console errors appearing for objects with shadow masks enabled in case of using a world light source with a single shadow cascade (OpenGL).
• Fixed rendering of lens flares for light sources inside a node reference.
• Fixed Screen-Space Subsurface Scattering issues on OpenGL+Nvidia.

Improved C++ and C# API

More or less often our users have complained that our API (as well as memory management) is a bit complicated and requires some effort to use it safely. In this release, we have significantly refactored our API to make it simpler and safer, so you could concentrate on application logic.

UNIGINE's smart pointers were significantly refactored in order to avoid dangling pointers, unexpected object deletions (e.g., when getting out of scope) as well as double deletions (in case an object has more than one owner) leading to crashes. Add to that clear lifetime management, convenient downcasting with clear semantics (no ambiguity, more C++ style) and automatic upcasting, as well as reduced number of wrapper-interfaces resulting in less memory consumption and improved thread safety due to atomic reference counters.

As a small example take a look at how the following code has changed from 2.8 to 2.10, thread safety and stability improvements are not obvious here, but it surely looks simpler and clearer.

2.8 and Earlier Versions

2.10

Source code (C++) // creating a player and setting its name PlayerActorPtr actor = PlayerActor::create(); actor->setName("player"); // adding the node to the Editor actor->release(); Editor::get()->addNode(actor->getNode()); // setting actor as the current player Game::get()->setPlayer(actor->getPlayer()); // trying to find our node by its name NodePtr node = Editor::get()->getNodeByName("player"); // deleting a node with all its hierarchy Editor::get()->removeNode(node);

Source code (C++) // creating a player and setting its name PlayerActorPtr actor = PlayerActor::create(); actor->setName("player"); // setting actor as the current player Game::setPlayer(actor); // trying to find our node by its name NodePtr node = World::getNodeByName("player"); // deleting a node with all its hierarchy node.deleteLater();

The list of other changes includes the following:

• Engine's singletons with improved thread safety and simplified access to their functionality.
• A set of new classes and functions to improve synchronization in multithreaded applications.
• Improved hierarchy management for nodes and widgets ensuring that all children are automatically deleted along with the root, as expected.
• Stronger typing with enums and bools replacing int values.
• Node management functionality (i.e., finding, adding, removing nodes, etc.).

The code migration will require some manual effort, but it is pretty much simple find-and-replace operations or throwing away redundant code. Unfortunately, this is the price we have to pay once for stability (less crashes and memory leaks), convenience, thread safety, code readability, and overall development productivity in the future. We've put all our efforts to concentrate all required major API modifications in this release to avoid further breaking API changes until UNIGINE 3.

For more detailed information on API changes please refer to the API Migration Guide.

C# API

C++ API changes made it possible to improve C# API as well. So here is the list of C#-specific improvements in addition to the ones listed:

• Improved C# memory management with Dispose pattern implemented for each object performing memory cleanup for Engine's (native) resources.
• Improved C# garbage collection with tweakable Collector behavior.
• C# Component System with safety improvements and statistics on the current System's state available at run time.
• Extended C# API with all plugins now available along with a lot of methods, that were earlier available for C++ only.

Added a new video tutorial on C# Component System:

Unigine Language Object Notation

Unigine Language Object Notation (ULON) became the basis for a universal format used in UNIGINE to describe complex structures similar to classes in Object-Oriented Programming. It enables you to have dynamically-built hierarchy depending on logical conditions that you define, and even embed source code (e.g., shaders or scripts).

The new format is currently used to describe Landscape Terrain materials and brushes. The base Brush material can be used to implement your own custom terrain brushes.

In the future, we plan to convert all UNIGINE built-in materials to this format.

Please refer to the Unigine Language Object Notation article for more information.

Filesystem & Resource Management

• Resource update on the fly is now available at run time without the Editor running. When you change any resource and want the Engine to use the updated version, you can call the FileSystem::changeVirtualFile() method to notify the Engine that a file has been modified and needs to be updated. This enables you to write your own custom file watcher to ensure automatic update of necessary resources.
• Fixed issues with UGUID-related functions in UnigineScript.
• Ignore filters (i.e., list of folders that should be ignored) for the project's root data folder are now available. At project creation, the root_mount.umount file is created in the data folder. For more information please refer to the File System article.
• Improved streaming of all textures, reducing lags on loading small portions of data.
• Texture cache can now be generated and saved to a location outside the data folder, the location is defined by the -cache_path startup command-line option.
• Fixed an issue with generating cache for certain types of textures.
• Boosted initialization speed of the filesystem, materials, textures, and console.

High-Level Vehicle Physics System (Experimental)

Creating realistic wheeled vehicle simulations with UNIGINE has become much simpler now. Introducing a new high-level system, implemented as a set of C++ components, minimizing efforts required to create virtually any wheeled vehicle, be it a 4WD SUV, an exploration rover, or a sophisticated multi-axle transporter.

The following features are available:

• Setting engine's power and resistance curves, as well as idle speed (RPM).
• Gearbox simulation (manual and automatic) enabling you to adjust throttle and speed values for shifting gears along with transition time, as well as to set the number of gears and configure gear ratios.
• Mathematical wheel model for more realistic steering, enabling simulation of forces affecting the rotating wheel, along with an ability to adjust suspension travel distance, spring, and damping values.
• Easy setup of steering and driving axes along with capability to turn the differential lock on and off.
• Switching between different views (driver's view, external camera, etc.).
• Simulation of various surface conditions (such as dry, wet, snow-covered, or icy road, mud, and so on).
• A set of debug windows displaying information on all vehicle parameters in real time.

Physics simulation with a lot of parameters taken into account ensures lifelike vehicle dynamics. So, when driving your virtual vehicles please keep in mind, that engine will stall if you drop the clutch too fast!

The set of C++ Components is available in the Vehicle Sample from the C++ Samples package included in the SDK (SDK Browser -> Samples -> Demos -> C++ Samples -> Vehicle Sample).

For more information on creating your own wheeled vehicle using the new high-level system please refer to this article.

GUI Improvements

• Added color multipliers for various elements (border, background, selection, buttons, etc.) of the following widgets: GroupBox, ScrollBox, Button, CheckBox, ComboBox, MenuBar, ListBox, Scroll, EditLine, EditText, TabBox, TreeBox, Slider, tSpinBox, Window.
• Fixed stencil buffer for the ObjectGUI, restricting all UI elements to the interface window's and object's area.
• Fixed clipboard-related operation in WPF applications.

Teslasuit Support

We continue to add more integrations with leading hardware solutions, enabling new levels of immersive experience in the virtual environment. Now it is time for haptics.

UNIGINE now supports Teslasuit - a full-body haptic suit with motion capture and climate control letting the user feel the sensations in virtual reality, transmitting body motion and providing sensations of heat and cold. The new TeslaSuit plugin provides integration with the suit and allows controlling the Teslasuit service communicating the following data:

• User motions
• Haptic feedback
• Biometry

A user can feel the pressure, heat, cold with this suit, while the application can read motion and pulse rate data from the user. This enables a lot of applications in the enterprise personnel training.

Plugin's functionality is available via C++ and C# API. For more information see the TeslaSuit Plugin article.

Collision Detection Optimization (Important)

In order to optimize performance and avoid unnecessary calculations the Collision flag shall now be unset by default for all surfaces of ObjectMesh* objects.

So, you'll have to set the Collision flag manually for all the surfaces that require it. In case of creating objects via code please don't forget to set the flag via the setCollision() method where necessary. We also strongly recommend you to use physical shapes to detect collisions of dynamic objects, as they work much faster!

GPU Debug Information

Added GPU debug information for Debug and Development builds of the Engine, which can be helpful when using third-party graphic debuggers (such as RenderDoc or NVIDIA Nsight). The new feature is integrated with the Microprofile tool, enabling you to combine OpenGL or DirectX commands into GPU Debug groups and create them automatically when defining a profiling scope. All graphic resources loaded from external files, such as textures, shaders, static or skinned meshes, as well as Engine's internal resources, now have their own debug names to simplify identification.

Other Engine Improvements

• Added support for EXR files (currently Windows only). Such images can have an arbitrary number of channels with true 32-bit float per pixel per channel to store additional data. There are a lot of HDR textures available in EXR format, and manual conversion is no longer required for them.
• Added support for RGBA32F Tiff-images.
• Fixed issues with performance drop on enabling World Layers placed in node hierarchies.
• Fixed collision detection for MeshClutter elements.
• Fixed issues with changing the size of the original billboard when applying another material to its clone.
• Fixed a crash on calling the size() function for arrays of structures in properties with a non-zero array size.
• Fixed an issue with incorrect grabbing of impostors with a pivot offset.
• Scaling of environment probes is now available with projected reflections applied correctly.
• Improved visualizer with reduced flickering of thin lines.
• Fixed image decompression errors appearing in the Console when creating a FieldHeight within the volume of the WaterGlobal object.
• World::getNodeByName() method now filters out isolated node hierarchies and cache nodes, so it does not return nodes having a possessor (NodeReference/Clutter/Cluster) among its predecessors or nodes from cache.
• Fixed a crash on attaching/detaching a Grass object to the parent Geodetic Pivot.
• Improved error reporting for cases of incorrect usage of manual properties.
• Node Layers are no longer removed from the world if they contain broken Water Mesh objects (with a missing mesh), they are now loaded normally keeping all their hierarchy, with only the broken Water Meshes removed.
• Fixed tileset file issues leading to incorrect editing and corruption of height maps of the TerrainGlobal object with insets, in areas of missing high-detail LOD data.
• Improved alignment of MeshClutter objects with impostors generated for them using the Impostors Creator which sometimes led to missing impostors for some clutter elements.
• Fixed a crash related to memory allocation for a large texture used by a dynamic Environment Probe.
• Fixed an issue with adding new unnamed surfaces to an object (or meshes to a mesh cluster) resulting in unsetting the Enabled flag for them.
• Fixed a crash on replacing a mesh for an ObjectMeshSkinned, having a child WorldTransformBone node assigned to a certain bone, with a mesh having a lesser number of bones.
• Fixed behavior of the Node::setDirection() method for a case when the "upU vector is collinear with the direction vector, which led to a crash on shader cache generation.
• Fixed integer overflow in MeshDynamic::addTriangleFan().
• Fixed incorrect mesh-related operations in the Water Mesh objects.
• Fixed plugins execution sequence eliminating double-initialization issues that occurred in some cases.
• AppEasyBlend plugin now supports Scalable SDK 2.96.
• Fixed generation of XML-warnings. In case of having many of them in the Console, please be aware that most of them may signalize about errors that occurred during previous content migrations. Such errors are to be fixed manually, should they appear.
• The Microprofile is now disabled by default in the C++ Component System.
• The shutdown() method of C++ components will only be called after calling all initialization methods.
• The Engine will always load the proper openal.dll library from the bin directory even if it is installed in the system (system32).
• Fixed velocity correction factor for Doppler shift calculation.
• All open sockets are now closed automatically before deletion eliminating related Engine crashes on shutdown.

UnigineEditor

In previous releases we put a lot of effort to make UnigineEditor a full-scale standalone application, enrich its functionality and improve its stability and performance. This time we've focused on giving you an ability to extend it.

Plugins and Public API (Experimental)

This feature is an experimental one and is not recommended for production use, as the API may be changed drastically in future releases. However, your feedback is highly valuable to drive further development of the feature.

Introducing a long-awaited UnigineEditor Plugin System and a public API, enabling users to create their own plugins to customize the Editor for their project-specific needs, e.g., add new menus, windows, toolbar commands, sub-modes, define how properties are displayed, etc.

Plugins are collections of code and data that developers can easily enable or disable within the UnigineEditor on a per-project basis. Each plugin is compiled into a dynamic library that is shipped separately, it is detected and loaded at run time by the UnigineEditor. Plugins can have various versions and can rely on other plugins so the Plugin System implements a mechanism of dependency resolution.

You can see the list of all currently loaded plugins in the UnigineEditor via Help -> Plugins.

If an error has occurred when loading a plugin, a detailed message shall be displayed in the description window.

UnigineEditor is an application written entirely in C++ relying a lot on the Qt5 framework infrastructure. So, in order to extend its functionality not only C++ programming skills are required, but you should also be familiar with the Qt5 framework, and CMake build system.

For more information on Extending Editor functionality please refer to the following articles:

• Extending Editor Functionality.
• Creating Your First Editor Plugin.
• Editor API Reference.

Project Build

We've added a new tool to take care of the final build assembly for your project. So, you can now create a final build for your project right in the UnigineEditor via File -> Create Build.

Please note, that similar functionality (Assemble Project) was removed from the SDK Browser.

There is also a new project launcher for your build (you can modify the UI as you need):

The new build system has the following advantages:

• Project is built right in the Editor with fine-tuning all settings in one place.
• Building process for projects based on the C# Component System is simplified to the maximum.
• GUI-based launcher is now available with the banner image and default settings. It can be visually customized to fit your needs.
• Setting a default world to be loaded on startup is possible.
• Files from mount points and data folder are copied to the output folder by default. The list of other necessary data to be copied can be specified manually.

For more information please refer to the Building a Project article.

Texture Profiler

Textures are the most frequently used assets and can be the most memory-consuming ones. Proper optimization here ensures faster streaming, reduces video memory consumption and spikes generated on loading.

Introducing a new Texture Profiler giving you detailed information on all textures in your project for clear understanding of which of them can be optimized or deleted. You can sort textures by size or resolution to quickly find the ones that significantly affect memory consumption and take a lot of time to load. You can also focus on examining only the textures currently displayed in the viewport!

In case there are a lot of textures used in your project, we strongly recommend you to use this tool to make sure that all of them are configured and used properly. This tool saves artists a lot of time and effort spent on optimization, for more information please refer to the Texture Profiler article.

Asset Dependency Tracking

Sometimes it is very hard to find where exactly a certain asset is used. Imagine that in the Asset Browser, you find a texture having a strange location. You'd like to know which material uses it in order to move the texture to a more appropriate place in the project. Or, perhaps, this texture is not used at all, so you can delete it and save some disk space. So, we've got a new tool for you so you could examine any asset, be it a material, texture, FBX, mesh, property or anything else.

You can check whether an asset is used as a part of a more complex asset, or consists of a set of assets itself by choosing Show Assets Using This One or Show Assets Used in the shortcut menu in the Asset Browser.

Other Editor Improvements

• UnigineEditor no longer monitors modification of resources outside the data folder referred to via absolute paths automatically, so it is recommended to use mount points.
• Improved UI generation for the Parameters window resulting in a 4x boost and minimizing lags on displaying parameters when selecting nodes with a lot of complex-structured properties assigned.
• Changed the way of curving nodes relative to the GeodeticPivot: clicking Make Curved creates a curved clone of the initial node, while the latter (using a non-curved mesh) is simply disabled, so you can use it when you need to return to previous (uncurved) state, the Make Flat button is removed as unnecessary.
• Improved alignment of generated Vector and Point objects with the curved surface of the Global Terrain. The only cause of inaccuracies in alignment now is the use of low-resolution height maps.
• Source node parameters (min/max fade and visibility distances) are now correctly transferred to generated Cluster objects ensuring proper LOD management.
• Fixed removal of associated property file, when removing a C# component in the Asset Browser.
• Fixed undo operation for changing a property assigned to a node.
• Fixed a crash on assigning a property created via the Create menu of the Select Asset window.
• Fixed assignment of a property asset to a property field by dragging it from the Asset Browser.
• Fixed displaying additional command line arguments for Play presets used for launching projects based on C# components.
• Blending mode changes for the Field Height are now saved correctly.
• Fixed an issue when changing Generator settings for a single WorldСluster object affects other WorldСluster objects in the scene.
• Fixed issues with Edit Size manipulators becoming unavailable when the size along one of the axes is close to 0. The manipulator now also behaves properly, when the camera is inside the volume of a Voxel Probe.
• Fixed issues with incorrect displaying of control boxes of the Scale-manipulator.
• The sizes of tool windows (Settings, World Hierarchy, Materials Hierarchy, etc.) are now reset correctly after resizing and reopening them again.
• Fixed issues with unresponsive controls in additional Scene Viewports, when the first one is closed or hidden.
• Renamed ambiguous Save buttons for various types of presets in the Settings window to explicitly indicate the corresponding type.

  

• Fixed an issue with information on the second UV-channel being lost after importing a model with the Merge Surfaces by Materials option enabled.
• Improved handling of texture assets with 16K+ resolution, they are now correctly imported "as is" without conversion to DDS (DDS does not support 16K+ resolution).
• Fixed inversion of the G-channel for RGB8, RGBA8, RG16, RGB16, and RGBA16 images on reimporting.
• MeshStatic objects added as children to a Geodetic Pivot after reloading a world are positioned correctly.
• Fixed an issue with hot-reloading of modifications made to *.prop files outside the Editor.
• Fixed a crash on baking Impostors for a Mesh Clutter.
• Fixed automatic opening of landscape files by double-clicking in the Asset Browser.
• Show asset in the Asset Browser command will automatically set focus to the Asset Browser.
• Fixed center pivot point calculation for hierarchies containing NodeDummy nodes.
• Heightmap normalization is now saved to the landscape asset.
• Video Grabber now takes into account node.enabled values stored in *.track files.
• Fixed behavior of buttons in the Tracker tool.
• Removed re-generation of shadows for static lights with disabled shadows stored inside node references.
• Fixed a crash on attempt to place one of the multiple node references created inside a mounting point from the same static mesh.
• Fixed a crash on creating a new world with the Edit Size manipulator enabled for an Environment Probe.
• Fixed an issue with adding a new node parameter in the Tracker tool, when the world contains a NodeReference.

IG Updates

The IG (Image Generator) Application template, our plug-n-play component for professional distributed simulation systems has got a pack of updates.

Adaptive Quality Management

Simulations usually operate with large numbers of various entities which are often represented by complex hierarchies.To keep performance high a proper optimization is required, as transforming and rendering the whole hierarchy of an entity that is hardly visible wastes a lot of computational resources. A new Simplifier component can help optimize rendering of your entities. This component, when assigned to an entity, enables you to define which parts of its model can be neglected starting at certain distance levels (e.g., hide flaps, ailerons, and rudders at 1km, engines at 5 km, etc.) and which substitutes can be used to represent an entity at a large distance (e.g., a flashing strobe light, when the plane is just a point on the screen).

In addition to model simplification introducing an experimental Adaptive Quality system providing automatic real-time adjustment of levels of detail depending on current performance (only degradation mode is currently available). This system works together with entity model simplification mechanism described above and automatically drops off details as performance decreases.

Unified IG Configuration

The majority of IG configuration settings were stored in the ig_config.xml file while some of them were scattered in property-files. We've gathered all of them in one place (the ig_config.xml file) and added a new IGConfig class to let you manage IG configuration via API.

Integrated Synchronization

The principle of IG interaction with Syncker has changed. The IG now has its own synchronization system with the Syncker plugin initialized automatically - no IP-addresses or port numbers required! Simply use the following command-line options:

• for the Master (ig_count - total number of IG hosts, including the Master):
  -ig_master 1 -ig_count 2
• for a Slave:
  -ig_master 0

By default IG uses the UDP port 25000, but you can change it when necessary (e.g., if this port is blocked or used by another system) by specifying the ig_port key. You can also use the ig_address key for a Slave to set a specific Master's ip address, if necessary. When Syncker is not needed simply skip the -ig_master key, or specify -ig_master -1.

The complete set of updates includes the following:

• User messages can now be sent using the IGManager class:
  • void sendUserMessage(const Unigine::BlobPtr& send_message)
  • void setOnUserMessageReceivedCallback(Unigine::CallbackBase * callback);
• You can now obtain the list of all existing entities via the getEntities(Unigine::Vector<IEntity *> & entities_ret) method.
• Added new on_connect and on_disconnect callbacks for the DISConnector (see the setConnectionThreadCallbacks() method). These callbacks are fired on establishing connection for access and modification (KDIS::NETWORK::Connection).
• Broadcasting address and port used for sending UDP messages can be changed via API without restarting Syncker, simply set new parameters using the Master::setBroadcast(const char *address, int port) method.
• Fixed a crash during application shutdown when the Syncker plugin is loaded, associated with remaining attached widgets.
• Fixed Syncker crashes on reloading and closing a world.
• Improved logging with more informative messages.
• Precipitation intensity in CIGI is now controlled via the Coverage parameter of the WeatherControl packet.
• Weather regions can now be referred to via ID instead of indices.
• Fixed a number of issues related to wind direction.

Samples & Demos

The Oil Refinery demo now also uses a new Landscape Terrain with a high-resolution inset in the refinery area which also demonstrates flattening of terrain surface. Landscape Terrain masks are used to define areas for grass and even asphalt which is now implemented as a high-quality terrain detail.

The Oil Platform and Soldier demos were also ported to the new Landscape Terrain.

The Samples demo package was renamed to Art Samples with the following ones added and updated:

• A set of Landscape samples showcasing features of the new Landscape Terrain:
  • Landscape with high-resolution terrain insets using landscape layer maps, blending modes.
  • Using masks of Landscape Terrain details: Blending by Heightmap using various Contrast values for transition between details, Additional Mask, and Triplanar Mapping
  • Creating a tunnel cutting through the landscape using decal-based holes.
• Object Terrain Global was replaced with the new Landscape Terrain in the following samples: Shoreline, Clutter Terrain, Grass Terrain, Impostors, and Forest.

C++ Samples

To showcase the use of engine features for various use cases via the C++ API we added a new demo to the SDK (SDK Browser -> Samples -> Demos -> C++ Samples). We plan to update this demo package every release with new simple examples for you. Meanwhile, the 2.10 brings you the following ones:

• Vehicle Sample showcasing a new High-Level Car Physics System.
• A set of Landscape Terrain samples demonstrating run-time modification via API as well as getting terrain information (height, albedo, masks) for a certain point.

SDK Browser

SDK Browser will now automatically download the latest available SDK version for all new users on their first login. Please note, that My Projects tab is available only if at least one SDK is installed. So, if the tab is inactive and you can't create a project, switch to SDKs tab and make sure that the list of installed SDKs is not empty.

Documentation

Being always focused on our customers' needs we want our documentation to be useful. So, along with a set of quality of life enhancements we added a new feedback channel - now you can rate articles, send us error reports and your requests regarding incorrect or missing information from any page directly.

• Updated IG documentation.
• Added a new Extending Editor Functionality section.
• Added a new Editor API Reference section. Related in-place documentation is also available in IDE.
• Added a set of articles on new Landscape Terrain.
• Added a new article on Unigine Language Object Notation.
• The complete list of API changes is available in the API Migration Guide.
• The complete list of Console command changes is available in the Console Migration Guide.

Progress On Particle System Improvements (Preview, not in 2.10)

Shading (WIP)

We're currently working on shading improvements for particles: more realistic translucency effect with the ability to set translucency radius to imitate different smoke density, translucent shadows cast by particles, as well as normal mapping providing additional volume and adding details. Together they make particles lighting more vivid and consistent with the scene, enabling you to create convincing volumetric effects.

Simulation (WIP)

Setting particle system parameter values that remain constant during the particle's lifetime is no fun. For many of these parameters you'll be able to use the Curve Editor to define how they should change with time. This will give you a lot of flexibility in animating each particle's behavior during its lifetime.

There are a number of other cool features almost ready to be released in the beginning of 2020, stay tuned!

Notice: UNIGINE 2.10 SDK requires SDK Browser version 1.9.20 or later.

[fox]

Known Issues

Engine (2.10.0.1 00ec2156f2):

• FieldAnimation doesn't work with  mesh_base + Vegetation state enabled;
• Switching to the fullscreen mode from windowed in runtime (on fly) is not possible;
• ObjectLandscapeTerrain: Insets artifacts on Maxwell GPUs under Linux OS;
• Migration is not changing the version of *.umount files (do not affect the mounts work);
• ImageFileDDS::load(): can't skip mipmaps in "core/textures/common/noise.dds" file warning message if noise.dds texture is used in some material;
• AMD + OpenGL performance issues on streaming (including regular meshes / textures and more complex Landscape cases).

Editor (2.10.0.1 00ec2156f2):

• Landscape Tool: Huidini integration is not available. Patched version is available on demand, please write to engine-support@unigine.com;
• Incorrect materials import after hitting Reload Materials button: random material will be assigned to all the surfaces;
• Errors in log after Reload Materials if Landscape Brush Editor is being opened;
• Errors in log after Reload Materials if Landscape have details assigned (TerrainDetail::setMaterial(): can't find guid "...").

[zhu.jun]

Can the scene in the picture provide demo?

[morbid]

10 hours ago, zhu.jun said:

Can the scene in the picture provide demo?

Hi, no this is promo image. Actual demo shows vehicle physics only.

Mars demo will be released in 2020.

[zhu.jun]

4 hours ago, morbid said:

嗨，这不是促销图片。实际演示仅显示车辆物理。

火星演示将在2020年发布。

ok Happy holidays

[christian.kubler]

Hi,

Oil Refinery demo missing in SDK Browser?

Best Regards,

Christian

 

Edited January 8, 2020 by christian.kubler

[morbid]

Hi Christian,

This demo is not upgraded yet, we'll release it later with 2.10 hotfix (January).

Thanks.

[fox]

2.10.0.1 Hotfix is now available!

 

[fox]

2.10.0.2 Hotfix is now available!

 

[davide445]

On 12/28/2019 at 2:08 AM, morbid said:

Mars demo will be released in 2020.

Any ETA for this? 

[binstream]

18 hours ago, davide445 said:

Any ETA for this? 

Originally we were targeting July (to match SIGGRAPH time), but since the events are getting cancelled, the plan is changing as well.

Technically we are waiting for the texture compression to be implemented to reduce the build size, plus some UI improvements.