The Behavior Editor and the Crowd Visual Feedback are able to report Behaviors, Behavior 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
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.
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 Containers, Parallel 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.
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).
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).