To deal with a crowd scene means to handle it and treat it on two levels: at the crowd level and at the individual level. Although the crowd is a single entity, it is made out of many char-acters that supposedly have a life on their own, and somehow you have to show this.
For example, a flock of birds normally flies in one direction, but the similar and yet never identical movements of each bird differentiates it from the others, giving a nice, char-acteristically asynchronous look to the flock. This concept is not limited to animation, but is easily extended to modeling and rendering. For example, each bird in the flock is different in size and proportion, not to mention the color patterns of the feathers that differentiate males from females from juveniles.
Therefore, at the crowd level, you must decide how the crowd moves in its entirety; at the individual level, you must decide how each individual looks and moves with the crowd.
Although you can treat the crowd level primarily as a single task, being "just" about position and orientation of each individual frame by frame (with some exceptions), at the individual level, you deal with the appearance of individuals and how they propel themselves (legs, ten-tacles, turbines).
worry about the appearance of each single character, other than maybe considering its vol-ume to avoid unrealistic interpenetration. At this level of abstraction, they'll pre-visualize the shot with simple spheres or boxes of various sizes and proportions.
The second team, in the meantime, can start working out the details of the source mod-els—one or many—and their rendering properties (task 2). Once the original model is ready, this team must develop methods to duplicate and differentiate the models. In some cases, this step is simply a matter of minor color differences. In others, the geometry is affected, and major color differences are appropriate. The goal for these variations is to provide enough visual variety to the usually static property of the characters that they seem to be individuals, not duplicates.
Team 3 is responsible for animating the individual characters in the crowd (task 3).
Although not always necessary—for instance, if the crowd is actually a procedurally driven Formula One race—the animation team is a must if the characters are to have limbs or any other nontrivial moving part. The responsibility of team 3 is to move the body according to the information provided by the crowd system, most notably the speed and rate of turn, eas-ily extrapolated by position and orientation values changing over time. Team 3 must also handle status tags, which I'll discuss later, because of their potential in changing the position of the characters' moving parts. How this is done depends on the typology of the crowd, ranging from a fully procedural to a semi-automatic approach, in which libraries of hand-animated character motion are seamlessly blended by procedural means. I'll cover these top-ics later in this chapter.
At this point, you may have noticed that something is missing. Who takes care of the skeletons, constraints, and expressions that compose each character setup?
Although the best solution is for a fourth team to take care of that specific task, the schema outlined in this section is just an ideal path to diverge from as soon as the details of a production require it. The first team could handle this task, for instance, because of some strict connection between the crowd system and what each individual does, but most likely the choice will be between the animation team and the modeling team, with a preference for the former. The animation task force is likely to have more experience animating characters, and they're the folks that are supposed to use the character setup.
Given this broad overview, it is important to realize that even if we can draw lines between these primary tasks, they are still intertwined. They require a good level of commu-nication between the teams, a need that grows exponentially with the complexity of the individual character and the richness of the crowd behavior. Let's now proceed with the details of each team's to-do list and how to tackle them.
172 C H A P T E R 6 • Creating Crowd Scenes from a Small Number of Base Models
The Genesis Team
The Genesis team (team 1) is responsible for the modeling, setup, and diversification of the characters. Modeling a character for a crowd is somewhat similar to modeling a character for a video game: the models must have a low polygon count, and the textures provide most of the details. Although in the movie industry, we have some advantages over our cousins in the video-game industry, who are forced to render a relatively high resolution frame in l/30th of a second, it is good practice to keep the overall complexity of a crowd character as low as possible. For the example in this chapter, I set myself a target mesh of about 2000 polygons, knowing that the overall number of individuals I wanted in the final scene is in the 100-200 range, for a worst-case scenario of about 400,000 polygons. These numbers aren't really something I found with a magic formula precisely stating how many characters and polygons my dual 800MHz workstation can handle. But anybody who has worked inten-sively enough in this business will know about how much can be asked of hardware and human patience.
Human patience tends to be the most important issue when working with a crowd scene. During the production of Help! I'm a Fish, a Danish-German animated feature I had the pleasure to work on, some scenes had a loading time of 20 minutes, a change to the crowd—whose properties were mostly expression-based—took another 20 minutes, and sav-ing the scene took an additional 20 minutes—on a then powerful 250Mhz SGI Indigo2, with 300-600 models with 200-400 polygons each. In an ideal 10-hour day (no lunch, no coffee, no nervous breakdown), that's a total of 10 changes, not really many if you're not at the final, polishing-touches stage and you know exactly where you want to get.
The biggest problem facing an artist working on a crowd scene is not so much render-ing time, which is becomrender-ing cheaper and cheaper every day with larger render farms, but the degree of interactivity with the 3D scene, a bottleneck created by the growing but far more limited power of graphic cards.
Later in this chapter, I'll discuss modular strategies for overcoming these problems. For now, let's focus on the Zoid, the character we're going to use as the base model for our crowd and shown in Figure 6.2. (You can find the Maya file for this scene, Z o i d _ b a s e . m b , on the CD-ROM.) The Zoid will be the protagonist of a shot, together with about 200 of his broth-ers, portraying a crowd sitting on a bleacher in a basketball court and making the wave.
As you can see, in Figure 6.2, the polygonal mesh is simple: 2000 polygons, 4000 ver-tices, and 53 bones. As a rule, I tend to avoid NURBS or subdivision surfaces for crowds, to save the renderer from the tessellation step, given that most of the time polygons are enough for models of this type.
A three-finger hand is in place for our Zoid, with bones for each finger, but I could have easily saved another eight bones using two fingers only, one for the thumb and one for the four others. Time is a tyrant, and any step that saves time is worth considering.
Some expressions connect two extra attributes on the forearm (elbow joint) to the clo-sure of the hand and thumb in a fist; their purpose is to help the animator pose the character for the animation library. Those expressions though, as any other static output expression, shouldn't end up in the final scene. Each expression is evaluated in every frame, no matter if the result will actually change or move anything. On a handful of characters, leaving expres-sions in the scene easily might be forgiven. In a crowd of 200 characters, in a 96-frame scene, 12 expressions in the original Zoid (one for each finger joint) means 200 x 96 x 12 = 230,400 evaluations, a rather large waste of processing power if it can be avoided with no loss in the visual output.
Figure 6.2: The skin, skeleton, and shader tree of a Zoid.
As you can see in this simple example, in the creation phase we must be really careful with the apparently small numbers of features of the base character. We must try to limit model and setup to only what's necessary and unavoidable, and we must flag some charac-teristics as removable by the people downstream in the production pipeline.
Additional utilities for the animators are six IK handles—two in each ankle, two at the tip of each foot, and two more in the wrists. Two nulls, or locators (dark green), control the pole vector of each arm's two-bone chain.
174 C H A P T E R 6 • Creating Crowd Scenes from a Small Number of Base Models
Now, let's look at the shader tree. It too is simple: eight nodes in all. Starting from the top node, a Lambert node, the tree splits in surface colors and a fake rim light. The rim light is given by a Sampler Info node whose facing ratio output is piped in a black to red ramp.
Although this might sound complicated, it is actually nothing more than a bare X-ray shader, the only difference being that its output is directed to the incandescent input of the Lambert node instead of to the transparency. In the ramp itself, moving the colorEntry[2] up and down changes the overall thickness of the red rim, faking a back light behind the character.
The two surface colors—yellow and blue—are provided by two monochromatic ramps mixed together by a layered texture node. A third input to this node is a texture file, painted on the 3D model with Maya-integrated painting tools and then saved as a 1024 x 1024 . t g a picture ( b a s e _ h u m a n o i d S h a p e . t g a on the CD-ROM). The yellow color is placed on top of the blue background color using this file as a mask and generating the effect of a yellow pat-tern on the blue skin of the character. Figure 6.3 shows the three colors of a Zoid.
The character is encoded as a Maya binary (*. m b ) file. I have a rule of thumb about this, not unusual in the 3D industry, and that's why I'm mentioning this apparently trivial topic. Maya binary files load faster than Maya ASCII files. The Z o i d _ b a s e . m b file loads two to three times faster than the same file saved as Z o i d _ b a s e . m a . Saving your finished model files in Maya binary is a good idea because these files usually contain thousands of coordi-nates for vertex positions and numbers for topology information. You can then switch to Maya ASCII when you put together your entire scene with all models, especially when the
scenes become complex and have references in them.
As you know, you can read and edit an ASCII file using a sim-ple text editor. This can help in at least two situations. For example, a scene has 50 references to model files. If you have an ASCII file, you can switch from low-resolution to higher-resolution models without opening the scene. Simply use the Replace function available in any decent text editor, and you can start right away with the high-resolution render. (See Figure 6.4.) Here's another example: Some-thing goes horribly wrong, and your extremely precious scene is corrupted. You can open an ASCII file and debug it manually to find Figure 6.3: The three colors characterizing a Zoid and correct the line that generated
Figure 6.4: The first lines in a *. ma file include the path and filenames of the referenced models.
Replacing them with the help of a text editor updates the scene without the need to open it in Maya, a time-consuming operation when the crowd of characters is in place.
the loading error. In the worst case, you will lose only the corrupted lines instead of the last two hours of work.
A Word about Architecture
Before we look at the scripts in this chapter, I want to give you some details about their over-all architecture and discuss the guidelines I follow when writing a script.
First, I require that each script act either on a selected group of characters or, if nothing is selected, on all characters. Such flexibility is important. For example, the crowd is in place, but you don't like a few of the individuals. You can run the script more than once, and only the selected characters will be affected. Sometimes, instead, the overall effect is not right, and in those case you'll need to change everything in the scene by running the script on all the characters.
Second, I must be able to run every script in a GUI mode and from the command line. In the Z o i d _ h u e V a r . m e l script, for instance, I can call the global procedure Z o i d _ h u e V a r G U I ( ) and access it through a button on one of the shelves. Clicking the button opens a simple prompt-Dialogue window that displays a tiny prompt line with default reliable values and some hint of their meaning. The user can enter help instead of the values to get a more extensive description.
1 76 C H A P T E R 6 • Creating Crowd Scenes from a Small Number of Base Models
This script admittedly doesn't have a fantastic GUI. I prefer to keep interfaces as small as possible and focus on writing a robust core procedure, the one actually doing something to the scene, in this case Z o i c L h u e V a r ( ). Once the script is working correctly and is properly debugged, there is no harm going back to the GUI code and improving it or having a GUI programmer take care of it.
The command line becomes important when things get slow. After the testing is done and all the useful input values and ranges are known, you can use the interactive GUI version of the script to modify the crowd and all the variations of its individuals. But this can take a while if, for example, you have 1000 Zoids in a scene. Even if the system can handle \ 000 Zoids, it would surely take its time doing so. Suppose that you calculate the runtime at about 6 hours and that it should finish about 2 A.M.. And you need to run another script after the first one, which will also take some time. You don't want to be there at 2 A.M. to run the second script, do you?
If the scripts you write are GUI based only, you have no choice but to wait, miss your son's evening basketball game, go home about 3 A.M., and face a spouse who's not exactly happy. Solution: the script must always have a GUI-free "core" procedure, ready to run from the Maya command line, the Maya Script Editor, or from another script. With this method, you can stack two or more scripts to run one after the other, even more than once, without your assistance.
The last issue I want to mention about the architecture of these scripts is an important argument regarding anything meant to run for a long time, a usual occurrence with crowds.
At least in the interactive, GUI version, a script must generate goodly amount of runtime output (maybe with different "verbose" levels) and statistics about what it is doing and how fast it is doing it. With a crowd scene, a script can easily run for ten minutes, one hour, or all night. Therefore, I usually generate two types of output:
• A line of text for each character processed
• A report of the start and end times
In the main loop of the script, I usually generate a line of text for each character processed, for example, "Processing Zoid27... done! - (27 of50)". The frequency of this out-put can range from less than a second to a few minutes. If the frequency at which a new line of output is printed to the screen is lower than this, generate additional lines in key points of the code, most notably after the instructions that require the longest time—for example, loading and unloading of big reference files. If the frequency is higher, and the output is liter-ally racing down the screen, it's wise to generate output only every 10, 100, or 1000 loops or every 5, 10, or 25 percent of the total number of loops.
Furthermore, at the beginning of the script, I usually set a variable with the start time.
When the script finishes, the start time and the end time are reported together so that I can check when and for how long the script has run.
Here's what can happen if you don't generate such output. You run the script overnight, and during dailies, the director or the supervisor asks you to make a change. "No problem,"
you reply, but when they ask how much time it will take and if the executive producer can see it before lunch, you have to answer evasively because the script that started at 8 P.M. could have finished at 9 p.m. or at 7 a.m. the next morning. Generating output prevents this situation.
Listing 6.1 is an empty template, the basic framework on which I usually structure my scripts. Easily recognizable are the two main procedures, the user-input handling and the output-generating lines of code.
/ Listing 6.1: An Empty Template / / t e m p l a t e S c r i p t . m e l - v l . 0 0 . 0 0 // by Manu3d - © 2 0 0 2
i f ( $ v e r b o s e ) {
p r i n t (" - - - - \ n") p r i n t ( " Z o i d _ s i z e V a r . m e l output starts h e r e . \ n " ) p r i n t ( " - - - - \ n") :
$timel = "system("time /T")';
// c y c l i n g t h r o u g h the selected objects for($i=0;$i<$objNb;$i++)
I
$obj = $objList[$i];
i f ( $ v e r b o s e )
p r i n t ( " O b j e c t " + $obj + "...");
/ / - - - - A L L the a c t i o n STARTS h e r e - - •
A L L the a c t i o n ENDS here
-// A l w a y s output the s c r i p t p r o g r e s s e s . if($verbose)
p r i n t ( " Done! - ("+($1+1)+" of "+$objNb+")\n'
/ / r e p o r t i n g f i n a l s t a t s i f ( $ v e r b o s e )
{
s t r i n g $time2 = 'system("time /T")';
print("--- - - \ n") ; p r i n t ( " M a i n l o o p begun: " + $ t i m e l ) ;
p r i n t ( " M a i n l o o p ended: " + $time2);
p r i n t ( " - - - - \ n") ; p r i n t ( " c o r e P r o c e d u r e . m e l output ends h e r e . \ n " ) ; p r i n t ( " - - - - \ n") ; }
r e t u r n 0 ;
continues
1 78 C H A P T E R 6 • Creating Crowd Scenes from a Small Number of Base Models
Why use two monochromatic ramps, a black-and-white mask file, and a layered texture if painting the yellow spots directly on a blue background would lead to a single file and a single node? If we could get by with blue and yellow characters only, that would be a good,