#Asynchronous Prefab and Runtime Entity Spawning Handling - RFC

1 messages · Page 1 of 1 (latest)

solid canopy
#

Outline

When introducing Loading Screen functionality to the GS_Play framework, I encountered major hitches when spawning the latter level, as a prefab, during a level change. Because of this, the following frame deltatime was so enormous, animations running at the completion of the load would complete before starting.

In overcoming that process I opted to pre-process my spawnable asset data to be able to batch load them.

After the first prototype I bore deeper into it, and with information brought forward from Nick and ChatGPT independently, I found there was ample opportunity to refine this batching loading process into a full fledged asynchronous spawn handler.

Lastly, positioning this as a phase 2 step to a greater Entity functionality Expansion project after: #1426268617124614175, I believe that we can even further hone the spawning performance, due to a lower number of spawntime activations at the final junction of spawning, and create a highly valuable expansion to the core engine systems.

Feature Outline

By refining and introducing some additional steps of processing during the spawn process, we can maximize the performance of the many stages of entity spawning, from asset data, to spawned and activated Entities and yield a load functionality the does not create huge framerate lurches, and can additionally report load progress to provide player facing data on the progress of the game load.

#

What is needed

Upon an Asynch Spawn Request, we would process the spawnable asset entity list into a list of batched entities to process together in the later, main threaded activation phases, in order to create a full throughline from multi-threaded handling, to main thread handling to provide a fully "Async" spawning experience through "Over Time" entity loading.

I believe that the data loading stage of spawning already runs threaded (async), however we would want to simply verify it and make sure that it's processing the source entity data in a way that we can piggy back on on completion.

Next, we can begin batch processing entity Initialization Init(). Either through callbacks from batched threaded data loading, or after a batching process that processes our list of loaded entities into groups, we then start Initializing these enitities over time. One batch per frame.

  • One extra feature I would like to target is to have a deltaTime threshold where the batch this frame will break out and complete in a later frame if it's been taking too long to Init. This would be from situations where you're activating massive entities like Terrain or Nav Meshes or other big data entitities.

After Init(), if we introduce this feature after the Entity Activation Handling featureset, we can also target the Initialized entity Transform Component to build our entity hierarchy map and determine if this Entity, and therefor it's descendents will spawn inactive (meaning, remaining Initialized and no further.)

Then, upon full Init, we can do two possible things:

  • Do a single massive entity activation of all valid Activate Enitites. This would be most compliant of current O3DE spawning patterns and thus, should yield a very regular outcome.
  • Or, do Activation Batching as well. This might be worth creating as an option in the AsynchSpawnArgs companion class.

All throughout the stages of this process, we can utilize an AsynchSpawnNotificationsBus or add additional methods to the already present SpawningNotificationsBus to report the progress of the Spawn over this extended time.

Conclusion

Having already done a far more crude version of this feature here #1423862760701431868, I believe it's not too much farther to go the full way and build this range of features.

My second internal iteration from the original linked was going to pretty much match this process, however, as a duplicate of the already present spawn system in order to completely circumvent the Spawn Process and introduce these feature injections in my proprietary version. It, being separate from the entity system as it is, meant I had shortcomings, like being unable to process/map first runtime entities spawned, and ultimately involved recreating wheels that were already fully present and functional in the Entity system.

With the validation of the processes of spawning from Nick, I don't believe my proprietary implementation would be worth pursuing over a community expansion of the Entity Spawning system, as, with only a few additional steps, we could have a fully fledged and integrated feature that, along with entity activation handling, would lead to a HIGHLY impactful feature set that would significantly improve the viability of the engine for outside parties that expect these features to be present in game engines inherently.