Systems

This sample shows how to load resources like meshes and textures in the background using the AsyncQueue class. Files are loaded in a separate thread, so the main application stays responsive.

Meshes and textures are added to the loading queue, and the system listens for events to know when each resource is ready. When a mesh finishes loading, it's removed from the queue. For textures, an event handler is used to handle their completion. The sample also demonstrates how to group and manage resource requests, making it easier to control the loading process.

This kind of async loading is useful for streaming large levels, loading assets on demand in VR, or preloading data in simulations without freezing the interface.

This sample demonstrates how to asynchronously load large number of nodes using the AsyncQueue class while ensuring correct activation on the main thread.

In UNIGINE, world nodes must be created only from the main thread. To comply with this restriction and avoid blocking the main thread, the sample performs the initial node loading in a background thread, and then schedules a follow-up task on the main thread to finalize activation by calling updateEnabled() - a method that registers the node and its children in the world's spatial structure.

With the built-in Profiler enabled, you can observe how the engine handles increasing load smoothly and avoids frame spikes.

Refer to the AsyncQueue class API for detailed information on available execution modes, thread types, and priorities.

This sample demonstates how to schedule and run different types of tasks using the AsyncQueue class. It shows how to execute operations in different thread types, control thread count, and choose whether tasks should complete within the current frame or run freely in the background.

• Async - non-blocking execution in a single thread. Useful for offloading tasks without stalling the main thread.
• Async Multithread - parallel execution across multiple threads. Each thread receives its own portion of work. Does not block the caller.
• Frame-Async Multithread - same as Async Multithread, but ensures all threads complete their tasks within the current frame.
• Sync Multithread - multi-threaded execution that blocks the calling thread until all threads finish.
• Frame-Sync Multithread - same as Sync Multithread, but ensures all threads complete their tasks within the current frame.

Refer to the AsyncQueue class API for detailed information on available execution modes, thread types, and priorities.

This sample demonstrates how to use abstract classes in the C# Component System to implement common behavior across different components.

At the core of the sample is the abstract Toggleable component, which defines a shared structure for enabling and disabling functionality. It contains the Toggled property that automatically calls the On() or Off() methods when changed. These methods are abstract and must be implemented in each derived class. The Toggle() method is used to switch the state manually, applying the corresponding behavior and updating the internal state.

Two specific components, Lamp and Fan, inherit from Toggleable and implement their own versions of the abstract methods. Lamp controls a light source by toggling its emission material state, while Fan continuously rotates the object when active.

The Toggler component performs interaction by casting a ray from the camera when the left mouse button is pressed. If it hits an object with a Toggleable component attached, it toggles that component's state.

This setup is useful for scenarios where different types of objects need to respond to a common interaction pattern. Using abstract classes makes it easy to implement consistent logic across objects while still allowing each one of them to behave differently.

The example demonstrates possible variations of component parameters.

Select the component_parameters Node Dummy in the Editor and check the parameters window.

It will contain all types of parameters.

This sample demonstrates how to interact with the engine's built-in console and add custom console commands and variables via API using the Console and ConsoleVariable classes.

It shows how to define different types of console variables: ConsoleVariableInt, ConsoleVariableFloat, and ConsoleVariableString, and how to register custom console commands. Commands are linked to callback functions using MakeCallback, and can be executed directly from code or entered manually through the console.

Commands can also be added and removed dynamically at runtime, making the system flexible for various use cases. Console variables can be accessed or changed through both code and the console interface.

This can be used for development, debugging, rapid prototyping, and runtime adjustments in interactive applications.

This sample demonstrates advanced ways of subscribing to events in UNIGINE: using extra arguments, discarding parameters, and storing connection handles for disconnection.
SDK Path: <SDK_INSTALLATION>data/csharp_component_samples/systems/events_advanced

This sample demonstrates how to create a custom data package using code and use it to generate objects in the scene.

Package is a collection of files and data for UNIGINE projects stored a single file. The Package class is a data provider for the File System. You can use it to load all necessary resources.

The ExternalPackage class describes the generation of a mesh (in this case, a box) and its saving to a temporary file at a specified path. The class also implements an interface for searching, reading, and retrieving information about files within the package.

The ExternalPackageSample class adds the created external package, and its contents are used to create meshes with different positions and orientations. This approach allows for quick and convenient management of a large number of objects without adding them by hand.

Packages can be used to conveniently transfer files between your projects or exchange data with other users, be it content (a single model or a scene with a set of objects driven by logic implemented via C# components) or files (plugins, libraries, execution files, etc.).

Using this example will help you understand how to organize work with external files, create and manage your own data packages, implement a mechanism for loading and reading data from a package.

This sample demonstrates how to render a simple 2D shape using the Fixed Function Pipeline (Ffp) in UNIGINE via the C# API. A colorful figure composed of 16 vertices is drawn directly on screen using orthographic projection.

The rendering logic is called every frame by hooking into the engine's render loop. Ffp mode is enabled for drawing and then disabled, keeping this rendering isolated from the rest of the frame.

This approach is useful for quick visualization overlays, editor tools, or debugging tasks where shader-based rendering isn't required.

This sample shows how to procedurally generate 3D image data and use it as a density texture for a volume-based material in real time.

The result is visualized using a volume box that updates dynamically every frame based on custom field simulation.

The sample initializes a 3D image with a predefined resolution and fills it with voxel data derived from a set of moving fields. Each field represents an abstract spherical influence zone that contributes to the voxel density based on distance. Field dynamics are updated every frame to simulate motion.

The raw image data is accessed directly via a pixel pointer and modified per frame, with density values mapped to RGBA channels. The resulting image is then uploaded to a material as a 3D texture used in a volumetric shading model.

The sample demonstrates how to work with the Image class and update GPU resources efficiently at runtime. This approach can be used for generating volumetric effects such as clouds, fog, or procedurally driven visual phenomena.

This sample demonstrates methods for tracking performance and estimating the time spent on different sections of code. For this purpose, it uses Microprofile, an advanced CPU/GPU profiler with per-frame inspection support.

Profiling is crucial for identifying performance bottlenecks and optimizing code execution. This analysis helps you understand if any code sections negatively impact the project's speed.

This sample demonstrates the correct order of operations for modifying and applying procedural mesh data at runtime. It serves as a minimal example showing how to build geometry, configure procedural mode, and apply changes to an ObjectMeshCluster. The same workflow and apply methods are also available for other objects that support procedural meshes, such as ObjectMeshStatic, ObjectGuiMesh, DecalMesh, and ObjectMeshClutter.

Inside the component's code, you'll find a linear implementation of the procedural mesh pipeline, demonstrating how geometry is generated and applied in the correct order.

Use this sample to understand the basic flow of procedural mesh updates and try adjusting configurations to find what best suits your needs.

Refer to the Procedural Mesh Workflow article for more details on memory behavior, update strategies, and best practices when working with procedural geometry.

This sample demonstrates how to generate static mesh geometry at runtime using different procedural mesh generation methods. A grid of ObjectMeshStatic objects is created, each receiving its geometry from a user-defined callback that builds a box-shaped mesh surface via the Mesh API.

You can experiment with various procedural modes (such as Dynamic, File, or Blob), as well as configure how geometry is stored and accessed by selecting different MeshRender usage flags (DirectX 12 only). These flags determine whether vertex and/or index data is kept in RAM instead of VRAM, allowing the GPU to render directly from system memory.

• Dynamic - fastest performance, stored in RAM and VRAM, not automatically unloaded from memory.
• Blob - moderate performance, stored in RAM and VRAM, automatically unloaded from memory.
• File - slowest performance, all data stored on disk, automatically unloaded from memory.

The Field Size parameter defines how many mesh objects are generated along each axis, forming a square grid.

For each configuration, the sample shows total RAM and VRAM usage, along with the number of active mesh objects. This makes it easier evaluate the performance, memory layout, and behavior of each procedural mode in different runtime conditions.

Use this sample to understand how procedural mesh generation works across different modes, observe how geometry is stored and managed between RAM, VRAM, and disk, profile memory usage for small versus large number of procedural objects, and explore how update strategies influence performance.

Refer to the Procedural Mesh Workflow article for more details on memory behavior, update strategies, and best practices when working with procedural geometry.

This sample demonstrates how to dynamically generate, modify, and apply procedural geometry at runtime using different procedural mesh modification methods.

The dynamic surface mesh being built and animated over time using trigonometric functions. The geometry is rebuilt each frame depending on current configuration.

You can experiment with various procedural modes (such as Dynamic, File, or Blob), as well as configure how geometry is stored and accessed by selecting different MeshRender usage flags (DirectX 12 only). These flags determine whether vertex and/or index data is kept in RAM instead of VRAM, allowing the GPU to render directly from system memory.

Additionally, you can choose whether mesh generation occurs on the Main thread or in the Background, giving you more control over performance and responsiveness during updates.

• Dynamic - fastest performance, stored in RAM and VRAM, not automatically unloaded from memory.
• Blob - moderate performance, stored in RAM and VRAM, automatically unloaded from memory.
• File - slowest performance, all data stored on disk, automatically unloaded from memory.

You can also toggle between different update modes (Async or Force), choose memory transfer strategies (Copy or Move), and optionally enable manual control of the MeshRender, where you update its content explicitly after modifying mesh data, instead of relying on automatic updates. Additionally, collision data can be generated explicitly after geometry modification, as it is not created automatically.

Use this sample to understand how procedural mesh modification works across different configurations and explore how update strategies influence performance.

Refer to the Procedural Mesh Workflow article for more details on memory behavior, update strategies, and best practices when working with procedural geometry.

This sample showcases integration between C# and UnigineScript by registering external C# functions that manipulate UnigineScript array types.

The registered functions allow for setting and getting values, generating test data, and enumerating the contents of both ArrayVector (indexed container) and ArrayMap (associative container).

This sample demonstrates how to call UnigineScript functions from C# code via callbacks.

The mechanism is based on Variable Class instances and allows calling both custom and built-in script functions by name.

The sample registers a C# wrapper function to expose script invocation capability to UnigineScript via the Interpreter class.

This sample demonstrates how to work with different variable types in UnigineScript using the Variable class from C# code.

Various types (int, long, float, double), and vector types (vec3, vec4, dvec3, etc.), are wrapped in Variable objects and passed into a UnigineScript callback function.

This sample demonstrates the full range of features provided by the Visualizer class for visual debugging.

The sample illustrates how to use Visualizer for debugging node positions, physics vectors, bounding volumes, and custom geometry in both world space and screen space. Use controls to explore the area.

VisualizerUsage.cs renders a wide range of primitives including points, lines, boxes, frustums, spheres, capsules, and object bounds using Visualizer methods.

2D visualizer features can be toggled on and off via the corresponding checkboxes.

Enable or disable depth testing, toggle specific primitives, and inspect how different rendering options behave in real time.

This sample demonstrates how to create and manipulate an XML document using the Xml class.

The sample creates a nested XML tree with multiple child nodes, each containing arguments and optionally a text value. The structure is built using the Xml::addChild() method, and the arguments are parsed using Xml::getArgName() and Xml::getArgValue(). After construction, the XML tree is traversed recursively to display the structure and all attributes in the console output.

This approach demonstrates the use of the Xml class for working with hierarchical data, which is useful for config files, level data, and other structured content in XML format.