Troubleshooting calculation performance
When do long calculation times appear
There are a number of moments during the usage of a project where calculations take place. Roughly speaking, whenever a change in the data of a project or session takes place, calculations are performed. The engine is already optimized to "cache" many results. If only part of the data changed, only the calculations affected by the changed data are performed again. However, at some times, all calculations need to be performed again. You may at some point in your project experience that the engine spends a long time performing calculations, despite these mechanisms.
- When loading a project into a single/multi user session
- When switching level
- When performing an action
- When firing an event
- When loading a project into the editor
- When starting or stopping a testrun
- When adding/removing/changing anything spatial (zones, buildings, areas, etc)
- When uploading excel sheets
Probable causes of long calculation times
Areas (And polygons)
Because many calculation in the engine rely on spatial data, many things in the engine have some form of polygon: a shape which, in one way or another, is "in" the 3D encvironment. Constructions, zones and areas are most easily recognized as polygons. But other things such as land ownership and terrain types do too. When data changes, the engine may have to see whether this has affected any polygons. If it has, it means things like the surface area of something has changed, or that some element now is or isn't overlapping with another polygon anymore. The engine tries to find ways to avoid these calculations as much as possible, but they must occur at some point. The following situations may cause the engine to calculate too much when it comes to polygons.
Many areas (or polygons)
The more polygons exist, the more the engine will have to check to see whether they require an update. A (quick) calculation will be performed to see if the change has affected a given polygon, and if it has, a more thorough calculation will be performed to calculate the actual resulting data. If there are more polygons, more will need to be checked that first time, to see whether they are affected by a given change.
Constructions form an exception. They are used less as "containers" for calculations, so aren't checked in the same manner as often.
Where possible, use fewer polygons rather than more. Also, be sure to clean up polygons you no longer use (for example: unused areas). With the exception of constructions, the amount of polygon elements (areas, zones, etc) in a project should not be more than a thousand.
Large areas (or polygons)
The larger a polygon is, the more chance there is of it being affected by a change. Even though the change may be marginal in respect to the size of the polygon, every small change that takes place within it will cause the engine to recalculate for that polygon.
Where possible, keep your polygons a reasonable size. As a general rule of thumb, the zones in a project should be the largest polygons you have.
Complex areas (or polygons)
The more complex a polygon is, the more time it takes for the engine to calculate whether a change intersects with it or not. Complexity comes from the amount of subpolygons a polygon has (smaller,scattered pieces, or holes within the larger polygon), and the amount of corners a polygon has. A doughnut, 10 meters across, is more complex than a square 200 meters across, because a doughnut's edge is comprised of many small corners, and it has a subpolygon for the hole in the middle.
Where possible, keep polygons as simple as possible. There is no easy measure for determining the complexity of a polygon. If you find a polygon which is long, thin, has many corners, branches or holes, try to get the polygon smoothed out, or cut up into smaller polygons with fewer corners and subpolygons.