This page has been translated automatically.
Programming
Fundamentals
Setting Up Development Environment
Usage Examples
UnigineScript
C++
C#
UUSL (Unified UNIGINE Shader Language)
File Formats
Rebuilding the Engine and 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
Networking Functionality
Pathfinding-Related Classes
Physics-Related Classes
Plugins-Related Classes
CIGI Client Plugin
Rendering-Related Classes
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.

Virtual World Structure

A Unigine-based virtual world is a scene that includes a set of different built-in objects with certain properties. Almost all of the objects can be seen in the virtual world. However, some of them are pseudo-objects, which cannot be displayed in a normal mode (such as physicals, sectors, occluders and so on).

In general, a world includes the following:

  • Built-in objects called nodes, which, in turn, may refer to other nodes (*.node), meshes (*.mesh), audio files (*.oga), paths (*.path) or scripts (*.h).
    Notice
    A world can store both nodes themselves and/or references to nodes stored in external *.node files. A *.node file, in turn, can also store both nodes and references to other external *.node files.
  • Materials and properties.
  • Shaders and textures to which materials refer.
  • General rendering, physics, sound and game settings.

A new world can be created via the Menu bar of UnigineEditor or via Unigine SDK Browser when creating a new project.

Each world is stored on the disk in a separate file in the XML format with the .world extension.

Notice
To be loaded properly, a world must be stored together with a world script UnigineScript file (*.cpp) named after this world.
In general, the world and the world script can interact bilaterally: via the world script you can affect the world by using data received from this world. However, there may be the following cases:
  • A world script has no implementation. In this case, the world content is created and managed via UnigineEditor.
  • A .world file is empty. In this case, the world content is generated and managed via the world script.

Interaction of the Main Components of the World

Worlds can be as large as a level designer wishes as Unigine supports data streaming, and required resources — meshes, textures, animations, sounds — are dynamically loaded in run-time. Resources that are no longer needed are unloaded from memory.

Notice
As coordinates of objects in a world are stored as floats, the accuracy of the float data type may be insufficient. However, visual artifacts are noticeable for small objects starting from the distance of 50  thousands units.
Also, for common outdoor scenes, we recommend you to use the scale 1 unit = 1 meter, when you export objects from a 3D modeling software.

For convenience of a large world designing and editing, a world can be split into several parts.

Coordinate System

The 3D space in Unigine is represented by the right-handed Cartesian coordinate system: X and Y axes form a horizontal plane, Z axis points up. When exporting an animation from 3D editors, Y is considered a forward direction.

Coordinate System

Positive rotation angle sets the rotation counterclockwise. It corresponds to the right-hand rule: if you set right hand thumb along the axis, other fingers wrapped will show rotation direction.

Rotation Directions

Built-in Objects

Unigine provides a set of built-in objects allowing you to add to a world practically all of the objects existing in real life. For convenience, they are divided into several groups that are responsible for different kinds of operations.

Notice
In terms of Unigine, all of the objects added into a scene are called nodes and displayed in the Nodes window of UnigineEditor.

A world can store both nodes themselves and/or references to nodes stored in external files with the .node extension.

Notice
Irrespective of whether a node is stored in a world or in an external file, it will consist of the same entities.
A node can refer to a mesh ( *.mesh), an audio file (*.oga) or a path (*.path) depending on the node type.

Nodes of object-related types may have surfaces and physical bodies (including collision shapes connected with joints). Surfaces contain references to particular materials and properties. Such references are created automatically when you assign a material or a property to a surface.

Notice
A single surface can refer only 1 material and 1 property.

A surface serves as an atomic rendering unit and can represent:

  • A part of the object that needs to have its own separate material.
  • Different levels of details (LODs) (including reflection LODs and shadow LODs). In this case, they represent the same object or its part in more or less detailed variants (a high-polygonal and a low-polygonal model). Which of these surfaces is visible at any given time is determined by the surface properties.
Each surface can also have several morph targets (blend shapes).

Taking into account the information given above, the scheme of world's components can be extended as follows:

Interaction of the Main Components of the World

Node Hierarchy

All nodes are organized into a hierarchy. Each node can have multiple children.

Nodes Hierarchy List in the Nodes Window

Usually coordinates and orientation of the first-level nodes are set in the global (world) coordinate system, while coordinates and orientation of their child nodes are in local coordinate systems of their parents (if not chosen otherwise). This allows easy transformation and rotation of the whole hierarchy tree branch only by transforming and rotating the root node.

The origin of the global (world) coordinate system is located at the scene center. The origin of the local coordinate system is at the pivot point of the parent node.

Surface Hierarchy

As it was mentioned above, nodes of object-related types can have surfaces. By default, such a node added via UnigineEditor has 1 surface and serves as a root for this surface.

Surfaces

Hierarchy of Surfaces

The number of surfaces depends on how a mesh was exported from a 3D editor and cannot be changed dynamically in the runtime. Each surface may add a separate DIP call to the GPU.

Notice
However, identical surfaces of identical meshes with the same material are automatically instanced and drawn in one DIP call.

Surfaces also participate in culling of invisible parts of the object when it is hidden by some other objects on the foreground. Moreover, they are used to calculate collision detection with physically simulated objects.

Notice
It is strongly recommended to keep the number of surfaces in the exported art assets as low as reasonably possible to reduce the amount of computations.

Nodes share common options for their surfaces. Each surface can be enabled or disabled for rendering, as needed.

Notice
Disabling or enabling a parent surface won't disable or enable its child surfaces.
The surfaces' hierarchal order can be freely changed (by dragging the node with ALT pressed). However, the surfaces themselves cannot be added, deleted, or otherwise altered in UnigineEditor. The reason is that surfaces are formed during object creation in an external 3D editor. So to change them, one needs to re-export the object.

The surface uses a separate material and a property.

Surfaces often represent LODs of the same object. For the detailed description of Min parent, Max parent, Visible and Fade distances parameters, see Level of details.

Physical Simulation of Objects

Besides being only a non-interactive environment, objects can take part in physical simulation. To be effective and at the same time keep the overall framerate high, physics is always a very rough approximation of the real world. Its main aim is to detect collisions between the objects.

For that, an object should be assigned a body that describes how it can behave and what physical properties it possesses. For example, whether it is a rigid body that always stays solid and undeformed or a cloth which can be folded and torn.

However, the type of the object's body is not enough for an object to start interacting. Its volume should be approximated using some kind of a physical primitive (or a set of them) — a shape. Unigine provides several types of such primitives: a box, a sphere, a capsule, a cylinder, a convex hull, or an arbitrary mesh shape. The shape is used to compute collisions between the objects.

A couple of shapes can be connected with one of the joints: fixed, ball, hinge, prismatic, cylindrical, wheel or suspension. They describe how two shapes can possibly move relative to each other.

Materials

Nodes themselves are rendered red in the scene. The information on how a node is to be correctly rendered is stored in the materials assigned to particular surfaces of the node. A material is a set of properties (states, options, parameters) and assets (2D, 3D textures), based on which surfaces are rendered.

Material Ball with No Material Assigned
Material Ball with mesh_base Material Assigned
Even if no material is assigned to the node surfaces (surfaces), it still can participate in collisions and intersections.

To manage rendering of surfaces with no materials assigned, use the viewport mask.

Notice
Thoug the surface isn't rendered according to the viewport mask, its shadow will still rendered.

In Unigine, there are 2 types of materials:

  • Read-only base materials created by programmers and stored in *.basemat files. A Unigine-based project includes a set of default base materials.
  • Editable user materials inherited from the base materials or from the other user materials and stored in *.mat files. Such materials are created by 3D artists and override properties of parent materials.

A set of base material properties may include:

  • Options. The set of options is pre-defined and invariable for all materials. Each option either enables or disables some kind of behavior. Option values for base materials are hard-coded.
  • States. They define conditions, basing on which Unigine selects appropriate shaders, textures, and parameters among all defined. For example, one can define a state turning on and off drawing of foam in water simulation and provide different shaders for both states (with and without foam).
  • Textures. Usually, the base material has several textures defined. The common reasons for it are the following:
    • A shader may need more than one texture for processing.
    • Usually, different textures are used on different rendering passes.
    • States also may influence the number of textures, for example, each state may require its own texture.
  • Parameters. They are passed as arguments to shaders, which require them.
  • Shaders. They are the very core of base materials. It is shaders which actually draw the material based on different conditions.
    Notice
    Only base materials can refer to shaders.
    Each base material is usually equipped with several shaders, and the appropriate one is chosen according to the current rendering pass and state.

A set of user material properties cannot differ from the base material ones: the user material inherited from the base material only overrides all its options, states, textures and parameters.

Notice
The user material cannot refer to a shader. It only can override properties sent to shaders used by the base material from which the user material is inherited.

In Unigine, there are also manual materials. Such materials are created and edited manually: changes made via Materials Editor in run time won't be saved. All base materials (both the built-in and the custom ones) are manual. However, not every manual material is the base one: the user materials can be manual too.

Notice
You can use the same name for the base (*.basemat), user (*.mat) and manual (*.basemat or *.mat) materials within one project: it won't raise any conflicts.

Material Hierarchy

In Unigine, materials are organized in hierarchy, like nodes, but are completely independent from the node hierarchy.

A parent material passes its properties to the inherited material so that they can be overridden.

Notice
All inherited and non-overridden properties will be updated automatically, if they are updated in the parent material.

The base materials cannot be organized in hierarchy: no base material can be inherited from another base material. However, if you need to modify properties of a base material, you can create a new user material by inheriting from the required base material: the base material will pass its properties to the inherited material and you can override them. Thus, the base materials are always on the top of the material hierarchy.

Materials hierarchy is based on GUIDs. For the base and manual materials, they are generated in run-time by using their names stored in materials files. For the user materials, they also generated in run-time on materials' creation and stored in the *.mat files. However, in materials files, references to the materials can be name-based or GUID-based.

Notice
Surfaces reference to materials by GUIDs only.

When cloning or inheriting a material, each new material becomes internal until a name is assigned to it.

The loading order of materials doesn't matter: on the engine start-up, all materials of the project are loaded, the base materials are loaded first. And since each *.mat material refers to both the parent and the base materials, the base material is used as the parent one until the parent is loaded. So, when the application is loaded, all materials existing in the project are presented in the materials hierarchy.

Hierarchy of Materials in the Materials Window

Look at the picture below, for example.

Material Ball with mesh_base Material Assigned
Material Ball with a User Material Inherited from mesh_base

The left material ball is rendered using one of the built-in base materials. The right material ball inherits its material from that base and simply changes 2 textures (the albedo and normal textures). There is no need to set other properties, as they are inherited. However, if one needs, they may change any property, just like we've changed the texture for the material ball.

All material properties (except shaders) can easily be overridden in UnigineEditor. However, if you need to extend the set of existing properties or override shaders, you need to create a custom material. In this case, refer also to the Materials Files section, as it contains a thorough description of material declarations in XML.

Properties

For the object to be correctly integrated in the world, defining its position, inherent characteristics and outside appearance will be insufficient. The properties specify the way the object will behave and interact with other objects and the scene environment.

A property is a set of options, states and parameters:

  • Options. The set of options is pre-defined and invariable for all properties. Each option either enables or disables some kind of behavior. Option values can be changed only for custom properties; options for base properties are hard-coded.
  • States. The states define conditions, based on which parameters of the property becomes available/unavailabe for reading and editing.
  • Parameters. Logic-related parameters.

For example, they specify if the object is interactive and whether it is a switch. For a character, properties can specify the character health points or gold amount. Thus, the properties make the nodes comply with the game/application logic.

Property Hierarchy

A property hierarchy is represented by the hierarchically organized list of the properties, which can be assigned to the nodes used in the scene. A property hierarchy is independent of node and material hierarchies.

Hierarchy of Properties

By default, Unigine provides 2 base properties which are at the top of hierarchy and cannot be changed. If you need to change a particular setting of the base property, you can create a new property by inheriting from the base one.

Notice
When inheriting from a property (the base or the custom one), the parent property passes all its settings to the child property. If the parent property (except the base one) is modified later, all inherited properties will be updated automatically.
You can also create a custom property on the same level as the base property and specify any settings for it.
Notice
If the new property is assigned to a node surface, it should be inherited from the surface_base property or from one of its children. Otherwise, the surface can behave incorrectly.

The hierarchy is easily edited in the desired way: the inheritance relations can be changed simply by dragging, properties can be cloned, assigned or removed with one button click. Apart from cloning the whole property, it is also possible to copy separately all its settings, choose another property, to which they will be applied, and merely paste them.

Property Libraries

To be used in the world, a set of properties should be organized in libraries. Property libraries describe states and parameters of properties as well as parent-child relations. They are stored in the XML file with the .prop extension that should be declared in the .world file for library preloading.

If you add a property library via the Properties window of UnigineEditor, the reference to this library will be added to the .world file automatically.

By default, Unigine SDK includes a set of property libraries located in the data/core/properties directory.

Notice
There is no need to include the default property libraries into the world, they are included by default.
Last update: 2017-10-20
Build: ()