API Migration

Previously, procedural mesh modification in static meshes followed a straightforward but limited workflow:

1. Enable procedural mode
2. Assign a new mesh
3. Apply changes

While simple, this model had constraints that could introduce significant issues in practice.

For example, streaming was not supported for procedural meshes, so they had to be constantly kept in memory. In complex scenarios with large or numerous procedural objects, this could lead to excessive RAM and VRAM usage, and in some cases, even application crashes.

To overcome these limitations, we've significantly extended the procedural mesh API and introduced multiple procedural modes, each optimized for different performance and memory characteristics. These modes allow you to fine-tune behavior: whether you need ultra-fast updates for a small number of objects or efficient memory use via RAM-backed or disk-backed streaming.

Please note that selecting a procedural mode directly impacts streaming and memory usage (RAM, VRAM, and disk). Be sure to understand the details before making your choice.

ObjectMeshStaticPtr my_static_mesh;
// ...

// Enable procedural mesh mode for this static mesh object
my_static_mesh->setMeshProceduralMode(true);

// Update the mesh geometry using the provided source_mesh
my_static_mesh->applyMeshProcedural(source_mesh);

ObjectMeshStaticPtr my_static_mesh;
// ...

// Choose one of the appropriate procedural modes
// DYNAMIC, BLOB, FILE or DISABLE
// For example, FILE - for streaming from disk
my_static_mesh->setMeshProceduralMode(ObjectMeshStatic::PROCEDURAL_MODE_FILE);

// Update the source mesh of the "my_static_mesh" object via the source_mesh instance
// More options are available, pick the best for your needs
my_static_mesh->applyMoveMeshProceduralAsync(source_mesh);

For more details on configuration and best practices:

• Refer to the updated Procedural Mesh Workflow.
• See the following classes: ObjectMeshStatic, ObjectGuiMesh, DecalMesh, ObjectMeshCluster, ObjectMeshClutter
• Check out the new Mesh Modification and Mesh Generation samples available in both C++ and C#

To improve code safety and consistency in C++ workflows, a wide range of engine objects now have const-qualified versions.

It allows to explicitly mark references as read-only, ensuring that non-const methods cannot be called on them. This helps improve code clarity, prevent accidental modifications, and enforce stricter API contracts at compile time.

XmlPtr xml = Xml::create();
xml->addChild("Node");					// OK: XmlPtr allows modification

ConstXmlPtr const_xml = Xml::create();
const_xml->addChild("Node");			// Error: cannot modify through ConstXmlPtr

The AsyncQueue class has been expanded to support explicit task scheduling across multiple threads.

Each task can be assigned to a specific thread type (FILE_STREAM, GPU_STREAM, BACKGROUND, etc.), giving you precise control over where and how your logic runs. Each task can be assigned relative prioritiy, enabling dynamic balancing of workload under high concurrency. This is especially useful for scenarius involving:

• Asynchronous file I/O
• GPU-side resource initialization
• Custom logic that should not block engine threads
• Parallel computations

See the new AsyncQueueTasks and AsyncQueueStress samples available in both C++ and C# to explore the updates.

A comprehensive set of atomic and synchronization primitives is available to ensure thread-safe execution. These include standard mutexes, recursive locks, spinlocks, and a variety of low-level atomic types. The system supports both automatic (context-aware) synchronization behavior and manual selection of locking strategies, giving developers full control over memory consistency and contention management.

New Functions

New Functions

New Functions

New Functions

New Functions

New Functions

New Functions

New Functions

New Functions

New Functions

New Functions

New Functions

New Functions

New Functions

New Functions