UNIGINE 2.11: Community Edition, Performance Optimizations, Better Particles, Archviz Demo

[fox]

Key Changes

• Community Edition, free for non-commercial/academic projects, as well as for commercial projects with revenue or funding less than $100K in the last 12 months.
• Optimized performance: async node update, optimized bounds calculation.
• Better input handling and window management via SDL.
• Improved particles shading.
• C# Component System updates: renaming, simple inheritances, parameter conditions.
• Significantly improved multi-channel rendering, revamped Syncker system.
• Usability improvements and performance optimizations of UnigineEditor.
• Fox Hole archviz demo with both desktop and VR modes.

New SDK Edition: Community

The new Community edition of UNIGINE SDK from now on is available to everyone for free as well as all future updates! You can download the SDK and use it for game development, as well as to create projects for archviz, product visualization, film and animation, education, or VR apps.

The UNIGINE 2 Community uses the same core technology as other editions (Engineering and Sim), which are more focused on the enterprise area. But Community has some limitations: it doesn’t support 64-bit precision of coordinates, has no support for GIS and CAD data formats, doesn’t support distributed network simulators, lacks some high-level simulation systems, doesn’t support projection onto curved screens, and can’t be embedded into other apps as a viewport. Also, it cannot be used in some industries: defense, gambling, energy, mining, oil & gas. Other than that developers get the same C++ and C# API, as well as the scene editor.

The great thing about the Community edition is that it is completely free (and has no royalty obligations) for several cases:

• Non-commercial projects
• Academic use (education only)
• Commercial projects with revenue or funding less than $100K in the last 12 months

There is also a Community Pro subscription option, which is technically exactly the same as the Community version but has no limitations on the revenue/funding.

Particle System Improvements

Along with extended use of multithreading in Particle Systems we've significantly improved shading for them. The translucency effect became even more true-to-life with the ability to set translucency radius to imitate different smoke density. Shadows cast by particles are now translucent, so the denser smoke areas will produce darker shadows than the ones having a low density. Normal mapping support providing additional volume and more details was added as well. All these improvements together make particles lighting more vivid and consistent with the scene, enabling you to create convincing volumetric effects.

Special buffers used to store vertices and indices for particles are now created in GPU memory at startup. The maximum limit of GPU memory to be reserved for these buffers can be set in the UnigineEditor (Settings -> Render -> Streaming) or via the render_streaming_particles_memory_limit console command.

Please be aware that setting a too low limit for a huge number of particle systems in the scene may lead to rendering only some of them while skipping others.

The particles_base material is now implemented in ULON-format with a new more convenient UI, some parameters renamed, and default values and textures changed.

More UI improvements, including a Curve Editor for visual adjustment of particle parameters as well as particle simulation improvements, are scheduled for 2.12.

Performance Optimizations

UNIGINE is able to handle huge worlds with enormous numbers of objects. These virtual worlds tend to grow, so we add a lot of new features improving overall performance. Keeping it within strict real-time constraints is a constant challenge where every bit of performance counts.

Asynchronous Node Update

Asynchronous update of nodes in the world depends on their hierarchy, e.g. a child particle system is updated in accordance with the update of the parent one. Before 2.11, distribution of node update load between the threads was performed in the following way: each root node (including the top-level ones stored inside NodeReferences or NodeLayers) in the hierarchy was updated in a single thread with all its children. This means that in order to use the power of multithreading the hierarchy had to be organized in a special way. In the worst case putting all nodes in the scene as children to a single root limited their update to a single thread. Now the Engine does the job!

Instead of processing all nodes in the async update, there are three modes for them now:

• no update - for nodes that do not change and don’t have to be updated (MeshStatic, NodeDummy, Decal, etc.), we simply skip them;
• independent update - for nodes that are guaranteed not to have any hierarchy-based logic, such nodes can be put to separate threads (LandscapeLayerMap, ObjectLandscapeTerrain);
• dependent update (hierarchy based) - such nodes can be influenced by other similar nodes (particles may depend on other particles and so on...) and should be updated together in the same thread.

Nodes can change their update mode, for example, assigning a body to an ObjectDummy switches its update mode to dependent.

Groups of dependent nodes are built automatically, the only thing you have to take care of is to avoid breaking hierarchies of dependent nodes by inserting an independent or non-updated node between them. E.g. if you have a hierarchy of particle systems that should be updated together in one thread, inserting a NodeDummy between them will break this hierarchy and put them to separate threads.

Visibility of an object (be it a particle system or a skinned mesh with animation played) has an impact on how often it is updated (see the Periodic Update section below).

Extended use of multithreading in combination with an internal task system ensures that load is distributed evenly between all available threads.

Periodic Update

Updating each frame a huge number of objects (e.g. smoke, explosions, or crowd simulation) located far away from the camera that are hardly distinguishable or observed as a mass is a waste of resources. What if we update them with a reduced rate, say once in 30 frames? When we say “update” here, we mean Engine’s logic like simulation of particles, water, cloth, or ropes, playback of skinned mesh animations, so please don’t confuse it with user’s logic.

Introducing periodic update - another important optimization feature enabling you to save a great deal of performance. The list of objects that require to be updated includes the following:

• Particle Systems
• Skinned Meshes
• Dynamic Meshes (only with a rope, a cloth, or a water body assigned)
• World Expressions
• World Transform Paths

For each of them you can now specify an Update Distance Limit - a distance from the camera up to which the object should be updated.

In addition to that, for Particle Systems, Skinned and Dynamic Meshes, you can set the following update rate values:

• for the case when the object is rendered to viewport
• when only its shadow is rendered (here we can cut even more)
• when the object is not rendered at all.

Please, note that these values are not fixed and can be adjusted by the Engine at any time to ensure best performance.

This feature is enabled with default settings ensuring optimum performance and can be adjusted per-object in the UnigineEditor or via API at run time giving you an exceptional flexibility in optimization.

In case in your project you had, for example, an invisible particle system (e.g., using the viewport mask) and some logic attached to its update (e.g. spawning some visible particles on collision with objects) this logic won’t work, as the particle system might be updated with a reduced rate or might not be updated at all. To enable updating such objects regardless of their visibility you can set the Update Distance Limit and corresponding update rate values for it to infinity.

Please be aware that using reduced update frame rate for an object should be carefully considered in your application's logic and may also lead to various issues with rendering skinned and dynamic meshes (flickering due to misalignment, e.g. in case of attaching a cloth to a skinned mesh).

Bounds Calculation Changes

Some nodes having their bounds defined by the bounds of their children, such as DummyNode, NodeReference, or NodeLayer, especially the ones with complex hierarchies took a lot of time to recalculate such hierarchical bounds. Moreover, calculation sometimes was incorrect, for example, in case the hierarchy contained skinned meshes or particle systems having their bounds changed every frame, as recalculation of all bounds in the hierarchy every frame would certainly drop performance drastically in projects with sophisticated node hierarchies.

We have revised the whole bounds system making it fast, clear and straightforward. “Abstract” objects (having no visual representation or their own size) like DummyNode, NodeReference, or NodeLayer now do not have bounds at all and therefore are excluded from the spatial tree. This significantly reduces the size of the tree and improves performance due to saving time on bound recalculation when transforming such nodes.

The following types of bounds are used:

• Local Bounds - bound objects with local coordinates which do not take into account physics and children: BoundBox and BoundSphere.
• World Bounds - same as local ones, but with world coordinates: WorldBoundBox and WorldBoundSphere.
• Spatial Bounds - bound objects with world coordinates used by the spatial tree, and therefore taking physics into account (shape bounds, etc.): SpatialBoundBox and SpatialBoundSphere.

And their hierarchical analogues (taking into account all children) to be used where hierarchical bounds are required (they are slow, but offer correct calculations):

• Local Hierarchical Bounds - bound objects with local coordinates taking bounds of all node’s children into account: HierarchyBoundBox and HierarchyBoundSphere.
• World Hierarchical Bounds - same as local ones, but with world coordinates: HierarchyWorldBoundBox and HierarchyWorldBoundSphere.
• Spatial Hierarchical Bounds - hierarchical bound objects used by the spatial tree, and therefore taking physics into account (shape bounds, etc.): HierarchySpatialBoundBox and HierarchySpatialBoundSphere.

New Spatial Hierarchical Bounds are equivalent to former bounds of a NodeDummy with all its hierarchy.

Please note that spatial bounds are calculated faster than World ones.

Regarding the changes described above you should pay attention to the following:

Intersections are detected only for nodes having bounds. So, to find an intersected NodeReference or a NodeDummy you’ll have to find one running up the hierarchy from an intersected node.

New Physics Intersection Mask

We have changed the way of detecting intersections - world intersections (i.e. between object bound volumes or ray intersections with object surfaces) and physics intersections (between physical objects with bodies and collider shapes or ray intersections with collider geometry) now use separate masks, enabling you to control them independently, which gives more flexibility. So, a new Physics Intersection option with its own Physics Intersection Mask were added to the list of surface parameters.

Physics intersections can be used, for example, to detect collisions of spawned particles with physical shapes and bodies or static collider surfaces to ensure proper interaction, or as a quick way to detect collisions for raycast-wheels of a simulated ground vehicle, or to check if a destructible object or a player was hit by a projectile. Particle systems, shapes, fracture bodies, player actors, and wheel joints now use the new Physics Intersection mask.

The Intersection option and the Intersection mask remain responsible for such features as selecting and highlighting objects under the mouse cursor, or cutting grass in areas occupied by other objects.

Automatic Collider Detection

Collision detection is now automatically enabled for an object if it has a body assigned or at least one of its surfaces has the Collision flag set. This makes the Collider flag of the node redundant - so we removed it. Less boxes to check - simpler adjustment and less chance to make a mistake (false-colliders waste resources).

Other Performance Optimizations

• Significantly improved performance of Mesh Clusters and Clutters with improved Visibility Distance calculation object’s visibility distance does not exceed the maximum distance among its surfaces.
• Improved performance of dynamic reflections.
• Improved rendering performance for Skinned Meshes on DirectX due to optimized velocity calculation.
• Improved File System initialization for huge numbers (hundreds of thousands) of files in the data folder making it 2-3 times faster.
• We’ve also made a pack of minor optimizations for occluders allocation, batching and surface management, and others, all contributing to overall performance improvement.

Improved Multi-Channel Rendering

Syncker, our multi-channel rendering system, has been completely revamped ensuring even more robust and reliable frame-to-frame synchronization with extended flexibility giving you much more freedom. You’re no longer bound to a single subnet and free to adjust display configurations at runtime via API and a lot more. The whole system has become even easier to configure and more convenient to use, as it now tries to automatically set as many parameters as possible, saving you the trouble of specifying ports and addresses, as well as removing the headache of ensuring delivery of messages.

Here is a brief list of major improvements:

• In addition to the former one and only Broadcast addressing mode now there are two more available: Unicast and Multicast. Hosts can now belong to different subnets!
• In addition to Asynchronous mode a new Synchronous mode is now available and enabled by default.
• Reduced number of ports: Syncker now uses a single UDP port instead of 2 TCP and 1 UDP ports. Easier to configure, simpler API no more sequencing problems.
• Automatic connection feature. You don’t have to think about IP addresses and ports anymore! Just define the Master and the number of Slaves to be used - that’s it!
• Reliable, sequenced packet sending using automatic compression, merging, and defragmentation when necessary. You don’t have to think about delivering your messages anymore. Simply sent, simply received - that’s it!.
• A lot of long-awaited functions added: screen/projector configurations can now be adjusted via API! Conversion of projection config files from old binary to new xml-based format via API is also available.

Syncker Demo

The Syncker demo has been updated to ensure maximum coverage of the Syncker Plugin API now demonstrating how to:

• Set cameras on slaves to target different objects.
• Enable individual logic and controls for each slave.
• Change the logic on slaves: for example, enable thermal imaging on a certain slave.
• Create objects and enable physical interactions for them.
• Animate objects based on the current time if their position can be pre-defined — that allows optimising network data transfer.
• Make Syncker a network library.

For more information on the changes please refer to the Syncker Plugin article.

Better Input Handling And Window Management

Implementation of window creation and management, system dialogs, as well as keyboard and mouse management in the Engine’s App class now uses SDL (Simple DirectMedia Layer), a cross-platform development library providing low level access to audio, keyboard, mouse, joystick, and graphics hardware via OpenGL and Direct3D. This improves interaction between various windows and dialogs of the application, including the ones created by plugins, and makes the whole system more stable. It also eliminates a lot of issues from flickering mouse cursors to unresponsive windows. System dialogs became easier to manage with a new SystemDialog base class, and are now available for both Windows and Linux.

Applications no longer have to implement their own file dialogs, as they can use standard ones. Improved full screen and windowed modes now work properly on multi-monitor configurations on Linux as on Windows.

Mouse cursor management has also significantly improved with a pack of new convenient methods added, enabling you to set custom skins, for example.

For more information please refer to the API Migration Guide.

Anti-Aliasing for Wireframe and FFP

Added anti-aliasing for wireframe and visualizer along with other FFP lines.

 

 

 

 

Anti-Aliasing: Off

Anti-Aliasing: On

 

Both options can be controlled via the Helpers panel or via the console command: render_ffp_antialiasing_lines or render_wireframe_antialiasing.

Updated Property Parameters

Switch parameter of the property is now one step closer to enums in C#/C++. Now it is a set of values, each of these values may have an optional arbitrary name (Item) associated with it.

Items can have positive or negative values, several items can have the same value.

You can define a switch parameter as follows:

<parameter type="switch" items="red=-1,green,blue=5,yellow"/>

A set of new types of property parameters is now available: vec2, dvec2, dvec3, dvec4, ivec2, ivec3, ivec4. These parameters are supported by both C++ and C# Component Systems.

Other Engine Improvements

• Improved filmic tonemapper making the resulting image even less deviating from the original, but ensures more efficient correction of excessively bright areas of the screen and makes the result even more realistic.
• Automatic laptop GPU detection for C# projects has got better with increased accuracy and reliability.
• Fixed incorrect loading of tiles for the ObjectTerrainGlobal with insets when the moving camera is far away from the origin causing visual artefacts of terrain albedo textures.
• Customizing your application is simple, as the window title can now be specified at Engine startup as an argument of the Engine::init() method.
• Improved Tracker Tool performance when processing complex track-based tracks making it up to 10x faster.
• Fixed an issue with application becoming unresponsive when loading a world containing mesh clutters with collision detection enabled having a LandscapeLayerMap as their ancestor, in case the world also contains at least one physical object (with a body and shape assigned and enabled).
• Fixed a crash occurring sometimes when switching between worlds.
• Fixed a crash on loading a world containing a NodeReference with a WorldCluster inside.
• Added a new scoped CPU/GPU profiler for your application logic. Now you can mark fragments of code to be monitored by simply adding a macro inside the scope you'd like to inspect:

  void myFunction()
  {
  	UNIGINE_PROFILER_FUNCTION;
  	// your function code
  }

• Fixed an Engine crash on selecting a CloudLayer with a 3D Detail Distortion Texture.
• Fixed various issues with baking static shadows for Mesh Clutters.
• Fixed an issue with the Editor becoming unresponsive during the light baking process.
• Fixed an issue with saving and restoring the current world state that appeared in the previous release. Now both operations work properly, as they were before 2.10.
• Inheriting or cloning a read-only material now produces a material that can be modified (not read-only).
• Fixed particles rendering artefacts on AMD in case Ambient lighting and Use Voxel Probe lightning options enabled for the particles_base material.
• Fixed an issue resulting in Field Height Particles not affecting water.
• Fixed an issue with Decal Particles rendering.
• Fixed rendering artefacts with materials using the old Specular workflow.
• Fixed a crash on the Engine shutdown with the Interface plugin loaded.
• Fixed an issue with phantom node reference duplicates appearing after deleting a previously created instance and adding the same node reference to the scene again.
• Fixed issues with baking lighting to a VoxelProbe located more than 600 units away from the origin related to probe’s far clipping settings.
• The Clear on Enable option now clears particles correctly.
• Unigine projects are now compiled correctly on Linux when using GCC 5.0 and higher.
• Fixed issues with updating the Spatial Tree by the MeshCluster resulting in disappearing cluster objects after changing their transformations.
• Animation fields now correctly interact with vegetation objects.
• Render, Sound, and Physics settings stored in the corresponding assets can now be loaded and applied to a world via API.
• Improved detection of intersections with mouse cursor for Widget and WidgetSprite classes: you can now specify an image mask for a sprite widget to be used when detecting intersections with it. For more information please refer to the API Migration Guide.
• File dialogs in the App class are now implemented using the nativefiledialog library and are currently available for Windows only, but Linux support is planned for the next release.
• Fixed an issue with sound playback failure after disabling and enabling a sound device, spikes generated by OpenAL were also removed.
• Improved options management for ULON materials, they can now be operated as states (grouped, hidden, assigned a new name, or a title).
• For any node in the world you can now get whether it is currently inside any WorldTrigger and access any of such triggers by simply calling the Node::getWorldTrigger() method.
• Fixed an issue with ignored max_expand option of the material parameter leading to incorrect clamping of values exceeding the maximum limit.
• EXR files are now supported on Linux. Memory leaks when loading and saving such files were fixed.
• Fixed an issue with KEY_QUOTE and KEY_COMMA key bindings in the Input class, now KEY_APOSTROPHE = KEY_QUOTE.
• Added a new CPUShader class enabling you to create a custom CPU shader, for example, to implement multi-threaded mesh cluster update (currently available for C++ API only). The corresponding sample is included in the SDK(/samples/Api/Systems/CPUShader/).
• Updated FBX SDK to 2020.0.1.
• Updated OpenCascade to 7.4.0.
• Updated OpenVR to 1.9.16.

C# Component System Updates

The C# Component System continues to evolve and has become even more convenient with a set of improvements.

Simple Inheritance

Suppose you have a component implementing certain functionality, and you need a certain number of subcomponents having exactly the same functionality, but different parameter values. This situation is typical when implementing quality presets or configurations of controls. Before 2.11 you'd have to do either of the following:

• write a single component, assign it to nodes and adjust values of parameters for each node (meaning that this should be repeated multiple times for all nodes in all worlds in your project any time you make changes to preset values),
• derive logic implementation from the base component manually by inheriting subclasses from the class of the parent component and adjust preset values (resulting in redundant code).

Things got simpler now - just inherit a property from the basiс component in the UnigineEditor for each preset and tweak necessary parameter values. After that you can assign these inherited properties to nodes, thus attaching to them the logic of the basic component with parameter values taken from inherited properties. No excessive copy-pasting, no redundant code.

Renaming Components

Ideally, you name things properly from the start. The name should be clean and reflective of what it does. But, sometimes things do change, and suddenly you realize that your component’s name has to be changed. Since 2.11 it’s not a big deal. Actually, there are two ways you can do it:

• Renaming your cs-asset in the Asset Browser. Component class and associated property will be renamed automatically. The only thing you have to do in this case is to replace all references to your component class in your source code with new ones in your preferred IDE via Find&Replace.
• Using refactoring tools of your IDE (e.g., Rename symbol in VS Code or Edit -> Refactor -> Rename in Visual Studio). After renaming simply open UnigineEditor - the corresponding cs-asset and associated property will be renamed automatically keeping all references. Please be aware that in this case the name of the cs-file containing implementation of your component will change and the file will be removed from the project by your IDE as a missing one. So, you’ll have to add the renamed file back to the project in the IDE.

Invoking and Overriding Private Methods

Private methods in derived components are now invoked and can be overridden, giving you an exceptional flexibility in implementing your application’s logic via components.

Example:

public class ClassBase : Component {
	 void Init() { Log.Message("ClassBase.Init()\n"); }
	 void Update() { Log.Message("ClassBase.Update()\n"); }
}
public class ClassDerived : ClassBase {
	 void Update() { Log.Message("ClassDerived.Update()\n"); }
}

Now if we create a ClassDerived component, the calling order shall be as follows:

• ClassBase.Init() - private method of the base class (was not invoked earlier).
• ClassDerived.Update() - private method of the base class was overridden by the private method in the derived class having the same name.

Parameter Conditions

Now you can selectively display component parameters if certain conditions are met. So, it is now possible to define such conditions like: "Show parameter A only when parameter selected parameter B value is this, and parameter C value is that".

Example:

public bool my_toggle;
public int my_int;
    
[ParameterCondition(nameof(my_toggle), 0)]
[ParameterCondition(nameof(my_int), 1, 3, 5)]
[ParameterCondition("other_field_name", 2)]
public float my_float;

C# Component Samples

We added a set of C# Component Samples (SDK Browser -> Samples -> Demos -> C# Component Samples) that demonstrate how to apply unsophisticated logic to various types of nodes via C# components. The samples cover various aspects, such as:

• Creating and controlling various cameras: first-person-view, orbital, panning, and persecutor camera.
• Setting character controls and collision shape.
• Enabling input from various devices.
• Using simple but frequently used arcade mechanics: controls, shooting and intersection of bullets with surfaces, node spawning, transformations, and deletion.
• Blending and lerping animations, applying partial blending of bones, rotating bones via code, controlling animation playback.
• Finding intersections between bounds and nodes, between rays and geometry.
• Changing various material parameters in runtime.
• Enabling 2D and 3D pathfinding with obstacles and portals.
• Adding and controlling various types of sound.
• Difference between local and world transformations and the importance of order of Euler angles.
• Various types of GUI widgets and containers.
• All possible types of parameters available in a C# component.

Other C# Component System Improvements

• Names of all new created components shall now be validated for compliance with С# coding standard and naming conventions. In case of invalid name the component shall not be created with the corresponding message displayed in the Console.
• When deleting either a component or a property associated with it, the two are considered as a whole. So, the second file shall be deleted as well.
• When an asset already known to the Editor (from the data folder or a mount point ) is imported causing a potential guid conflict the operation is processed as a copy-paste (new guid will be generated for the copy). In case of a guid conflict when importing a cs-asset (component) the operation shall not be performed with the corresponding message displayed in the Console.
• Fixed an issue with private parameters of the base class with the ShowInEditor flag set ignoring values of property parameters set via the Unigine Editor.

UnigineEditor

Improved Property Parameters Management

When selecting several nodes having the same property assigned you will now see their parameters in the Parameters window. You can adjust these parameters changing values for all properties simultaneously. Simply put, property parameters now have the same logic of multi-selection editing as other node parameters.

Surface property removal for Objects now works properly along with Undo/Redo improvements.

Automatic Generation of LightMap UVs

Creating custom lightmap UVs is a time-consuming process, especially for projects with enormous numbers of assets like tens of thousands and a lot of complex geometry.

Auto-generated lightmaps are a quick way to pack lightmap UVs saving you a lot of time you would otherwise spend on manually setting UVs and padding them correctly.

When importing your own FBX, CAD, glTF, or mesh assets, a lightmap UV will be generated for you automatically when the corresponding box is checked in the Import Options. A set of corresponding generation parameters is available for adjustment.

This feature is implemented using the xatlas Mesh parameterization / UV unwrapping library. And it represents the first step on the way to the LightMapper tool which is currently being developed and is to be completed soon!

Please be aware that generating UVs for too heavy complex geometry (300 Mb+) may take a long time, while in case of a CAD model even a relatively small file (20 kb) may generate a very sophisticated mesh that might be too hard for any UV generator to process.

Project Build Tool Improvements

Added a set of VR options (Use OpenVR, Use Oculus, and Use Varjo) for the Create Build tool to control whether the final build is intended for VR or not, this also defines whether to display VR options in the generated launcher.

Moreover, you can specify a list of available resolutions and additional startup command line arguments for the launcher.

Extending the set of launcher parameters by adding custom ones is now available, currently it can be done by manually editing the following file: data/.editor2/.assemblytool

When building a project the unigine.cfg file containing settings for mouse and controls is now correctly copied to the bin folder.

For more information please refer to the Create Build tool article.

Simpler Mesh Cluster Management

Several improvements were introduced to make mesh clusters more convenient and user friendly, so that even newcomers could easily create and edit them.

Create and Expand buttons have changed their names to Edit and and Apply respectively making they look consistent with Node References. All modifications made to a Cluster being edited shall be automatically applied on saving a world the same way as for a Node Reference.

A new mesh cluster shall now be created with 4 elements (cluster objects) for better understanding how to use it. Baking of new meshes to a cluster: now the only requirement for static meshes to be baked to a cluster is to have the same mesh as the one assigned to their parent cluster. Earlier all mesh surfaces were required to have the same materials and parameters.

Asset Browser Improvements

• Selecting folders in the Asset Browser no longer clears current selection and Parameters window (e.g., when looking for a material asset to drag it to a surface).
• You can now create a new world via the Create menu right in the Asset Browser.
• Fixed issues related to renaming assets or folders in the Asset Browser when new names contain dots and other specific characters.
• Create menu is now available as a subitem of the context menu displayed on right-clicking in the Asset Browser.
• Double-clicking on an unknown asset in the Asset Browser will open it in a third-party application according to system file associations.
• Assets already having meta-files are now imported correctly.
• Renaming an asset in the Asset Browser does not affect its type.

Landscape Terrain Editing

• Fixed a crash on selecting multiple LandscapeLayerMaps in the World Hierarchy and browsing their parameters.
• Fixed an issue with re-generation of Landscape Terrain tiles in case resolution Height in manual import settings for an *.lmap exceeds 16384 pixels.
• Fixed issues with visual artefacts on Landscape Terrain surface when using masks with R16F image format.
• Preview for Landscape Terrain brushes is now displayed at full resolution removing visual artefacts.
• Fixed flipping of brush texture along the X axis when editing landscape terrain masks.
• Added LandscapeLayerMap to World Hierarchy filters.

Other Editor Improvements

• Improved processing of global search requests in projects containing a lot of assets (tens of thousands and more) making it much faster (up to 100x).
• Reloading a world containing thousands of objects in the Editor is now 2x faster.
• You can now create your worlds in UnigineEditor on 4K monitors - improved DPI scaling now ensures that all UI elements are displayed correctly for non-FullHD resolutions. This feature is currently available for Windows only.
• You can now reset windows layout to defaults in a snap by selecting Windows -> Reset Windows Layout.
• Improved hierarchy management UX for World, Properties, and Materials hierarchy windows: easy drag-and-drop. Horizontal scrollbar is correctly displayed for all these windows.
• Assigning .render, .sound, and .physics assets to a world is now available in the UnigineEditor. When assigned these settings shall override the ones stored in the .world asset.

  

• On Linux physics, sound, and render presets are now saved correctly with the corresponding extension.
• You can now select a node in the viewport and quickly navigate to it in the World hierarchy via the “Go to” button in the Parameters window. This option is especially useful for projects with sophisticated World hierarchies containing huge numbers of nodes.

  

• Node ID in the Parameters window can now be copied to the clipboard.
• Rectangular selection of nodes in the viewport by their icons is now supported.
• Fixed an issue with marking Material Mask as modified after simply opening it, causing inconvenience when working with multiselection of materials.
• After selecting a node in the filter mode, it shall remain displayed even after clearing the filter.
• Engine Viewport shall not be displayed for projects using C# Component System, as the Play button covers all necessary functionality making this viewport redundant.
• Clicking any node in the World Hierarchy window and selecting Create will add a new created node as a child to the selected one.
• Double-clicking on a node in the World Hierarchy window does not set the current focus to this node anymore.
• Create Mesh and Create FBX options of the World Hierarchy context menu have moved to the new Export to submenu.
• Fixed an issue with always enabling simplified rendering mode for a world that was at least once saved with this mode enabled.
• F2/F3 hotkeys no longer toggle "Final Image"/"Simplified" rendering modes.
• Fixed issues leading to error messages about GUIDs already in use displayed for assets stored in mount points.
• When assigning a texture asset as a normal texture, the user will be prompted to apply the Normal Map texture preset for it if it has not been yet applied (works only for textures with unchanged option disabled).
• Fixed issues with Edit Size manipulators for cases when the dimensions of node’s boundbox along some of the axes are too small.
• Static shadows are now rebaked when changing the light’s transformation by manually entering values in the corresponding fields in the Parameters window or via spinboxes as well.
• Fixed behavior of Intensity and Lux sliders in common parameters of light sources.
• Material and property names containing dot characters are now handled properly without truncating.
• All keyboard actions are now ignored by the SplashWidget.

Changed Geometry Import Settings (Important)

We have changed default geometry import settings, making meter the default unit in UNIGINE. Automatic content migration is provided. According to our internal statistics, 1% of migrated content requires additional scale correction. So, we strongly recommend you to make sure that after migration all your content has a proper scale. If you have a feeling that after migration your model has become bigger or smaller (e.g., you can’t see it on the scene) simply adjust the Scale multiplier value in Asset Import parameters.

Other Editor Improvements

• Fixed a crash on importing an FBX model with the Merge Surfaces by Materials option enabled.
• Improved Merge Similar Materials option in the FBX importer.
• Fixed an issue with unique material name generation in the FBX and GLTF importers.
• Pivots for imported geometry lods with the Combine by Postfixes option enabled are now calculated correctly.

Demos and Samples

A new Occluders sample has been added to the Art Samples suite. It demonstrates culling of objects hidden behind occluders.

Fox Hole

The Fox Hole archviz/BIM demo is now available for desktop, in addition to the previously introduced VR mode. As for the VR mode, we did some refactoring here to make source code easier to understand, and added tooltips giving you a hint on using various types of controllers.

We have extended the set of controller models displayed in VR, so for each HMD type (HTC Vive, Valve Index, Oculus Rift / Rift S, Windows Mixed Reality) you’ll see the appropriate controllers identical to real ones.

We consider a standalone release of the demo a bit later.

Project Templates

Added a new empty template for C# .NET Core projects (Desktop with starter content) with a simple environment built using a constructor, pre-configured physical primitives with necessary adjustments, baked lighting, and a first-person character component - everything you need to start creating. Source code of all components is available for modification. All this content is intended to demonstrate the basic principles of word building in UNIGINE to new users right from the start. The starter content is located in a separate folder, so you’re free to delete it if it is not needed.

VR Template is now available for C#, not only for C++. The template implements basic mechanics of interaction with environment via the C# Component System.

Moreover, no additional assets will be generated when creating a new world in the project, as it was before. A new world shall now contain only the ground plane, the default light source and the default camera. Material ball’s mesh, texture, and materials were removed from core assets and became a part of template content.

Removal And Deprecation List

Some things need to go as we progress further.

NodePivot

We've removed the Node Pivot as redundant, as you actually can control transformation of a group of nodes by simply building their hierarchy placing dependent ones as children of the one considered as the main one.

Layers, Clutters, and Clusters

World Layer and World Cluster are considered deprecated and will be removed in the next release. Starting from 2.11 creation of these nodes is not available in the UnigineEditor. In case your project contains World Layers, we strongly recommend to replace them with Node Layers, as this significantly reduces spikes and makes your application run smoothly. After a set of performance optimizations including the ones related to spatial tree management and others described below, the World Layer no longer provides any performance gain. Removing it from the world will slightly increase RAM consumption (5-25%, depending on the contents of the layer) but will surely reduce spikes as this node loads the spatial tree heavily. World Clusters no longer provide any performance gain as well, as separate objects become fast enough after optimization.

World Clusters and World Clutters will continue to work as before (at least in 2.11), but without any fixes or new features. More likely these objects will also be removed in 2.12.

We strongly recommend using Mesh Clutters and Mesh Clusters in your projects as they provide significant performance gain!

Sectors and Portals

We've decided to remove sectors and portals. Apart from being rarely used, their old implementation gets more unsolvable issues and unacceptable incompatibilities due to active Engine development.

In case you used sectors and portals in your project we recommend replacing them with occluders. Occluders are clear and straightforward, they are faster, work more stable and offer more flexibility in world building. In case you need to create a room with a door and cut out everything beyond its walls, simply place occluders along the room’s perimeter. Make sure such occluder-walls have zero-width to gain even more performance!

Dataset Classes

Removed Dataset, DatasetRasterPosResolver, DatasetSpatialReference, and DatasetCoordinateTransformer classes from the Engine’s API, since they are far from being a generic Engine feature and represented a very specific and limited wrapper for GDAL functionality.

You are free to use GDAL directly without any limitations of an intermediate level. You can consider the Geodetics plugin code as an example of GDAL initialization. In case the removed classes are required for your project, or you’d like to use them as an example of using GDAL functionality to implement your own logic, we will send you the corresponding code on-demand. To get the code please contact us via the private helpdesk.

Documentation

Added a quick video guide on SDK Browser:

• Added a set of articles on the C# Component System.
• Updated C# API documentation as well as all related code snippets and usage examples.
• Updated the Syncker Plugin section and Syncker API.
• Huge update of the Migrating to Unigine section for both UnrealEngine and Unity Software users.
• 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.

Notice: UNIGINE 2.11 SDK requires SDK Browser version 1.9.22 or later.

[silent]

reserved

[Ihde.Sascha]

First of congrats to the team at Unigine for the release of the community edition! Nicely done! This should allow more people access to the wonderful world that is Unigine.

Second, will the current Entertainment licenses roll over to the Community Pro license? Just wondering since I can`t find 2.11 in the SDK browser, using 1.9.22 btw.

Keep up the great work.

 

Sascha

[binstream]

All the Entertainment users will be migrated to Community Pro or can upgrade to other editions. The migration will be performed next week, we had some shortage of available resources due to the large amount of work connected with the release and introduction of the Community edition.

The expectation is that there will be more technical specialists joining UNIGINE community indeed.

[yan.xiansheng]

7 hours ago, binstream said:

All the Entertainment users will be migrated to Community Pro or can upgrade to other editions. The migration will be performed next week, we had some shortage of available resources due to the large amount of work connected with the release and introduction of the Community edition.

The expectation is that there will be more technical specialists joining UNIGINE community indeed.

This is an improvement. I advised your salespeople a long time ago to change their authorization strategy. unigine is a great tool and framework. But it looks like the current community version should only be available on the gaming side. Non-commercial in nature. Empowerment Strategies I suggest you take Unity's empowerment strategies seriously. A detailed study of what each licensed version of Unity can do. Reasonably priced products will have a large number of customers, especially individual developers. With more users, I think you can do a lot of other things. Similar to Unity.

The cost of the UNIGINE mandate has led to a number of problems. Few users, resulting in high incubation costs for employers. Finding a professional also becomes difficult. It's a vicious circle, especially now that unreal,unity is so popular. I hope UNIGINE continues to improve and listen carefully to the community. I hope the ungine grows better and better. Currently many youtube users are appreciating the release of the community version.

 

[rohit.gonsalves]

Congratulations to Team Unigine. This is Wonderful release of such a wonderful engine.

Being Unigine Developer since 2008 and watched it being developed from 1.0 to 2.11; I believe this community will now grow exponentially.

A Humble Suggestion to Add Marketplace now as Community Edition is in Place. :-) 

Rohit

 

[binstream]

Asset Store is in the design phase now.

[davide445]

I appreciate the Unigine offer being expanded and hope will be further adopted due to his unique positining on the market.

Some specific doubts regarding the shift from current Entertainment to Community Pro (that I personally didn't like as a naming, to me seems a bit the company with too small funding for doing relevant projects. Being focused on visualization and not sim I suppose something such as "Creators" would have fit better the scope)

- As from linked thread was solved the possibility to customize title and splash screen, now I will need to update to the Engineering license to have the same feature?

- Currently using the Landscape Tool to create construction simulations that will be not sold to customers but used for AI training, again no more available? Can be substituted from the new Landscape Terrain (never tried it so far) for this scope ?

- I have already sent an offer to a tunneling company for the creation a VR safety training where none of the Engineering features will be used, Engineering license was not on the budget, I suppose this is not to be considered mining so can fit inside the Community Plus?

- I have planned a meeting with a couple of companies from both defence and special vehicles which want to create demos, needing to use High Level Vehicle System. Demos as you know are not commercial projects but internal investments.

- I have had also already demos and proposals with energy companies for immersive remote control system, where if approved a first step will be a small POC. We will need still to start from an Engineering licence?

- For an upcoming R&D project we will need to use DynamicMeshes continuosly adding new parts from external created mesh, this is considered part of the Engineering and Sim only Runtime Data import and export capability?

Edited April 11, 2020 by davide445

[binstream]

Please contact your sales account manager on Monday - we will figure out options.

[binstream]

FYI: Build for the Fox Hole demo are not available for download right now. ETA Monday-Tuesday. Releasing on Friday night is hard :(

[eddie-j-l.christian]

So far I am blown away by the engine! Congrats on such a fine job. As I look through things with development in mind, I do wish there were a few options that Indies could actually afford and that were available.

First, I wish the Planetary tools were in this edition. $5995/year is what most Indie Studios have for the entire year as a budget for their total studio. So it is unlikely that small studios will be able to use these tools.

Second, not having networking multiplayer support is the biggest weakness I see in this engine. Give me Photon or the Aether Engine support. Fact is Single Player games have taken a backseat to multiplayer games.

If those things were added and it still ran at a decent frame rate,  this would be the top game engine used by Indies worldwide very quickly.

Edited April 13, 2020 by eddie-j-l.christian

[david.sanda]

Please do not bring Unity forum habits of just asking for things and wanting to pay less to Unigine forums.

Unigine has to be at least somewhat expensive so that the team can keep up an excellent work that they really do. Hundreds of requests such as yours, asking for free things here and there, asking to pay less or nothing might just as easily destroy Unigine, if they give in.

[eddie-j-l.christian]

7 minutes ago, david.sanda said:

Please do not bring Unity forum habits of just asking for things and wanting to pay less to Unigine forums.

Unigine has to be at least somewhat expensive so that the team can keep up an excellent work that they really do. Hundreds of requests such as yours, asking for free things here and there, asking to pay less or nothing might just as easily destroy Unigine, if they give in.

I do not do any such thing. I have used Unity and Unreal for over 10 years. I teach game programming and I am stating some simple facts that students and many Indies need.

Edited April 13, 2020 by eddie-j-l.christian

[demostenes]

14 minutes ago, eddie-j-l.christian said:

I do not do any such thing. I have used Unity and Unreal for over 10 years. I teach game programming and I am stating some simple facts that students and many Indies need.

With this logic I can say, that everybody needs Ferrari, so they must be for free. No, students/indies really dont need planet, they dont even need integrated networking. If they REALLY need, they can integrate some 3rd party solution, no problem. If you really need something, you will do it, or pay for it. If not, well, you dont need it that much.

 

Edited April 13, 2020 by demostenes

[eddie-j-l.christian]

Asking a student to integrate multiplayer... Obviously you never had any students.

[demostenes]

9 minutes ago, eddie-j-l.christian said:

Asking a student to integrate multiplayer... Obviously you never had any students.

Actually I had. We were discouraging students from any RPG/MMO/Networking projects they came with as their semestral work and we were approving only simple (deliverable) projects.  So this is exacly reason, why I am saying, they really dont need that. And you were the one, who asked for that.

Edited April 13, 2020 by demostenes

[eddie-j-l.christian]

6 minutes ago, demostenes said:

Actually I had. We were discouraging students from any RPG/MMO/Networking projects they came with as their semestral work and we were approving only simple (deliverable) projects.  So this is exacly reason, why I am saying, they really dont need that. And you were the one, who asked for that.

Well that is your school. Mine has other plans..

[mark.pizzolatto]

Greetings everyone new to Unigine - welcome.

Please understand something - Unity does stuff one way, UE4 does it another, Unigine must do it differently otherwise it might as well be Unity or UE4.

Next are you looking for a RENDERING engine or a GAME engine - two different things (but is easily confused).

Finally: libraries are great, there is a good chance that networking, or any other feature you might want to add has already been made - just add the library to the Unigine project.
If you are looking for a plug and play system Unity, UE4, etc... might be a better fit.

But realize something - there is no "Perfect" solution, sometimes you need to implement the system yourself (look at what Star Citizen decided to do).
If you are claiming to be a developer - then develop the systems your project needs! If your paying for Unigine then I can see asking for features.

[binstream]

We have offered free Community edition specifically for technology enthusiasts to support creative talents. It has some limitations, but we consider them reasonable. Even with this set of features people can create amazing stuff without paying a penny for a license.

As a privately held commercial company we have no intention to give away everything our team is building so hard for free. We have built a set of even more powerful advanced features and are charging some fee for them, which allows to keep working on the technology.  These features are targeted towards simulation & training industry (UNIGINE Sim) and other industrial enterprise projects (UNIGINE Engineering). In terms of service the customers with paid licenses have the priority as well.

If you want more features - you can pay for them and use them, that' s totally normal workflow.

[david.clay]

Reasonable indeed. Thank you very much for this. All these features plus we can use C# (.NET Core finally making it a real language) and there is even a Community Edition now.

My favorite feature is of course the lighting/rendering but that new terrain! The auto generation of LightMap UVs is going to be a big time saver as well. Plus, thank you for making the VR Template available for C#.

This is very impressive work and an amazing release. I can't wait to start using it and see what my team comes up with. We'll be sure to post in the Showcase as we go along.

[polyk.kristf]

Is the Fox Hole demo available in the Community edition? It looks awesome, I'm very intrested in the vegetation aspect of it. Right now i'm working on a game with a lot of vegetation, i'd love to make my next vegetation-y game with unigine!

Spoiler

 

 

 

Edited April 28, 2020 by polyk.kristf

[binstream]

No, Fox Hole is available in Engineering and Sim editions only.

[ahmad.karami]

10 hours ago, binstream said:

No, Fox Hole is available in Engineering and Sim editions only.

Hello Mr @binstream

I do not see any video demo of Fox Hole(more this video demos is a few years ago) , It is possible Unigine team upload new video demos of Unigine Engineering & Sim for near future (2020)?  

[binstream]

There will be more videos soon, both on the fox hole demo and Engineering / Sim promo reels.

[ahmad.karami]

  

IT IS GREAT Mr @binstream

Advertising videos are a strategic concept, let me make a few strategic points:
1. Schools and universities(collages) with Unigine, probably done in Russia, target the countries of the Middle East, Europe.
2. Video tutorials for C # programming in different languages(English/Arabic/Kurdish/Spanish /Russian/Italian), not everyone, like me, has the patience to read documents, but most users watch videos , Video tutorials are very, very important for all tools in Unigine.
3- Fixing bugs and crashes (low facilities with no or very few bags are much better than high facilities with many crashes and bugs).

 

I believe that Unigine has been created very creatively and its level is very, very high. I have worked with different game engines, Plus Good skills and implemented my projects on these game engines in private and public schools, but Unigine is from a different world and very different and the best.

 

The man's voice in the video tutorial is also very magical and enchanting...

 

Thank you so much for free version