Interface Overview
Assets Workflow
Settings and Preferences
Adjusting Node Parameters
Setting Up Materials
Setting Up Properties
Landscape Tool
Using Editor Tools for Specific Tasks
Setting Up Development Environment
Usage Examples
UUSL (Unified UNIGINE Shader Language)
File Formats
Rebuilding the Engine and Tools
Double Precision Coordinates
Common Functionality
Controls-Related Classes
Engine-Related Classes
Filesystem Functionality
GUI-Related Classes
Math Functionality
Node-Related Classes
Networking Functionality
Pathfinding-Related Classes
Physics-Related Classes
Plugins-Related Classes
CIGI Client Plugin
Rendering-Related Classes
This version of documentation is OUTDATED! Please switch to the latest one.

Content Migration

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

Automatic Upgrade

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

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.

In the 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.

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

Manual Upgrade

This mode should be used to upgrade content stored outside the project's data folder:

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

  1. Put the binary executable <UnigineSDK>/bin/usc_x64.exe (or <UnigineSDK>/bin/usc_x86.exe) to the <UnigineSDK>/utils/upgrade folder that contains the upgrade script.
  2. In the command prompt, run the upgrade.usc with the required options:
    Shell commands
    usc_x64.exe upgrade.usc path/to/the/additional_content_1 path/to/the/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/the/additional_content_1 path/to/the/additional_content_2 ...
    • path/to/the/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.

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

Migrating Content to New File System

Since UNIGINE 2.7.2, there is a mount point feature that is used instead of multiple data paths, external packages and *.ulink files to extend the project.

Migration to mount points includes not only reorganization of project files, but also the source code migration.

If you use multiple data paths (additional -data_path command-line options that allow access to external resources), *.ulink files, external packages or OS symbolic links, you can simply replace them by mount points:

  1. Remove all additional -data_path and -extern_package CLI options specified on the application start-up. Leave only one -data_path that specifies the path to the project's data directory.
  2. Remove all *.ulink files and symlinks from the data folder.
  3. Instead of each removed item, create a mount point that refers to a folder or package with external content. It can be done via UnigineEditor or API.
    You can also accumulate all external folders specified in the *.ulink files in a single one and create a mount point for it.

Remember that the runtime files are now generated per mount point. For successful migration, the editable mount points (not read-only) should be created via the Editor: it will reimport all content of the external directories, and in each of them, the .runtimes folder and the guids.db file will be generated.

When a mount point is used by multiple users, it should be read-only to avoid issues. It means that after migration, you should make all mount points to be read-only.

You cannot create such a mount point that provides access to external content in such a way as if it is stored in the root of the data folder (like it was with multiple data paths). When specifying a virtual path to a file inside the mount point, it always includes the name of the mount point. For example, if you have a data/external_image.umount mount point, that refers to D:\external_content, you should access any file in this folder as follows:


Migrating Impostors

All impostors should be rebaked after migration. Please, check the article on Impostors Creator tool for details.

Last update: 2018-08-10
Build: ()