This tutorial is intended for users who have an existing scene that is not performing well due to too many assets being loaded at once. The performance issues may be presenting while working with the scene in the Editor, in Play Mode, or in a build (or all three).
With that said, if you do not currently have such a scene but would still like to work through this tutorial, you can download the Samples Package (v2) and use the scene called 5_Pre_SAM_Example_Scene, which can be found in the Assets/Deep Space Labs/SAM/Samples/SampleScenes/BasicConcepts folder. We will reference this scene as the Sample Scene within this tutorial.
Whatever the case may be, this tutorial will guide you through the process of taking the objects in that scene and converting them into Streamable Asset Chunks, which can then be used by SAM for more efficient loading both in the editor and in Play Mode or a build.
This tutorial assumes that you have already worked through the Getting Started Tutorial Chapter, as most of the game objects/components/scriptable assets you create/add to the scene in that tutorial are needed in order to proceed with the scene breakdown.
Please do not skip that tutorial (especially if you are using the Sample Scene, as this tutorial will be very confusing if you do! If you haven't already, complete that tutorial and return to this Chapter/Section afterwards.
For certain types of Assets, the steps outlined in this tutorial may not be needed. These include:
1) Unity Terrain
2) Ground Meshes
3) Other Game Objects that cover large areas of game space
These game object can usually be converted directly to Asset Chunks by simply making the game objects into prefabs (by dragging and dropping them into a folder of your Project Hiearchy), or scenes (using the Scene Generator asset after making the game objects into prefabs).
The choice is yours, however, and you can choose to use this tutorial to convert these assets to Asset Chunks if you desire. In some instances (such as if the assets do not follow a uniform naming convention) it may be easier to use this tutorial rather than converting the assets directly to Asset Chunks.
Smaller Assets that are abundant in the scene, as it makes sense to group these objects together under common Cell specific Asset Chunks.
--For example--
Imagine you have a bunch of grass game objects, with each one containing a few quads. There would likely be 1000's of these grass objects in your scene. If we were to create a separate Asset Chunk for each grass, the number of Asset Chunks would grow out of hand very quickly.
Instead, it makes more sense to group similar assets/game objects together under a single parent game object, which in SAM serves as the Asset Chunk. With this tutorial and with the aid of the World Designer Tool, this process is automated to make the grouping of hundreds if not thousands of individual game objects into Asset Chunks as simple as possible.
Your scene is likely a complicated combination of different assets, from small rocks, plants, and grasses to larger trees, houses, and other structures.
These different assets will likely require different loading strategies and configuration settings. For instance, a tree may be viewable from a far distance, while a grass might only be noticeable to the Player when they are standing right next to it.
When you group objects under a single Asset Chunk, those assets are bound together. When one is needed, the other has to be loaded, and vice versa. The consequence of this rule should be obvious, however we will state it anyway: Only group assets/game objects together if they should be loaded together!
The primary criteria for determining if two assets/game objects can be grouped together should always be the size of the assets, or more specifically, the distance from the player at which it makes sense to load the asset. If you group a large tree and a small grass object together, the tree will need to be loaded at a far distance from the player, and the grass will come along for the ride. This is very inefficient, as the grass will likely not be viewable at the same distance as the tree.
With that said, size is not the only criteria. Here are some others (though note this list is not 100% complete! You may think of other criteria to use, which is just as valid):
1) Memory Footprint - If you group assets with vastly different memory sizes together, it can be hard to predict the impact on memory/RAM that each Asset Chunk will have. This can make it harder to pinpoint which Asset Chunks are using too much/too little memory later down the road.
2) Performance Footprint - Activation/Deactivation and Main Frame Integration/Destruction of game objects carry performance penalties. Groupings similar assets together makes it easier to reason about the cost of these operations on a per Asset Chunk basis, which will make optimizing your game down the road easier.
3) Pooling - Assets Grouped together will utilize the same Chunk Manager, which among other things, is responsible for making decisions about whether the assets are pooled for later use. It can make sense to divide assets into different groups based on whether you think you will need to use them with a pooling system.
4) Streaming Mechanism - How the Assets are streamed into and out of the scene is also an important consideration. You may wish for some assets to be represented by prefabs, some by scenes, and still others by the Addressable System. Assets grouped together are locked into using the same Chunk Streamer/Streaming Mechanism.
5) Tags/Layers - Asset Chunks (and their children) can be assigned tags and assigned to layers at runtime, which is a powerful feature. Assets should only be grouped together when you want them to use the same tags/layers (assuming you are using this feature).
6) LODs - SAM's LOD system requires that for each Streamable Cell, at least one Asset Chunk exist for each defined LOD Group. In general, it is easier to satisfy this requirement if you group assets together only if they have the same number of LODs.
7) World Grouping Listener Requirements - Listeners are assigned on a per World Grouping basis and will generally be more efficient if they can operate on the Asset Chunks belonging to their assigned Grouping in a generalized way. If a Grouping contains a mix of assets, it's likely the Listener will have to pick through the Asset Chunks child objects to find the objects it wants to operate on, making it less efficient.
In relation to SAM, the determination of which Assets can be grouped together is not just theoretical. It has physical consequences, and for each logical grouping you have determined to be necessary, separate Scriptable Assets and World Groupings are needed.
As such, you can consider the remainder of this tutorial a guide on how to setup a single grouping of assets. For each grouping you need, you will need to repeat the steps outlined in the following Sections!