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

Rotate

usePivot

referenceFrameIndex

When the UsePivot parameter is set to false, the node will use the position of each entity at a given frame as a pivot. This means loading the reference frame from the disk and applying all the layout nodes prior to the Rotate node. When using this mode, 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 Rotate node as much at the beginning of the execution flow as possible:
    this allows the reference frame to be computed faster

Expand

referenceFrameIndex

The Expand node always uses a reference frame index to get the correct expand pivot positions. 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

SnapTo

referenceFrameIndex

The SnapTo node always uses a reference frame index to ensure the entities are snapped at theeir target at the given frame. This means loading the reference frame from the disk and applying all the layout nodes prior to the SnapTo 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 SnapTo node as much at the beginning of the execution flow as possible:
    this allows the reference frame to be computed faster

FrameOffset

frameOffsetNoise

frameOffsetNoiseStep

The FrameOffset always needs to load another frame to offset the entities. But when using noise, the node might require the load of as much frames as entities that are affected by the node. This means loading the offseted 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)

FrameWarp

frameWarpNoise

frameWarpNoiseStep

The FrameWarp always needs to load another frame to warp the entities. But when using noise, the node might require the load of as much frames as entities that are affected by the node. This means loading the 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)

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