I have a scene that is not running well in the Editor and/or Play Mode/Builds . . .
Great! You can work through this tutorial using that scene.
I don't have a scene but am interested in the process . . .
Download the Samples Package 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 and instructions intended for you will be marked by Sample Scene Instructions within this tutorial.
I am a MicroVerse user . . .
Use your own MicroVerse scene or (if you don't have one) the 2x2 Demo Scene found in the MicroVerse Demo Module. Instructions intended for you will be marked as MicroVerse Instructions within this tutorial.
Please don't skip 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.
For certain types of Assets, the steps outlined in this tutorial may not be needed. These include:
1) Unity Terrain (except if part of MicroVerse)
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 (this is the case for the MicroVerse 2x2 Demo Scene terrain).
Almost everything else . . .
Seriously, unless the asset is extremely large or heavy, it will probably be better off packaged with other assets within an Asset Chunk, which is the aim of this tutorial!
Consider the different assets in your scene and the different loading strategies/configuration settings they'll need. 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 should be loaded together (and thus grouped together) is typically the assets' size, however the following are also common criteria:
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) 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.
4) 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.
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 Enabled 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.
In addition, Zones allow you to group together several Groupings of assets into a defined region of space in your game World. While you can place the entirety of your game world into a single Zone, it is usually better to use several Zones, one for each discreet area of your World (for example, if your world is made of several islands or continents, each one might be a separate Zone).
The determination of how many Zones your game will have is up to you, although a good rule of thumb is, if you have content that is separated by a lot of empty space, the separated content should probably go in separate Zones.
In relation to this Scene Conversion Tutorial, the tutorial is intended for use on a single Zone Grouping. If you have multiple Groupings and Zones, you will likely need to work through the tutorial multiple times!