rdInst Basic Concepts


There’s a few concepts about rdInst that can be handy to know right from the start.

First off, let’s assume you have a basic understanding of Instances and how to use them from an InstancedStaticMeshComponent (ISMC) or Hierarchical Component (HISMC). If you’re just wanting to let the Auto-Instancing handle everything, you don’t really need to worry about these concepts unless you’re wanting to make Proxies and/or SpawnActors.


Singleton Instance Manager

The first concept is “Singleton Instance Manager”. This is what rdInst employs – it’s a single set of ISMC/HISMC’s containing all instances for a mesh in the entire level. This dramatically reduces draw calls and Component Setup costs – and also allows for a centralized recycle system for very fast instance spawning.


Instance (ISMC/HISMC) and Actor Instance identification

The second concept for rdInst is how to identify an Actor and/or its instances, or an ISMC/HISMC handler and instances within it.

There are 2 ways:

  1. For Instances, a reference to the mesh asset can be used. This has been the default way up until version 1.50. When wanting to process an instance in some way, you pass in the “StaticMesh” reference and the “Instance Index” – the index is the same as the ISMC/HISMC instance index, so things like Collision hits can be used directly.

  2. A “sid” – this is a string (Name) based ID which describes the StaticMesh along with SpawnType, Material overrides, Reverse Culling switch, collision type and ID – or an Actor along with its scene instance properties. Each “sid” is an independent ISMC/HISMC for instances.

All Instancing routines in rdInst accept either a “StaticMesh” as the id, or a “sid” – the routines are identical to call, except the routines that accept a “sid” are suffixed with an “X”.

e.g.


rdInst Proxies

rdInst uses a proxy system for swapping objects when close to the player.

Unlike the traditional Proxy type, which refers to a low-poly object far off in the distance, a rdInst Proxy is the high-res, interactable object that’s swapped close to the player. Instances are displayed when further away from the player. These instances can have collision turned off, and VSM invalidation set to static to keep rendering speeds up.

A Proxy can be attached to any StaticMesh – you can assign one to a specific instance, or every instance of a mesh.

The Proxy can be a full Actor such as a Blueprint containing interactive code, a DataLayer (if WorldPartition is enabled) or another StaticMesh.


rdInst SpawnActors

A SpawnActor is basically that – it spawns things – instances, actors and VFX. They can spawn at play, or spawn when the player comes within a radius. The object assets and transform data are not loaded until needed, and can be freed when hidden to keep memory usage optimal. All data is pre-calculated in the SpawnActors DataAssets including spatial collation and the spawn and process threads all access them directly.

The Spawn DataAssets are optimal in disk-size and CPU memory consumption too – in an initial test, 5,664 actors, comprising of Meshes, BPs, Lights and Decals packed down to 2.164MB (not including textures and meshes). This helps reduce disk streaming and processing times by large amounts in itself.

These DataAssets are optionally relative to their SpawnActor containers and can be re-used in the level as many times as desired.

Once the Mass-type movement system is implemented, the plan is to save copies of the DataAssets containing NPCs for each game slot, making it easy to have all entities return to their last-played locations and states.

There are various modes for populating the stored objects – any object can be customized to have its own population type, or it can use the default type for the SpawnActor – they can be all, always visible, all spawned when the player comes within a specified distance, A Local mode where only a sphere around the player is spawned, removing and reusing objects that fall out of the sphere, and a View Frustum mode which maintains the objects within the players View Frustum, removing and reusing objects that fall outside that area.

There are different types of Mesh Spawning too – they can be spawned as physics capable components, instances, Niagara meshes or actors – coming soon will also be rdMeshlets and Componentless Meshes.

The SpawnActor is the base for population Actors to SubClass off – by itself, it’s a fast BakedData spawner, proximity scanner and the beginnings of an ecs type mass system. The Subclasses are in charge of working out where to spawn and what object – the SpawnActor is in charge of getting them onto the screen fast, and scan fast for proxy changes.

They can also be populated by PCG scripts.


rdPickups

rdPickups are fully interactable PickUp objects which you can easily create just by setting a few options on the Asset from the Content Browser, or directly on Actors in the level. They support highlighting with powerful customizations, communicate with your player by way of some Delegates and can be set to respawn.