UNIGINE 2.7.2 Available

Along with bugfixes and overall stabilization this release introduces a number of new important and long-awaited features.

Notice: UNIGINE 2.7.2 SDK requires SDK Browser version 1.9.7 or later.

Improved File System and Collaboration

We continue improving our File System to make it more reliable and flexible. We know that collaborative development of projects is one of the most important features for you, so your demands and suggestions were taken into account to provide easy and convenient project workflow.

UNIGINE File System now lets you use:

• single content source for several projects (folder, network share, or repository);
• several content folders for a single project (analogue of multiple data paths).

You can combine both to fit your needs, thus re-using content, avoiding unnecessary copying and simplifying collaboration between the members of your team:

• letting several artists work with various content folders independently;
• making programmers and artists independent by splitting code and content.

Mounting External Content Directories

Introducing a new mount point feature – a sort of a symlink enabling you to extend the virtual file system of your project by adding any external folders and packages to the data directory. This feature replaces external packages, *.ulink files and multiple data paths.

A UNIGINE-based project now has a single data directory containing all assets and runtimes of your project. It can also contain mount points created via Asset Browser (Create -> Create Mount Point).

All folders inside a mount point are treated by the file system as ordinary folders with assets inside the data.

Inside each mount point, there is a .runtimes folder that stores runtime files generated for assets of the external directory. Note that they aren’t added to the data/.runtimes folder. If you move an asset from one mount point to another, its runtimes will be moved as well.

When a mount point is used by multiple users, only one of them can modify it, for others the point should be read-only.

A read-only mount point doesn’t allow any changes in the folder or package it refers to. Such folder must contain assets with all .meta files and runtimes generated. Otherwise, they won’t be available in the Asset Browser. The workflow here should be as follows:

• All .meta and runtime files for assets are generated once and saved/committed to the common folder/repository.
• For each project using assets from this folder/repository a read-only mount point referring to it is created.

Please note, that all .meta files and runtimes in the mounted directory/package must be valid and up-to-date. All assets, that were not properly migrated, as well as the ones having outdated .meta or runtime files will be unavailable and won’t be displayed.

When working with mount points there are rules to be followed:

• Nested mount points can be used: a folder referenced by a *.umount file can store another *.umount file, etc. However, looped (recursive) mount points are not allowed: you cannot create the 2.umount inside the 1.umountthat refers to 1.umount.
• *.umount files cannot be packed, as well as packages cannot store other packages.
• Each *.umount file should have a unique name. If the data folder contains a folder having the same name as the mount point, this mount point will be ignored.
• Automatic resource reloading isn’t available for the mount points. So, you will have to update each of them manually by right-clicking it in the Asset Browser and choosing Refresh Mount Point.

A mount point is represented on the disk as a *.umount file in JSON format.

Optional guids.db File

Collaboration is no longer bound by the one and only guids.db file, now it is optional and can be stored anywhere inside the data folder: the Engine will be able to read it. Each folder of the project, whether it is mounted or not, can have its own guids.db file.

Moreover, the Engine can now read asset .meta files. So if a file wasn’t found in the guids.db for some reason, or guids.db files are missing, the Engine will search among all .meta files inside the data folder and all mounted external directories and packages.

CAD Models Import

UNIGINE’s Import System is getting more and more versatile, this time we added a new CadImporter plugin that allows fast importing of heavy CAD models in native formats into UNIGINE: IGES, STEP, STL, BREP. The list of supported formats will be extended in future releases.

M-11L aircraft engine by Michael

As the Import System is utilized by both the Engine and the Editor, you can import your CAD models at run time via C++ and UnigineScript API as well as in the Editor. The plugin is fully customizable, just like the FbxImporter.

UNIGINE ensures correct importing of all details of a CAD assembly model, even the smallest ones. All details of the assembly are available in the World Hierarchy, and each surface can be set up individually.

Model of a Jet Engine based on a twin spool gas turbine engine design by Vasileios Thalassinos

The CadImporter plugin provides a lot of useful options, such as mesh splitting and merging, changing the model’s pivot point, scaling, importing materials, etc. They cover all components that can be imported from a CAD model. You can also modify the plugin to add functionality of processing any custom attributes (user-defined properties) of your CAD models.

For more information on CAD import options please refer to this article.

Importing of CAD models is available only in Engineering and Sim editions of UNIGINE 2 SDK.

Classic Volkswagen engine by Juan Arroyave

Impostor Improvements

Impostors, that are used almost everywhere for performance optimization, now look even better due to improved fading between LODs and perfectly match initial objects, making the whole trick almost unnoticeable while giving a significant boost. Impostors baking became much faster, flexible and convenient: baking performance increased up to several times.

Please note, that after migrating your content all impostors should be rebaked.

Impostors Creator

Generating impostors for Mesh Clutters is easier now, just select the desired MeshClutter object (e.g. a forest) and click Create in the Impostor Creator window – a new Grass object with generated impostors will be added as a child to your selected Mesh Clutter. All you need to do manually is to adjust visibility distances for Grass object’s surfaces, as by default they are set to -inf and inf.

Changes have affected most options of the tool:

• SSAO texture is now baked ignoring global ambient occlusion settings in the Settings window to ensure the correct result.
• You can now choose to how to bake your albedo texture with or without SSAO, the first option is a new one and visually gives more volume, the second one just copies the data from the albedo buffer (like it was before).
• Improved baking of Normal and Translucence textures for vegetation, you can now choose the way your textures are to be baked to fit your needs:
  • for vegetation: normal map will add more volume to the final look of your impostors, while translucence texture will imitate translucence of a real tree crown.
  • for other objects: both textures will simply contain data copied from the corresponding buffers (like it was before).
• Now it is possible to set any supersampling ratio regardless of texture resolution.
• Padding size can now be set for all textures.
• Impostor textures now ensure that when rotating a camera around any tree its trunk will exactly match its geometry original regardless of its shape complexity.
• All grabbed textures use point filtering and have the Unchanged option disabled (i.e. runtime files are created for them and mipmaps are generated).

Impostors Materials

grass_impostor_base and billboards_impostor_base materials have been improved as well:

New samples illustrating improved impostors can be found in the Samples demo package included in the SDK.

Improved Particle Systems

Particle systems are used almost in every project to create impressive visual effects. So, we made a number of improvements to make the process of adjusting them in the Editor more flexible and convenient. Now you can control re-initialization of the particle system when it is enabled via the Clear on Enable option: when this option is disabled, turning on the particle system will restore the state it had before it was turned off, otherwise it will be re-initialized. Thus, you can easily test and adjust your particle systems directly in the Editor, even the ones that are spawned only once (such as explosions).

You can also control the number of particles to be generated each time according to the spawn rate via the new Number per Spawn option.

The Limit option of the emitter now specifies the total number of emitted particles: the number of particles existing in the world cannot exceed this value.

For example, if the Number per Spawn value is 10, and the Limit value is 5, only 5 particles will be emitted. No new particles will be spawned until the previous ones exist.

Refactored Voxel and Environment Probes

Refactored Voxel and Environment probes resulting in up to 3 times increase in overall performance. The basic workflow now is to use Voxel Probes for lighting, and Environment Probes for reflections. However, you can also enable both lighting and reflections for a Voxel or Environment Probe via the corresponding options.