The biped crowd is a special case of crowd simulation necessitated by the complex nature of legged animal movement. Biped locomotion exhibits intricate dynamics and exacting IK foot constraints. As such, the smoothly curving trajectories computed from delegate motion parameters, while suitable for birds, fish, insects, and snakes, are not rich enough to animate the microstructure of bipedal motion. Therefore, several features in Crowd are focused on the special needs of bipeds.
In order to generate the required level of nuance, animated motion clips form the basis for the repertoire of biped movements. In other words, during a Biped/Crowd simulation, the delegates have no effect over the motion of the Biped, they only set goals to be achieved using clips available in the Motion Flow graph. With this approach, the animator can precisely control details in the motion either by using hand animation or employing motion capture to produce a set of clips that describe how a member in the crowd behaves.
For example, if you wanted to animate a crowd of marathon runners making their way through the streets of a city, you would need motion clips for various kinds of walking, running, jogging, resting, drinking water, cheering, etc. In effect, each of the motions you might expect to see in a marathon race could be represented as a clip. But motion must be more than a fragmented collection of clips. You must also consider how motions might be sequenced. Which motion transitions are possible from a given motion clip?
Biped's Motion Flow functionality provides the mechanism for defining how separate motions fit together into a fluid animation. In effect, the motion flow network describes which motions can follow from other motions. Once the motion flow network is defined, a broad set of animated actions is possible by following different paths through the network. In Biped, a path through the network is called a motion flow script.
For example, shown below is a motion flow network used in the sample file Walkers.max. You can find this file in the cstudio\tutorials\tutorial_8 directory in your 3DS MAX path. This directory also contains the .bip files used in the motion flow network.
This is a fairly simple network of possible motions, because the characters can only start, stop, turn at 90 degree angles left and right (walk_L90 and walk_R90), and do an about-face (walk_180). However, for more natural crowd interaction, it's advisable to expand the motion flow network to include shorter, more finely tuned variations such as turning at 45 degree increments, moving in different directions while facing the same way, loitering motions, and moving at different speeds. The Biped Motion Library has a comprehensive list of clips for you to experiment with.
Tip: You can create motion clips that curve slightly to the left and right by applying Biped's footstep-bending operation to straight-line motion clips. If the clips are motion captured, you should employ footstep extraction during import in preparation for the bending operation. Adding clips that turn slightly will let the biped crowd simulation make minute corrections in heading in order to achieve goal locations more precisely.
Motion flow graphs that work best incorporate fine-tuned transitions. A good way to check your Motion Flow transitions is by building test scripts as you build the graph: Add clips to the graph, add the necessary transitions, and optimize the transitions. Optimizing transitions works well as a starting point and, more often than not, produces the smoothest transitions. Next, make a new script that uses your transitions, and use the script to tweak the motion flow until the feet don't slide.
Motion flow networks may be shared by many bipeds using Shared Motion Flow Networks. Therefore, it's practical to make motion flow networks large without taxing your computer's memory.
You can give a biped a behavioral goal by associating it with a delegate in the Crowd system, and then assigning behaviors to the delegate.
For example, in the Walkers.max sample, the behavioral goals of each of the biped's delegates are to:
Move toward the sphere using the Seek behavior.
Avoid hitting each other using the Avoid behavior.
During a biped crowd simulation, the software attempts to compute the best motion flow script for each biped member of the crowd that satisfies the behavioral goals of its associated delegate. In other words:
The biped's crowd delegate defines the behavioral goals of the biped.
The possible motions to reach those goals are defined by the biped's motion flow network.
The Crowd plug-in's Solve operation computes the script, or path through the motion flow network, that best meets the goals of the biped's delegate.
So in the Walkers.max sample, the simulation will always choose the best available walking clip in the network that directs the biped's delegate toward the sphere. Each biped's script evolves as the crowd "Solve" computes. This is somewhat like a real-time "game engine" in that the crowd solver's choice of the next best clip for a given biped is restricted by that biped's currently active clip.
Because bipeds in crowds are always following motion flow scripts, the avoidance behavior for bipeds works differently. Unlike ordinary delegates, biped delegates can move only along motion flow-scripted paths, so if a collision takes place, the software will backtrack to the previous clip in the current script and find another path. This may take some time to compute when complex crowd interactions are present since a single backtrack may not be enough. The computation will explore all paths from a given backtracking clip, and if that fails, it will backtrack to the previous clip, and so on, until a solution is found.
In the example, if the current script of a biped is:
and a collision is encountered during the walk_L90 clip, the biped will backtrack to the end of the walk clip and attempt to try a different clip in place of the failed left turn. If that fails, it will try the next best choice, and so on.
Tip: The inclusion of stopping and loitering motions in the motion flow network is sometimes helpful in preventing excessive backtracking since stopping is always an effective way to avoid collisions in a tight situation. In general, the more variation in speed and direction that is possible, the more quickly the backtracking feature will find a solution.
In order to make the backtracking computationally manageable, the biped crowd members are computed one at a time in order of priority. Thus, the crowd interaction is accumulated with each successive biped added to the animation. In other words, each waits its turn to compute its complete animation, which entails avoiding the bipeds that have been computed before it. It follows that bipeds with the lowest priorities generally encounter the most collisions, since they must steer around all the bipeds that have higher priorities.
Crowd Helper Object
Creating a Crowd of Swimming Bipeds