Working with Cells

PreviousWorking with LODs NextWorking with Data

Last updated 2 years ago

Working with Cells

Uranus Instancer will automatically run a special frustum culling algorithm for visibility tests. This is similar to the PlayCanvas camera frustum culling that can increase performance by excluding from rendering objects that are not visible in viewport.

While frustum culling can increase GPU performance and reduce the amount of draw calls rendered per frame, it can increase at the same moment the CPU usage. The calculations required for visibility tests increase linearly in complexity with the number of objects in scene.

From the PlayCanvas API documentation:

"Frustum Culling: Controls the culling of mesh instances against the camera frustum, i.e. if objects outside of camera should be omitted from rendering. If false, all mesh instances in the scene are rendered by the camera, regardless of visibility. Defaults to false."

Similarly if you are using LOD levels, the distance calculations required for each instance add to that CPU overhead and can potentially decrease performance for large numbers of objects.

Uranus GPU Instancer provides a special system to reduce this CPU overhead and improve performance: using a special grid partitioning system.

How Cells work?

When an instance that has the uranus-instancer-cell.js attached is enabled and rendered for the first time, Uranus Instancer will automatically add that instance to an internal grid and assign it to the required cell, based on its world position.

From this moment that instance will be grouped with all other instances in the same cell and all LOD and visibility calculations will be executed once per cell and applied to all included instances. That can result in a massive increase in performance.

Cells, as expected, will only work with static objects since they are based on the world position of the entity. If an entity is dynamic then it should not be using Cells.

This script has the following settings:

Cell Size: Defines the size of the cell for all grouped instances.

Note that the instancer will pick this size from the first instance added and will reuse it later on, meaning all instances of the same object should be using the same Cell Size.

Update Frequency: Set how often in seconds culling (LOD and visibility) checks will execute, useful to further improve performance by skipping per frame calculations. Set to 0.0 to update per frame.
Update Shadows Frequency: Same with the previous setting but for shadows rendering.

PreviousWorking with LODs NextWorking with Data

Last updated 2 years ago

From the PlayCanvas API documentation:

Similarly if you are using LOD levels, the distance calculations required for each instance add to that CPU overhead and can potentially decrease performance for large numbers of objects.

Uranus GPU Instancer provides a special system to reduce this CPU overhead and improve performance: using a special grid partitioning system.

How Cells work?

Cells, as expected, will only work with static objects since they are based on the world position of the entity. If an entity is dynamic then it should not be using Cells.

This script has the following settings:

Cell Size: Defines the size of the cell for all grouped instances.

Note that the instancer will pick this size from the first instance added and will reuse it later on, meaning all instances of the same object should be using the same Cell Size.

Update Frequency: Set how often in seconds culling (LOD and visibility) checks will execute, useful to further improve performance by skipping per frame calculations. Set to 0.0 to update per frame.
Update Shadows Frequency: Same with the previous setting but for shadows rendering.