When to Use Level Instance, Packed Level Actor, or ISM/HISM in UE5

Development World Creation
, ,
1

Hi,

We’d like to understand what the standard level workflow looks like in Unreal Engine 5.

After upgrading to UE5, we noticed that new concepts such as Level Instance and Packed Level Actor have been introduced. However, we’re still unclear about how these relate to the traditional ISM/HISM systems and how they are intended to work together.

For example, ISM and Packed Level Actor appear to serve similar purposes, and we’re not entirely sure when each should be used, or what their key differences and appropriate use cases are.

At the moment, we find the usage conditions of ISM, HISM, Level Instance, and Packed Level Actor in UE5 somewhat ambiguous.

Could you please provide a detailed explanation of the respective use cases for ISM/HISM, Level Instance, and Packed Level Actor in practical production workflows? Also, does the Packed Level Actor have any specific advantages over ISM?

2

Hello!

Level Instances are a way to group related actors that will be used multiple times in the world. Things like bus stops, rock formations, house with their interiors… LIs can be built using StaticMeshActors as you would do for a regular level. The Packed Level Actors are an optimized form of a LI where the entire content of the level is grouped under a single Blueprint. Meshes that are instanced multiple times in the LI will be grouped using ISM for better memory usage and higher rendering performance. https://dev.epicgames.com/documentation/en\-us/unreal\-engine/level\-instancing\-in\-unreal\-engine

You will want to pay attention to the Runtime Cell Transformers which allows to transform the content of the generated cells (sub-levels). The first RCT (in 5.5) gathers instances from immutable (unreferenced and static mobility) meshes under a single actor and multiple ISM components. This reduces the UObject count and optimize each cell to use batched rendering as much as possible. Version 5.6 introduces the FastGeo plugin that goes further and use a lighter construct to manage the immutable mesh instances at runtime instead of the classic Actor\Component combination. The RCTs are non-destructive so that artist can keep on populating the levels as they are used to.

Regarding ISM vs HISM, the main difference is now related to the type of StaticMesh that they are referencing. ISMs should be used for Nanite meshes while HISM should be used for regular (non-Nanite) meshes. Nanite rendering is moving occlusion and culling to the GPU which makes the clustering of HISM irrelevant and a waste of CPU time in the end. That being said, the RCTs are greatly reducing the need to generate them while editing the WP level.

We have this fairly old video where my colleague went over the World Partition system and it’s different new features before the release of Unreal 5.0: YouTube

Lots of the discussed information is still relevant today and this makes a good start in your journey to learn UE5.

I also recommend reading the World Build Guide article. This is the most up to date source of information on anything related to building large worlds in UE5. We update with every new release of the engine to ensure that the ever evolving best practices are shared with the users. https://dev.epicgames.com/community/learning/knowledge\-base/r6wl/unreal\-engine\-world\-building\-guide

Regards,

Martin

3
  1. You assumptions are in line with our current recommendations. As a precision, PLAs are created from LevelInstance but they only contain visual elements
  2. ISM vs PLA.
    1. ISM: This usually relate to the InstacedStaticMeshComponent which can manage multiple instances of the same mesh in an optimized way
    2. PLA. A PackedLevelActor is a blueprint generated from a LevelInstance where all meshes are grouped under the PLA root using StaticMeshComponent and InstancedStaticMeshComponent.
  3. The foliage system is based on classes that derivates from HierarchicalInstancedStaticMeshComponent. You can\should still use the system as is for now.
  4. FastGeo: I recommend starting with the default settings. The plugin does have internal inclusions and exclusions that you can review in FastGeoStreaming.ini. Those are the types that we have tested when the plugin was developed. The plugin will destroy Actors whose components have been fully “collected” so they will not exist at runtime. This can indeed have incidence on gameplay logic. The plugin will exclude automatically BP with logic and Actors that are directly referenced by other Actors. You can tag important actors with “NoFastGeo” so they are rejected and will stay alive in the runtime.
  5. The StaticMeshes that are managed by FastGeo willl still be hit by line traces. I recommend opening a new case with a project that demonstrate the problem if you need more help on this.

Regards,

4
  1. A PLA is built from a LevelInstance and can be updated when the LI is changed. One of the main benefits is that LIs can use actors which is easier to manipulate. On the runtime side, it’s fairly equivalent as both use the same component in the end.
  2. FastGeo is a new plugin and considered experimental. It was developed in the context of the Witcher 4 demo we recently released and was aslo valided with the CitySample. It is not recommend to try to convert all AActor at this point. Using the default configuration is the recommendation at this point. You can download the 5.6 version of CitySample if you want an example of its usage.
  3. Yes, you are correct Regarding line traces, it is possible to trace the FG instances but it is not possible to manipulate as stated in the case you shared.

The goal of FastGeo is to reduce the number of UObject in the system by converting the mesh instances that are not interactable (other than collision). Instances that are to be affected by gameplay should stay as regular Actor in the levels.

5

Thank you very much for your reply!

1. Regarding the difference between Level Instances and Packed Level Actors, my understanding is that Level Instances are more suitable for creating POIs (Points of Interest).

They are also ideal for standalone sublevels that include gameplay logic.

On the other hand, Packed Level Actors are better suited for purely decorative content that does not contain any gameplay functionality.

Another difference, as far as I understand, is that PLAs can only contain Static Meshes, whereas Level Instances can include all types of content.

Could you please confirm if my understanding is correct?

2. I also wanted to ask, what is the difference between ISM and Packed Level Actor (PLA)?

In our development, we often notice that some meshes are merged using ISM, while others are merged using PLA. Our developers are not quite sure what the actual difference is, so they tend to mix both methods. We would like to understand when ISM should be used, and when PLA is the better option.

3. Regarding the HISM part, you mentioned that HISM has become less important. However, for vegetation, we should still be using HISM, right? I noticed that foliage is still inherited from HISM. Will the upcoming Nanite Foliage use ISM instead of HISM?

4. Regarding FastGeo, there does not seem to be much documentation available. We tried using it briefly and attempted to add some Actors into the FastGeo list, but after the merging process, many gameplay-related logics started to break. It seems that directly including AActors into FastGeo causes issues with gameplay functionality.

[Image Removed]We would like to understand how Runtime Cell Transformers ISM and FastGeo are configured in FN.

5. Additionally, we found that FastGeo also seems to have issues when dealing with Static Meshes. For example, after a Static Mesh is processed by FastGeo, line trace detection (LineTraceByChannel) no longer works correctly, and the HitResult always returns Null.

6

Hi,

Thank you very much for your reply.

1. Regarding ISM and PLA: from a practical standpoint, there does not seem to be much difference between them. ISM is not limited to merging identical objects into a single ISM; it can also combine different meshes into one ISM, where each mesh generates its own InstancedStaticMeshComponent. This appears to work the same way as PLA.

[Image Removed]What we are mainly confused about is when we should use ISM and when we should use PLA. Since their functionalities seem quite similar, it is difficult for us to clearly distinguish the proper use cases for each.

2. Regarding FastGeo, if I understand correctly, you mean that it’s not recommended to directly add AActor to the Allowed Actor Classes, right?

3. When you say to mark important Actors as NoFastGeo, does that mean setting it in the Actor Tag property?

[Image Removed]It seems that this is more flexible compared to the Disallowed Actor Classes option in the World Settings?

[Image Removed]For example, with the same Actor class, I could allow one instance to be included in FastGeo and another to be excluded.

Is my understanding correct?

Regarding the FastGeo Line Trace issue, I found that someone has already asked about it.

[Content removed]

7

Got it, thank you very much for your explanation.

However, regarding your statement that FastGeo goal is to convert meshes that don’t require collision detection, I feel that this design isn’t quite reasonable.

For many games, nearly the entire scene needs to have collision information. For example, in shooting games, objects that are hit must provide physical feedback and trigger corresponding particle effects. Many action games also have similar requirements.

Since Fortnite itself is a shooting game, it should have the same needs. If collision detection isn’t supported, it’s hard to imagine how the FastGeo workflow could be properly utilized.