Layout Editor Performances
Some of the parameters of the Layout Nodes can consume more CPU cycles than others, depending how they are used. This page references the main performances heavy parameters and how to make it less time consuming.
Whenever a layout computation takes longer than one second a message will appear in the Script Editor telling how long it took. If you set the Golaem Crowd Severity log Level to Info, the log will also give a detail of where the time was spent:
Info message detailling where computaiton time is spent in the Layout
referenceFrameIndex
Some nodes use a referenceFrameIndex to help computing the transformation from a specific frame. This means loading the reference frame from the disk and applying all the layout nodes prior to the Expand node. Some strategies to minimise CPU computation are:
- using the same ReferenceFrameIndex for all nodes in the layout:
this allows to load and compute only one reference frame for the whole layout instead of a different one per rotate node. - putting the Expand node as much at the beginning of the execution flow as possible:
this allows the reference frame to be computed faster
Nodes using a referenceFrameIndex:
| Rotate | When the UsePivot parameter is set to false, the node will use the position of each entity at a given frame as a pivot |
| Expand | The Expand node always uses a reference frame index to get the correct expand pivot positions |
| SnapTo | The SnapTo node always uses a reference frame index to ensure the entities are snapped at their target at the given frame |
| FaceTo | The FaceTo node always uses a reference frame index to ensure the entities are facing their target at the given frame |
FrameNoise / FrameNoiseStep
When using frame offset/warp noise, the node might require the load of as much frames as entities that are affected by the node. This means loading the offseted/warped frame(s) from the disk and applying all the layout nodes on this source frame. Some strategies to minimise CPU computation are:
- using a noise and noise steps that will help minimizing the number of frames to load while still ensuring the desired display diversity:
The number of frames that will be loaded from the disk is computed as follow: frameCount = frameOffsetNoise / frameOffsetNoiseStep. For instance, with a noise of 2.1 and a noise step of 0.5, the number of different frames to load is going to be 4 (2.1/0.5=4.2, but 4 is the nearest integer lower to this value)
Nodes using a frame noise / frame noise step:
| FrameOffset | The frameOffset uses some noise to allow a different frame offset per entity |
| FrameWarp | The frameWarp uses some noise to allow a different frame warp per entity |
GroundAdaptation mode
The Ik mode of the ground adaptation is more time consuming than any other mode, because it requires to compute ground positions for each adapted, and then to compute an inverse kinematic for the legs, which requires more CPU than simply moving the whole posture up or down (like the snap height mode)
TrajectoryVectorField map
The size of the trajectory vector field map has a great impact on the layout performance