Simulation Troubleshooting

The Behavior Editor and the Crowd Visual Feedback are able to report BehaviorsBehavior Containers and Entity troubleshooting at initialization or during the simulation with visual feedbacks. 

Crowd Visual Feedback and Behavior Editor Feedback on a picked Entity

Simulation Initialization troubleshooting

At the simulation initialization, several configuration troubles may occur. In addition to the Maya Script Editor History, the Behavior Editor is here to help resolve these issues. Feedbacks are shown in the Behavior Editor main workspace, and in the status bar when a Behavior is selected.

Error feedback raised by beMotion

Feedback levels

Four feedback levels are handled in the Behavior Editor, an overlay icon related to the Behavior status is shown on top of the Behavior Icon.

Valid No icon the simulation initialization was computed without any issue and is able to run

the warning Behavior is able to be run but may occur some unwanted side effects during the simulation.

Warning raised by a beMotion
Example: a beMotion without any Motion Mapping File when the Motion Mapping Mode asked one

the Behavior is not able to be run and will be removed from the simulation.

Error raised by a beMotion
Example: a beLocomotion without any Animation Files

the simulation is not initialized, an unexpected critical error has occurred and stopped the simulation.

Example: a missing link in the Behavior Graph cannot be handled and must be fixed by the user

Notice that Behavior ContainersParallel Operator and No Order Operator status depends on children status. It means that if a child Behavior has raised an error, the parent Behavior Container will also tagged as in error. In this case the Behavior Container will not be removed from the simulation, only the failed child Behavior.

Error raised by a beMotion in a Parallel Operator

Recover the simulation

To recover the simulation, configuration troubles must be fixed and the simulation restarted.

Simulation troubleshooting

During a simulation, click on an entity in the Maya Viewport in order to get a live visual debug of the Behavior Graph process in the Behavior Editor and Behavior Visual Feedbacks in the Crowd Visual Feedback.
Picked entity in Maya Viewport (shown as orange), and associated crowd Visual Feedback
The visual feedback window displays the selected entity alone, and list below the behaviors it is currently running. Motion behaviors will provide an additional progress bar, showing the current progression in the motion total length.
Opening the Behavior Editor while provide additional information on what happened on last frame, highlighting which nodes have been started, updated or stopped.
Let's consider this Behavior Graph :
Idle - behavior graph as shown while editing
When not running, it displays two bePhysicalizeShape behaviors, and some "dummy" alternative nodes for the demonstration purpose only.
The first Physicalize sets a static mode, while the second will wait for a collision trigger, to go into ragdoll mode.
Let's see what happens when we hit play for a single frame :
Frame 1 - behavior graph after playing first frame, on a selected entity
The Initial node has been triggered, which has directly forwarded the runtime flow to the first behavior. The first behavior has evaluated its start trigger which was true, and went to "running" status. Then its stop trigger was false, so the behavior stayed in running state and stopped the runtime flow there.
Running nodes are displayed as green.
Stopped nodes are displayed as a yellow to green gradient, depending on their traversal order (yellow = older, green = newer). 

Frame 2
The first behavior stop trigger switched to true, releasing the runtime flow which will continue to the next behavior. The next behavior has its start trigger false, so it won't start and stop the runtime flow here.
Starting nodes are shown in cyan

Frame 3, and few next frames
The second behavior has a collision detection as start trigger. While it is waiting for this trigger, it remains in a "starting" status, and continue displaying as blue. Note that the previously stopped nodes are not highlighted anymroe as they have not been triggered on the same frame.
Collision frame - Collision trigger activated
The second behavior start trigger finally goes true, and put the behavior in a running state. Once updated, the stop trigger is not true yet, so the runtime flow will stop there.
Exit of second behavior, passing through different operators up to the final node.
Finally the second behavior stop trigger becomes true, releasing the runtime flow, which goes through the operators (just here to show the gradient in debug view, they don't actually do anything) which won't block, up to the final node. If this graph was the content of a composite behavior, the execution flow would continue in to the parent graph.
Behavior graph has reached its end.
Once the behavior graph has been totally traversed, it does not show any debug status, until the next trigger of its initial node (a scene replay, or for composite behavior, another trigger of the composite entry).

Simulation Behavior Coloring

It is also possible to control an Entity color based on the last Behavior which has been starting. This option can be enabled in the Simulation Attributes of the Crowd Field and the color of each Behavior can be controlled in its Visual Feedback Attributes. Notice that when a new Behavior starts it overrides the Entity color and this color remains even if the same Behavior has stopped. Finally the influence of the color in the viewport can be controlled with the Display Color Weight of the Entity Type Node:


Simulations with Channel Operator Behaviors

When running a Channel Operator Behavior, it is sometimes useful to be able to check the output values for each Channel Operator. This is something the Channel Operator Editor Visual Debugger can easily do.

The Channel Operator Editor Visual Debugger display output values for Channel Operators