This page has been translated automatically.
Video Tutorials
Interface
Essentials
Advanced
How To
Professional (SIM)
UnigineEditor
Interface Overview
Assets Workflow
Version Control
Settings and Preferences
Working With Projects
Adjusting Node Parameters
Setting Up Materials
Setting Up Properties
Lighting
Sandworm
Using Editor Tools for Specific Tasks
Extending Editor Functionality
Built-in Node Types
Nodes
Objects
Effects
Decals
Light Sources
Geodetics
World Nodes
Sound Objects
Pathfinding Objects
Players
Programming
Fundamentals
Setting Up Development Environment
Usage Examples
C++
C#
UnigineScript
UUSL (Unified UNIGINE Shader Language)
Plugins
File Formats
Materials and Shaders
Rebuilding the Engine Tools
GUI
Double Precision Coordinates
API
Containers
Common Functionality
Controls-Related Classes
Engine-Related Classes
Filesystem Functionality
GUI-Related Classes
Math Functionality
Node-Related Classes
Objects-Related Classes
Networking Functionality
Pathfinding-Related Classes
Physics-Related Classes
Plugins-Related Classes
IG Plugin
CIGIConnector Plugin
Rendering-Related Classes
Content Creation
Content Optimization
Materials
Material Nodes Library
Miscellaneous
Input
Math
Matrix
Textures
Art Samples
Tutorials
Warning! This version of documentation is OUTDATED, as it describes an older SDK version! Please switch to the documentation for the latest SDK version.
Warning! This version of documentation describes an old SDK version which is no longer supported! Please upgrade to the latest SDK version.

Content Migration

You can upgrade content of your project to UNIGINE 2.17 in the automatic or manual mode.

Warning
You cannot correctly migrate the project that contains assets with a version higher than the project version.

If your project contains at least one file with a higher version, upgrade to this version will be skipped, as the migration script would consider that the project is already upgraded to that version. Let's review an example case:

  • Your project is v. 2.14.1
  • It contains a v. 2.15 node.
  • You plan to upgrade the project to 2.16.

When you start the upgrade process, the following will happen:

  • Upgrading to v. 2.15 is skipped as you have one v. 2.15 node, and the script assumes the whole project is already using this version.
  • Upgrading to v. 2.15.1 is successful.
  • Upgrading to v. 2.16 is successful.

Thus, for a correct migration, follow this recommendation: ensure that the project does not contain assets with a version higher than the project version. This can be done by checking the number of the target version througout all project files. In the example above, you should check if any of your project files contains the text version="2.15" before starting the migration process.

Another way is to keep the Make Backup option enabled. In this case the project is automatically copied for reference, and if automatic migration goes wrong (i.e. it is stopped halfway and you see a message like "Skip migration to version "2.15" File: "D:/ProjectFolder/data/.../example_file.node in the migration log) you can fix the problem files manually.

Make Backup

Notice
You can delete the backup folder manually after you've migrated successfully.

Automatic Upgrade#

Automatic upgrade of the project's content can be performed via UNIGINE SDK Browser.

Notice
By default, the automatic mode is used to upgrade only binary executable files and content stored in the project's /data folder. If you have content stored outside the /data folder or in the additional /data folders, you will have to upgrade it manually.

As a result, the binary executable and configuration files, meshes, terrains, worlds, nodes, splines, materials, properties, tracks, settings files will be upgraded to new formats (if any). The <unigine_project>/migration.log.html log file will be opened in the web browser. However, you can uncheck Migrate Content during automatic upgrading and perform content upgrading manually. In this case, only binary executable files will be upgraded.

Notice
The migration results depend on the version of UNIGINE SDK, from which you are going to migrate.

Manual Upgrade#

Warning
This mode should be used to upgrade content stored outside the project's /data folder (such as mount points).

To upgrade the project's content in the manual mode, do the following:

  1. Put the binary executable <UnigineSDK>/bin/usc_x64.exe to the <UnigineSDK>/utils/upgrade folder that contains the upgrade script.
    Notice
    Use usc_x64.exe from the SDK version you are migrating to.
  2. In the command prompt, run the upgrade.usc with the required options:
    Shell commands
    usc_x64.exe upgrade.usc path/to/additional_content_1 path/to/additional_content_2 ...
    If you have unchecked Migrate Content during automatic upgrading, add the path to the project's data folder to the list of arguments passed to the upgrade script. For example:
    Shell commands
    usc_x64.exe upgrade.usc <unigine_project>/data path/to/additional_content_1 path/to/additional_content_2 ...
    Here:
    • path/to/additional_content_* - paths to folders with content stored outside the /data folder.

As a result, you will get your meshes, terrains, worlds, nodes, splines, materials, properties, tracks, configuration and settings files upgraded.

Notice
The migration results depend on the version of UNIGINE SDK, from which you are going to migrate.

As soon as migration is completed, run the Editor to have the project assets "indexed".

Migration of Object Particles#

Particle System has been updated to make deflectors and spacers separate entities, and after migration these objects will be created and placed to the root of the World / Node Layer hierarchy. You'll have to manually configure them and move to the required place in the hierarchy.

Migration of Graph-Based Materials#

Due to the bug fix in the TextureRamp parameter of Material Graph child materials, warnings may appear in the console after the migration. These warnings will guide you through the manual migration.

Migration of Objects with Immovable State Enabled#

Before 2.17 you could set the Immovable flag for any node, and actions with nodes added to the immovable spatial tree were unrestricted. Now for optimization reasons such objects can't have a physical body assigned to them, that's why after migration the Immovable state will be disabled for objects having a physical body. Thus, if you need to make such objects immovable, remove their physical bodies manually and enable the Immovable state for them.

New Spatial Temporal Denoiser#

Global Illumination settings have been improved, and the denoiser has radically changed, so the related settings should be configured anew.

By default Denoise is set to Sharpest Low, reconfigure it manually if required.

Last update: 2023-06-23
Build: ()