Scene Generation and Update Time
One measure for performance is the time it takes to generate an elastic scene. This includes 1. downloading all resources such as maps and loading all scene resources from the storage, 2. preprocessing internal data structures and 3. processing all node outputs that contribute to an ElasticSceneDefinition. The same operations are called whenever a scene generation catches-up with the player. Hence, a slow scene update may even cause the player to leave the generated scene and fly into the void.
The ElasticSceneGenerator extents determine the amount of data that has to be downloaded and preprocessed. Cutting the extents in half almost quarters the number of operations of every pose set node as well as the open street map depending nodes such as the RoadNetworkMask. On the other hand, reducing the ElasticSceneGenerator resolution to half the size almost quarters the number of operations of every map node. This leads to the following checklist:
- Set the smallest bearable ElasticSceneGenerator extents with respect to popup effects.
- Set the smallest bearable ElasticSceneGenerator resolution with respect to the degree of detail of maps and terrain.
The most important handle for reasonable generation times is to keep the generation graph slim. It's technically easy to re-use nodes by linking the same output port to multiple input ports of different consumer nodes. This also means to avoid similar nodes and subtrees with slightly different output (such as multiple PerlinNoise nodes with almost identical parameters). Instead, try to unify them up to a degree where a different parameter set really matters. In order to keep your graph clean, make use of portals which are computationally for free. Let us summarize:
- Re-use nodes to avoid redundant operations.
- Use portals to emphasize re-usability.
Furthermore, think about how to avoid expensive operations if the output is almost identical. As an example, a pose set should first be masked with RemoveByMap before the objects are rotated using RotateTowardsGradientDirection because the rotation has to be applied to fewer nodes. Be aware though, that there are situations in which the order of the nodes doesn't only affect the performance but also the output. In the aforementioned example, applying TranslateAlongGradient after the masking will most likely lead to poses outside of the masked area. Consider these steps to make sure to use the most performant node setup:
- Review the order of your nodes. Swap the order if the output is identical but fever operations can be achieved.
- Use a single spawner with a PickPrefabByMap node rather than individual spawners with masked areas.
- For dense decoration objects, replace PoseSetSpawners by more performant but less flexible GridSpawners. (See framerate Optimizations)
Additionally, it is important to think of a worst case scenario when dealing with map data. OSM dependent spawners may download large files that require heavy preprocessing. Additionally it is a good idea to transition to an alternative scene setup that generates a internet independent scene replacement if the vehicle gets too close to the edge of the ElasticSceneGenerator. This can be a flight over a perlin noise terrain or an equally simple graph.
- Be aware of the potential size of your OSM query.
- Transition to simple internet independent graph if the ElasticSceneGenerator cannot catch up.