UNIGINE 2.16 Beta

[fox]

Key Changes

• DirectX 12 and Vulkan support (beta).
• Completely revamped window manager.
• Renderer improvements: bloom, motion blur, camera effects, etc.
• Sandworm tool UX/UI upgrade.
• Editor API: Assets.
• Texture brush.
• ROS (Robot Operating System) integration.
• Varjo XR hand-tracking.
• IG improvements for helicopters.
• SDK Browser 2.
• Asset Store.

This release brings you long-awaited double precision in Community edition, Vulkan and DX12 support, a new Texture Editor along with a huge pack of Editor improvements including API for assets management, as well as IG updates, rendering improvements and a lot more.

Beta Disclaimer

This version is NOT FOR PRODUCTION USE, beware. Some changes are not merged into this version, there are known major issues.

Do not migrate your projects to this SDK without keeping a backup copy - some more data format changes might be introduced before the final release. Migration from 2.16-beta to 2.16 is not guaranteed!

UNIGINE 2.16 Beta is intended for use with the new SDK Browser v2 (some features are not supported in the old SDK Browser). If you don't have the new version, please download it and install.

 

DirectX 12 and Vulkan (Experimental)

You’ve asked and waited and now they’re here - experimental DirectX 12 and Vulkan versions of the engine are available for everyone starting from 2.16. One might ask: why waiting for so long, DX12 is there since 2015 and Vulkan came out in 2016? Well, there were reasons for that: 

• Low quality of drivers - it’s no secret that, it is the driver that defines performance and reliability of any graphics API for the end user. Poor support from vendors at early stages, half-baked drivers were ranged from very unstable to almost non-functional (sometimes Vulkan drivers were calling OpenGL commands inside).

• Negative experience of porting AAA games, that suffered from driver problems (occasional freezes, application crashes, unstable behavior, etc.).

• No new libraries, technologies, and tools for DX12 and Vulkan at the beginning.

• Unclear profit regarding performance - neither of these APIs offered any significant performance gain at first (resulting in low motivation to support them).

• Windows7 that we had to support as a lot of our enterprise customers have stuck to using it, and were not so eager to switch (meaning no DX12, as it requires at least Win10).

So, unclear profit, along with high risks and costs (including time) made the whole task impractical back then. Now things changed, both APIs matured along with drivers, and the time has come along with motivation:

• Support for new platforms including consoles (e.g. XBox uses DX12), mobile, etc.

• Both Vulkan and DX12 are low-level APIs that give developers more control, interfere less, and provide direct hardware access with minimum overhead. These APIs offer a significant CPU gain which is critical for many applications as they usually have a CPU bottleneck (managing huge numbers of objects especially complex ones requires a lot of CPU resources).

• Hardware-accelerated raytracing DXR/VKRay (should be noted, that software raytracing was used in UNIGINE long before Vulkan and DX12 appeared) along with other new technologies not available for  DX11/OpenGL, like VRS,  Mesh Shaders, Async Compute, Wave Intrinsics, etc.

• Vulkan is a lot faster than OpenGL which is the only option for Linux (used by many of our enterprise customers). Apart from being slow, OpenGL requires a lot more time and effort to implement the same Engine features developed for DirectX and make them work, which slows down development process.

 

What We Have Now

Vulkan can bring you up to 100-200% CPU and 30% GPU boost, as compared to OpenGL implementation. DirectX 12 - doesn’t offer that much, but it’s still a good plus -  up to 15-60% CPU, as compared to DirectX 11. First we test new versions in our internal projects. 

Vulkan and DX12 versions of the Engine are not production-ready, the job is not 100% complete and some features will be missing in 2.16 for them (like both terrains, volumetric clouds, SRAA, occlusion queries, and support for multiple windows, render API may be unstable).

Missing functionality is currently being added and is to become available in future releases along with bugfixes and improvements. We keep pushing to make the performance even higher or at least keep it comparable.

The Engine is also being ported to game consoles. The Xbox Series X/S as well as the PlayStation 5 version both look almost feature-complete.

 

 

Revamped Window Manager and Engine Integration

UNIGINE Engine supports a large variety of outputs including multi-monitor configurations, panorama, stereo, VR, and so on. Apart from that it supports embedding into various third-party applications  (SDL, WPF, Qt, etc.), meaning that we create a lot of windows to draw on, often with GUI, along with events processing. 

There were multiple unresolved problems with window management, events processing, and graphics context initialization due to multiple integration options and complexity of implementation with functionality duplication. The problems ranged from missing support for specific keyboard layouts (e.g. accents/umlauts) to unmanageable UI input in multi-window applications or inability to use VR in Qt applications, including platform-related and fullscreen issues, etc.

Our roadmap contains a number of large-scale and important features like Node-based scripting, Visual UI editor, Sequencer, and Character animation editor. All of them need a new GUI system, which in turn requires a new Window Manager as basis (free from the imperfections mentioned above). So the main motivation was to create an advanced and reliable toolkit to simplify development of various advanced visual tools for growing number of platforms, with a large palette of widgets and extended capabilities, increasing productivity of our customers, and give this toolkit to them, so they could develop such tools for their purposes themselves.

So, we have completely revamped window management and integration workflow (see details in the sections below). 

The basis is completed, but some related changes are yet to be made in the upcoming releases - we are currently working on making a combination of multi-monitor and projection plugins (Wall, Projection) and combining all VR plugins into a single one along with adding OpenXR support to simplify adding new devices.

Unfortunately, the amount of related API changes is significant, meaning that in case your project uses your own custom implementation of Syncker or some custom multi-display/projection solution, it will have to be rewritten. But this is to be made once and will let you get rid of all imperfections of the old window management system and give you a firm basis in case you plan future development of your tool.

Engine Integration

We have replaced the old CustomApp-based workflow with a new one. A new CustomSystemProxy concept to be used instead of the CustomApp incorporates definition of available functions (windows creation and management, input management, additional functionality like dialogs, clipboard, etc.) along wil all necessary overrides. The functionality of some Engine subsystems is to be defined depending on the set of functions made available by the user. This class forms the basis for the operation of WindowManager, Input, GUI, Displays, etc. A separate proxy implementation is required for each integration environment (SystemProxySDL, SystemProxyQt, SystemProxyWPF etc.).

The new CustomSystemProxy -based workflow  has resolved the following issues: 

• inability to create a window without using platform-dependent code;
• inability to create a separate rendering window without any plugins; 
• code duplication (the same window creation functionality in all applications); 
• inability to control the graphic context as you want;
• only a part of functionality of the main window is available for other windows (GUI, Input, …); 
• inability to obtain information on physical configuration of displays (monitor resolution, main monitor, etc.);
• missing “window” concept and unclear API as a result;

We have simplified our own App* plugins moving similar functionality out and eliminating problems related to integration into applications created on the basis of third-party frameworks (such as inability to use VR in Qt or WPF applications).

Input System

To unify processing of the mouse and keyboard inputs we have extended the Input class. New functionality covers methods that were used for input in the App class. Similar functions are used for mouse input with an ability to control masks for every pressed mouse key getMouseButtonMask() / setMouseButtonMask(). All keyboard keys, mouse buttons and axes have been moved to this class. Input buffer is now used to avoid missing input events at low framerates. Input events can be received as a buffer, you can create user events and dispatch them to the Engine via Input::setUserEvent(). Input event filter is also available enabling you to reject certain input events for the Engine and get necessary information on all input events. This filter is configured via Input::setEventsFilter(). Event filter is also available for WindowManager (see WindowManager::setEventFilter()) enabling you to receive all events for windows coming from the SystemProxy and filter them out.

 

Extended Set of Callbacks

From now on, access to a wide range of input event callbacks is available:

MOUSE, KEY, CODE, TEXT, TOUCH, etc. Text input callback allows getting a symbol in Unicode format. The user is getting an unsigned char, then it is translated into a proper code (for example: If Shift+q is pressed, then we get “Q”, and not just a key symbol).

New Keys and Physical Codes

Apart from keys dependent on the keyboard layout (QWERTY, QWERTZ, AZERTY), physical codes for keys have also been added. You can work with these codes via isCodeDown(), isCodePressed(), and isCodeUp(). This ensures standardization of controls to the same layout for every keyboard type, with the same button opening the console everywhere. Those codes have standard QWERTY layout names. Some new keys have also been added (like KEY_ESZETT, KEY_U_UMLAUT, KEY_O_UMLAUT, KEY_ACUTE_ACCENT, KEY_U_WITH_GRAVE, etc.).

Moreover, paired keys (Ctrl, Alt, Shift, etc) are now separated (LEFT_SHIFT, RIGHT_SHIFT, LEFT_ALT, etc) making it easy to determine any pressed key on QWERTY, QWERTZ, and AZERTY keyboards. Numpad keys can also be obtained depending on the NumLock state.

 

Working with Displays

The new Display class allows getting information about connected displays. You can get the number of screen displays and the index of the main one. With those indices, you can identify their position and size in pixels. Also, there is access to the name and current dpi. Apart from that, there are functions for obtaining available modes for displays. You can get the number of modes and by their index get resolution and FPS.

 

Window Manager

For windows creation, we have added a new EngineWindow class. All operations for creating, removing, and merging windows are performed via this manager. With its help, you can access any window of the app, create and remove additional windows, and stack them.

A set of samples has been added to SDK to demonstrate various aspects of use  ( samples/Api/WindowManager ).

 

Interface Plugin Removed

We have removed the Interface plugin as its functionality has been covered by the updates described above.

 

Sandworm Tool UX/UI Upgrade

Up to 2.16 there were two terrain generation tools in UNIGINE - "In the end, there can be only one!"(c)

The main problem when designing a multi-purpose terrain generation tool is that it is intended to be used by different people, not just GIS-professionals. The previous Landscape tool had a lot of problems in this aspect, with a lot of non-trivial tasks, sophisticated workflow, unclear procedures and mixed naming resulting in many features, functions, and options lost in the UI and never found by some users. The previous iteration of Sandworm had an objective of absorbing Landscape tool’s functionality and therefore had the same weaknesses. Now with most of the functions covered the time has come to redesign the tool with a huge UI/UX upgrade. We have looked at it through the eyes of an average customer, simplified the workflow, reduced complexity of operations, ensured that all necessary things are always at hand, overall making the interface simpler, much more intuitive, and much easier to use.

In addition to redesigning the interface we’ve made grid division available for Vegetation objects (ObjectGrass / ObjectMeshClutter / WorldClutter) generated for landcover masks, splitting large areas of vegetation into smaller grid cells to eliminate artefacts associated with internal precision of mesh-objects, similar to splitting vector objects.

 

Starting from 2.16 Sandworm completely replaces the old Landscape tool.  

 

Improvements for Binoculars

In this release we have also improved the functionality of binoculars and narrow-FOV sensors  by making Landscape Terrain visibility completely independent from the global Distance Scale parameter that affects all other objects, preventing issues with Landscape Terrain’s scale being affected twice. There are some more improvements in this aspect planned to be added in upcoming releases.

Screen-Space Shadow Shafts

Added volumetric screen-space shadow shafts. Shadow shafts (aka light shafts) can be generated in screen space for the Sun and the Moon to simulate the real world effect of crepuscular rays, or atmospheric shadowing of atmospheric in-scattering. These rays can add depth and realism to your scenes. The new screen-space shadow shafts replace the previous implementation, as they affect haze and environment, do not cause excessive darkening of the final image, and work for both the Sun and the Moon.

There are certain limitations for this feature - it doesn't work with water and transparent objects, and there are known issues on multi-display systems as well.

 

Better Motion Blur

The Motion Blur effect now looks more realistic as it correctly applies blur along the edges of moving objects instead of keeping sharp silhouettes. The Neat Silhouettes parameter has been removed with a set of new parameters added (blur radius and number of samples to be used as well as depth thresholds).

                               2.15.1                                        2.16

 

Bloom Improvements

Previous implementation of the Bloom effect had a number of problems:

• The texture used by the Bloom effect was already processed by TAA resulting in damped highlights (reduced intensity of bright pixels, as it is actually TAA’s job).

• On the top of that same TAA with slightly different settings was applied further damping the highlights (which is good for anti-aliasing, but bad for bloom).

• The texture used by the Bloom effect had some issues with sRGB correction removing highlights even more and making the result look even less physically correct.

The new implementation used the frame data before TAA application and uses linear interpolation instead of additive blending. The effect produces a 100% correct result when Temporal Filtering is disabled, but even when it is enabled the loss of brightness is insignificant.

Temporal filtering for the Bloom effect has evolved and can now be called anti-aliasing as it uses an accumulation buffer with jittering. And specular highlights from the Sun on metal have become as bright as they should, while having a correct antialiasing.

Bloom in 2.15.1

Bloom in 2.16

New Runtime Format for Textures

DDS for UNIGINE is an external format, therefore it does not allow us to use our own compression and store additional data for textures. To get rid of limitations and optimize texture management we have developed our own format for texture assets ( .texture ). The .texture format will be used as the default runtime format for texture assets instead of .dds. All runtimes shall be regenerated automatically by the Editor. You can still use DDS if you want (simply set the Unchanged flag for your dds-textures). 

You can convert any image asset to the .texture format via the context menu right in the Editor.

 

Other Engine Improvements

• Added data compression for the Landscape Terrain details.
• Added basic bitwise operations to Material Graph Editor.
• FMOD plugin is now available for Linux.
• Fixed issues with referencing arrays of external structs or classes in components, now everything works as expected.
• Fixed issues with parallel update of dependent and independent nodes sometimes leading to Engine crashes.
• Fixed issues with incorrect overriding Voxel Probes by Environment Probes resulting in inconsistency of ambient lighting in certain cases.
• Added dynamic update for the shadow map used for the Cutout by Shadow feature of dynamic Environment Probes.
• Added a new Distance Scale parameter for Environment Probes to control reflection LODs visibility distance (similar to the Distance Scale parameter of Light Planar Probes).
• Added a separate option to disable far-plane clipping for clouds, as controlling clouds visibility by increasing the far plane distance significantly affects performance (dynamic Environment Probes etc.). This option is available via the render_clouds_far_clipping console command or via the Cutout By Far Clipping toggle in Settings->Render->Clouds->Common .
• Fixed Cast Global Illumination and Bake To Environment Probes options for Object Cloud Layer.
• Fixed issues with rendering of planar reflections in stereo modes (VR), reflections can now be rendered for each camera separately instead of rendering them once for the point between the cameras.
• Fixed a crash on deleting materials created dynamically after loading a world due to incorrect result of checking (whether material belongs to the Engine/Editor core).
• Offscreen mode implementation has moved from a sample to the Engine and is now available via the video_offscreen startup command-line option. The related Offscreen  sample has been removed from SDK.
• Fixed issues with C++ components shutdown ( ComponentBase class) sometimes resulting in Engine crashes.
• Fixed memory leaks in ObjectParticles on OpenGL.
• Fixed depth testing for ObjectGUI , stencils now work as expected.
• Fixed issues with incorrect intersection detection for the Global Water object.
• Fixed issues with incorrect application of changes made to parameters of the Global Water object.
• Fixed an issue with Water Decals being projected onto mesh geometry when the Emission state is enabled.
• When unmounting/mounting a mount point all materials, properties and other resources it contains are properly removed and reloaded.
• TextureCurve has been renamed as TextureRamp for consistency, for more information please refer to the API Migration Guide.

 

UnigineEditor

New Texture Editor

Make your environment unique in a literally one stroke with a rich set of brushes giving flexible control over the look of your props. The new Texture Editor enables you to paint textures of the materials applied to objects directly in the viewport, saving you a lot of time and effort to fine tune every prop to fit the scene and make it look natural, consistent, and exactly as you want it too. The tool is mainly used for painting masks that can be used to blend various materials together, but also helps editing the existing textures: adding details or fixing mistakes. GPU acceleration ensures high performance even when working with 4K textures.

Texture Editor is available when the Texture Paint Mode is selected on the toolbar:

Surface Custom Texture

Added an ability to add a custom texture for any surface of a static mesh giving you a wide range of opportunities for customization, and enabling you to optimize the number of materials while extending visual diversity. For example, instead of tweaking a set of similar materials for different surfaces, you can assign a unique custom texture to each surface and use a single material with the final look depending on the custom texture. You can either assign a unique texture to each surface or use the custom texture from other surfaces. This option is intended for use with LODs having the same UV maps.

A custom texture can be specified for any Static Mesh surface via the Parameters window (see the Surface Custom Texture group). You can paint it with a new Texture Editor and use it in the Material Graph Editor via the Surface Custom Texture node. 

Assets Migration

According to the standard workflow, content of the project is migrated to the newest version automatically via UNIGINE SDK Browser or manually using the upgrade script.

Starting from 2.16, you can also add outdated assets to the upgraded project right in the Editor (when importing a package of assets, dragging an asset to the Asset Browser, or  copying an asset directly to the project's data folder), as it allows upgrading them automatically to the current version of UNIGINE SDK. This functionality is also a part of the Asset Store infrastructure support, ensuring that assets and asset packages you download (which can be outdated) will be updated when you add them to your project via the Editor.

You can control automatic migration settings via the Settings window:

For more information please refer to the related article.

Editor API: Assets

Most likely your custom tools that you develop on the basis of UnigineEditor's functionality will somehow manage assets. For this release we’ve made a convenient asset management API. A new AssetManager class that extends the functionality of the UNIGINE's FileSystem in the UnigineEditor. enables you to check availability of a resource with a specific GUID, get its path, subscribe for the signals to perform certain actions when an asset is added, moved, updated, or deleted, and track assets changes in real time.

For your convenience we have also a sample plugin demonstrating implementation of basic asset management operations using the AssetManager class. It is called Assets Plugin and can be used as a template for your tool. A new article will help you get up and running quick. Information on new classes was added to Editor API Reference.

Evolution of Editor API goes on, so stay tuned.

 

Other UnigineEditor Improvements

• Fixed issues with copying .matgraph files resulting in GUID duplication.

• Fixed issues with refreshing parameter conditions for C# components in case a new  ParameterCondition is set via code after modifying the parameter in the Editor.

• Fixed issues with helpers in the preview.

• Fixed a crash on an attempt to open camera settings after moving a viewport to another display.

• Fixed an issue with creating child materials for graph-based materials via the Asset Browser or the Parameters window.

• Fixed a crash on importing a package (.upackage) containing .obj and .mtl files.

• Added tooltips with clickable links to documentation for nodes used in the Material Graph Editor.

  

• Updated UI layout for Color Correction settings with Sharpness parameters moved from Camera Effects.

• Editor settings are now divided into 2 groups: User and Project settings, the latter ones are applied per-project and stored in a separate file (UNIGINE_PROJECT/data/editor2/settings/unigineeditor.generic.cfg)

  

• Added an ability to reset current animation or playback time for certain nodes (SoundSource, ObjectWaterGlobal, WorldTransformPath, ObjectMeshSkinned, ObjectCloudLayer) to zero when saving a world (current values are restored after saving). This eliminates the problem with large diffs generated by version control systems in case of saving a world after opening it in the Editor and simply playing skinned mesh animations, sounds, or just having particles, water, and clouds simulation enabled (see the corresponding checkbox in Settings -> Editor -> User Settings).

• Fixed an issue with parameters of graph-based materials resulting in changing the look of material after rearranging parameters in the Material Editor.

• Fixed an issue with dependencies when exporting data to a package resulting in ignoring some dependent assets (e.g. ignoring a subgraph used in a graph-based material assigned to an object when exporting a world containing this object to a package.

• Fixed FBX exporting to locations outside the data path.

 

ROS Integration

There are multiple types of robots from vacuum cleaners to autonomous combine harvesters, drones etc. Most of them are made of actuators (things that move), sensors (things that read the world), and control systems (robot’s brain) There is a way to simplify the complex process of making these components work together - Robot Operating System (ROS). It is a set of free and open-source software libraries and tools to help you build robot applications. ROS enables you to build components quick and easily connect them via messages. These messages can be sent to various visualization or teleoperation tools so you can work with a simulated robot instead of the real thing (digital twin). So, with ROS you can build complex distributed systems with multiple nodes for different tasks (controls, image generation, etc.), it supports hardware interfaces for many common robot components like motor controllers, LiDARS, and cameras. The whole framework enables you to focus on implementing your logic, not reinventing the wheel. The list of tasks that can be effectively solved using ROS includes logging and diagnostics, fleet management, deep learning data collection (training), testing & quality assurance, and a lot more.

 

UNIGINE actively moves towards the automotive industry and the world of autonomous systems where ROS is a de-facto standard, so we made ROS integration (ROS2) to simplify processes of building, training, and testing such systems. 

 

For your convenience we have added a new ROS Demo to showcase simulation of the automotive vehicle control via ROS and simulation of sensors (cameras and LiDARs) mounted on the car. The demo is available for SIM edition only and includes several modules (ROS nodes):

• Simulator - renders the simulation and simulates physics (UNIGINE can also be used as Image Generator with physics and vehicle model calculated on separate nodes)

• Teleop - processes the input (control keys pressed) from the user and transmits it to other ROS nodes. To control two vehicles simultaneously you can run two Teleop applications on the same PC or on different PCs in the local network. Another control application (e.g. your own implementation of control system of an autonomous vehicle) can be used instead of Teleop to control vehicles in the Simulator.

The Simulator application sends data from cameras and LiDARs to RViz 3D visualization tool for ROS (included in the original ROS2 package) that renders point cloud visualization based on the sensor data received.

 

The simplified workflow of implementing a robot system using new ROS integration in UNIGINE is as follows 

1. Design your robot, define all sensors and actuators.
2. Implement your robot’s control system.
3. Create a 3D model and implement an entity for your robot in UNIGINE  (and other entities if necessary).
4. Connect your control system instead of the Teleop node.
5. Connect RViz 3D or other visualization tools to process and display the data from robot’s sensors.

In this case you just concentrate on your task - development of control system and implementation of a digital twin for your robot, without having to think about data transmission or write other utility code.

We also plan future development of ROS integration in UNIGINE.

 

Varjo XR Hand-Tracking

Advanced hand-tracking in VR is now available for human-eye resolution industrial-grade Varjo VR and XR headsets. Enabling you to build XR applications realizing their potential to the full extent by using hands naturally instead of some sophisticated controllers.  New functionality is available via our new Ultraleap integration plugin supporting the fifth generation of hand-tracking software (SDK v5.0) with better finger fidelity, two-hand performance, higher tracking robustness and a lot of other improvements.

 

   Image courtesy of Varjo

The C++ VR Sample has been updated to showcase new functionality. 

For more information about the related API changes please refer to the API Migration Guide.

 

Image Generator Improvements

Custom Network Components

Usually, if you need to render a world across several computers synchronized over LAN, you use Syncker. It sends a lot of data each frame from Master to all Slaves. Using Syncker allows for precise image synchronization, however, it is not always necessary. IG Template now provides functionality enabling you to reduce the amount of data to be sent and, therefore, network load. For example, to rotate an object, you can simply send rotation velocity from Master to Slaves once. When implementing the network component, you define data to be transferred over the network and send it only when necessary: you specify methods that can be invoked over a network (i.e. on Slaves) and then call them on Master passing the required data. These methods will be called on Slaves as well.

To create a network component with custom application logic using the IG Template functionality, simply inherit it from the Unigine::Plugins::IG::NetworkComponentBase class. For more information please refer to the Creating Custom Components article.

IG-Aircraft Add-On

To simplify creation of realistic aircrafts in your IG-applications we have added a new  IG Aircraft add-on with a set of ready-to-use aircraft components creating such effects as engine and landing gear fire, smoke, contrail, landing gears, helicopter rotor blade settings with the blurring effect and rotor downwash effect. The add-on also shows implementation of the wheel trace.

The new add-on is available on the Asset Store!

The list of other improvements includes:

• Added support for CIGI Symbols in IG applications.
• Added support for DIS entity marking.
• Added types of lights for ground vehicles as per DIS specification.
• Fixed an issue with disabling entity interpolation (smoothing) when activating CIGI entity ground clamping (conformal and non-conformal).

 

 

Asset Store

You’ve asked, we delivered: the Asset Store is finally here . For now, it’s an experimental version available for our most devoted users: you. We've been working hard to create the asset store and are now ready to grant you early access. UNIGINE Asset Store is used paired with SDK Browser 2.0.1, which is also experimental. For now, only free assets are available in the Asset Store. 

Further development of the Asset Store is in progress and will continue. The next stage expected in October this year is the ability to publish free assets for all users, with monetization functionality for all users (ability to get money for your assets) expected by the end of the year. If you’d like to publish your assets for free use, please contact our support team.

New SDK Browser

UNIGINE is made to help bring your projects to life. Most of your activities revolve around projects, you create, configure, and upgrade them, you also need to have all necessary templates, samples, demos, and additional content at hand. SDK Browser is a hub that connects you to the world of UNIGINE and streamlines all the processes. We’re putting a lot of effort into making all processes as smooth and intuitive as possible and switching to a new technology stack to make the product even more robust and secure.

 

Introducing a new SDK Browser 2 (experimental), completely reworked from scratch, supporting the complete set of features of the previous version with improved safety, robustness, and extended functionality to support additional features. And the cherry on the cake is the ability to minimize SDK Browser to the System Tray.

New SDK Browser 2 is considered experimental, as a set of new features is yet to be added (next stages of Asset Store integration, simplified user registration and a lot more) along with further UX improvements, but it is fully functional and you can already use it to work with your UNIGINE projects starting from version 2.9 and higher.

Here is a quick video guide about working with the new SDK Browser 2:

 

More details on the roadmap for upcoming releases can be found on the official forum.

New browser is available for downloading in the Downloads section.

UNIGINE 2.16 SDK is intended for use with the new SDK Browser v2 (some features are not supported in the old SDK Browser). If you don't have the new version, please download it and install. This release will be the last for old SDK Browser.

Documentation

Added a set of new ultrashort HowTo quick tip videos in English, Chinese, and Russian:

 

Other Documentation Changes

• Updated IG documentation .

• Added a new Texture Editor section.

• Updated Sandworm documentation and added a new Questions & Answers section.

• Added a new article on Managing Assets in Editor Plugins and updated Editor API Reference.

• 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.

[fox]

Known Issues

General

• Projection Configurator window for the Projection plugin is clipped at screen resolutions 1366х768 and lower making it impossible to modify configuration.
• Incorrect operation of the Texture Buffer Auxiliary in the Material Graph Editor on OpenGL.
• Uneven distribution of ObjectGrass along the surface of the LandscapeTerrain on slopes.
• Possible artefacts with shadows in the material preview.
• Issues with incorrect resize of the preview.
• Cyclic streaming of the Landscape Terrain data on low-end hardware at Low streaming preset.
• The Viewport QT sample build failure due to compilation errors.
• The Surround plugin is missing in 2.16-Beta.
• Black empty window appearing when running the Editor/Engine on Linux.
• Engine crash on quitting the application via the Quit button in the System Window.
• Engine crash on quitting the application on Linux with the following error message: BadWindow (invalid Window parameter).
• Closing one window of multi-monitor applications (e.g. Wall plugin) does not close others.
• Multiple warnings and errors in the Console.
• Qt-based projects crash on startup.
• Application is not unloaded from memory on closing a window via Alt+F4 or [X] button in case the background_update option is set to 1.

 

Editor

• Memory leaks on reimporting .dds assets.
• Inability to start editing a Node Reference instance in case another Node Reference instance is being edited.
• Some .tif textures cannot be imported.
• Flowmap drawing in the Texture Editor is not working properly due to shader errors.
• Issues with blinking windows and input handling in the Tracker tool.
• Inability to scroll the contents of the Console using a slider.
• Too short visualizer displaying time on selecting a node.

[ANTEVETY]

Опять для избранных или нет?

[silent]

Бетка доступна для Sim / Engineering пользователей на данный момент.

[christian.wolf2]

The new features are looking very cool and re-design/improving the overall window/display management sounds promising. Because we are currently evaluating an re-design of our applications UX in near future I want to ask, if 2.16 will also implement an new kind of Widget-system or will this be implemented in later releases?

Also, what might be a very handy with display/app-window management is getting access to some functions of the underlying operation system infos. For now, resizing the application window does not considering any taskbar in window mode, which leads to some "unseen" widgets on the bottom of the app hidden by the taskbar.

 

 

[Bartolomeus]

Really, double precision for also for the Community Edition. This is the main reason why I switched from Unity to Unreal not to Unigine. Awesome news, thanks for adding this feature.

[silent]

Quote

 if 2.16 will also implement an new kind of Widget-system or will this be implemented in later releases?

It will be implemented later.

 

Quote

Also, what might be a very handy with display/app-window management is getting access to some functions of the underlying operation system infos. For now, resizing the application window does not considering any taskbar in window mode, which leads to some "unseen" widgets on the bottom of the app hidden by the taskbar.

You mean in 2.16? Can you show us a small video that demonstrates this behavior?

Thanks!

[toster]

а когда состоится релиз UNIGINE 2.16?

[silent]

Планируем успеть до конца лета, но может быть немного залезем на начало осени.

[toster]

5 hours ago, silent said:

Планируем успеть до конца лета, но может быть немного залезем на начало осени.

Понял, спасибо

[charles.dodge]

Awesome deal, downloading it right now for Linux

 

[jose.rentildeones]

Looks great

[Amerio.Stephane]

Hi, I no longer see any indication of the "Planet' feature, or CESIUM integration, and it also disappeared from the roadmap. What's exactly the plan? (we can discuss this matter in private if you prefer, but this is highly concerning to us).

[binstream]

14 hours ago, Amerio.Stephane said:

Hi, I no longer see any indication of the "Planet' feature, or CESIUM integration, and it also disappeared from the roadmap. What's exactly the plan? (we can discuss this matter in private if you prefer, but this is highly concerning to us).

We are working on the updated roadmap now.

As for this feature, there are some external factors which require re-assessment of the current approach. We have some open technical questions which we would like to discuss in-depth with our key customers, so let's arrange a conf call on that.

[Lales.Charles]

Hi,

When starting on a new project with IG template, you do have a bunch of warning "unused argument" at loading materials step.. is it normal?
A way otherwise to avoid it?

Regards,
Charles

[silent]

Hi Charles,

That's fine, beta is not intended for production use. These warnings would be fixed in the final release.

Thanks!

[toster]

I apologize for such a question, but how long to wait for UNIGINE 2.16. I just want to try