The next issue to be dealt with was that the animal heads would move around and rotate during a shot. Nat - urally, animals move their heads, just like people do. The head moves were care - fully matchmoved, and we applied the finished motions to our geometry so that our CG heads would move in the same manner as the real ani - mals’ heads. Note: Matchmoving is a grueling, brain-burning task involving taking geometrically imperfect geometry into Layout, loading up the plate, and making the geometry fit the animal on every single frame, one frame at a time. If you ever meet a matchmover, don’t forget to give him cookies. It’s a thankless job and has a rating of 11 on the tough-o-meter. Our problem lay in that our spotlights have cone angles. In other words, there is a limited area where any given spotlight will illuminate something. If the head is moving around, then either the cone has to be large enough to encompass the entire range of motion or the lights have to follow the head around as it moves. Both of these have their advantages and disadvantages. ··························· Anatomy of a Production Lighting Rig 467 Figure 27.6 Figure 27.7 If we make the light cones all large enough that we never have to move the lights, we never have to move the lights but we have a prob - lem with shadow map resolution. We would have to crank up the shadow map resolution very high indeed so that the resolution was always high enough no matter where in the scene the object lay, and this would have a serious impact on render times. Remember, we’re not talking about just one light calculating a shadow map; we’re talking about eight array lights, a key light, a fill light, a rim light, and a bounce light. That’s 12 lights with 12 shadow maps. So if we have to ramp up our shadow map resolution from 1000 to 4000 to cover the area of movement, that means it will take 16 times longer to calculate the shadow maps. We definitely needed a better solution than that! In addition, we wanted to keep the cone angle as narrow as possible so that the light “beams” were as par - allel as possible, simulating a larger, more distant light source. If we had to make our lighting areas larger to encompass the range of motion we would have to back our lights off quite a distance to achieve the area of coverage we desired. This is not a huge problem, but when you are try- ing to get an overview of your lighting rig in the Perspective View and all your lights are a mile away, items get pretty tiny. You constantly have to ramp your world scale up and down to see things. It’s a pain. There had to be a better way. Of course, we could always target our spotlights to the CG animal head; that way each light would always illuminate the element, no mat- ter how far it moved. But the problem with this is that the light angle would be changing relative to the object as it moved. It would look just like a bunch of follow-spots all aimed at the animal and following it around. Nope. We needed something better. There was also the option of parenting all the lights to the animal head. This was not acceptable because the lights would always then maintain the same orientation to the head. As you know, when you turn your head in a lighting environment, the lights stay put and the orienta - tion between head and lighting angle changes over time with your head rotation. We needed all the good elements from each of these solutions with none of the bad ones. We needed a set of spotlights that would follow the head around without rotating. The most obvious solution to this was using expressions to make the light array maintain the same spatial posi - tion relative to the head but not rotate with the head. My first thought was to use LightWave’s handy Follower plug-in. Chapter 27 ······································ 468 With Follower, you can make one object follow another but only on the channels you desire. So I parented all my lights on a null named Light_Main_Null. Then I applied Follower to the Light_Main_Null and opened its interface. In the Follower interface, I selected mm_Null as the object to follow, and told Follower to follow only the X,Y,Z channels. I chose to use a null to apply Follower and parent the lights to the null rather than having all the lights follow the head object directly. That way, I could still independently move and rotate the lights relative to the head without affecting the following relationship. Note: The mm_Null (“matchmove” null) is where the animal’s head rotation and motion information is applied. The actual head geometry is parented to the mm_Null. There are a ton of reasons why we did this, none of which are really related to lighting, so don’t worry about it. Suffice it to say that since the motion and rotation were applied to a null object, the head, which was a child of the null object, moved just as it would if it had the motion and rotation applied directly to it. ··························· Anatomy of a Production Lighting Rig 469 Figure 27.8 Figure 27.9 Now that the lights follow the mm_Null but do not rotate, the spotlight cones always cover the geometry well just as we like. Our next step was to begin some rendering tests with fur enabled. DISASTER STRIKES! During our tests we discovered that there is an issue between LightWave and Sasquatch which prevents Sasquatch from properly interpreting shadow fuzziness information from LightWave spotlights. Note: At the time of publication, it is not clear where the prob - lem lies; however, both NewTek and Worley Labs are aware of the problem and are working to resolve it. We believe this problem will probably be resolved by the time you read this chapter; however, it didn’t help us at the time of production! The problem manifests itself in “crawling” fuzzy shadows. These arti- facts were much too visible and obvious to allow use in a production environment. We were now tasked with creating soft shadows from spotlights with shadow maps, but we could not set our shadow fuzziness above 1.0 without the “crawling” artifact becoming visible. This meant that we either had to settle for hard-edged shadows or come up with another solution. Fortunately, the old “spinning light” trick has been hanging around since the dawn of time, just waiting to save our bacon in a bad situation just like this one. But the situation was a little more complex than a simple distant light rotating 360 degrees to make a big, soft shadow. We needed our lights to retain their directional qualities, to cast shadows, but simply to have those shadows soften at the edges. We needed to create localized spinner setups for each of the four lights in our four-point rig, and we also needed a separate spinner that positionally spun the array without rotating it. I’ll explain this in more detail later. Note: For details about just how and why the “spinning light” trick works, please see Chapter 25. Adding a spinning light setup to each of the key, fill, rim, and bounce lights was not difficult. I started by adding a “Handle” null. This null is used to reposition the light. Beneath the Handle null I placed a Chapter 27 ······································ 470 “Spinner” null. Beneath the Spinner null was the Offset null, and beneath the Offset null was the light itself. The handle is parented to the Light_Main null which is following the translation of the mm_ Null; therefore, all the spinning rigs will continue to maintain their spatial relationship with the head geometry. Make sense so far? Not to worry, it gets much more complex. Next, I had to set up a spinning rig for the array. But where you can simply spin a single light, you can’t simply spin an array. Because the array is essentially a big, square fake area light, if you simply spin the whole thing, it will no longer behave like a rectangle but like a disc. You will lose shape control over your light. Furthermore, lights that are more distant from the rotation axis will cause softer shadows than those lights near the rotation axis. This is an undesired effect. This may be a moot and subtle point, but when you are dealing with as many variables as seemed to be creeping into this project, you want to minimize them as much as possible. I placed a Handle null, Spinner null, Offset null, and Array Main null in parenting order. All eight array lights were parented to the Array Main null, while retaining their position in the array. To maintain the array’s rotational orientation to the head geometry, I added an additional null in between the Offset null and the Array Main null called the Spin Corrector null. It works like this: Where the Spinner null rotates 1440 degrees for each frame (that’s four complete rotations), the Spin ··························· Anatomy of a Production Lighting Rig 471 Figure 27.10 Corrector null rotates –1440 degrees for each frame. So while the entire array describes a circle around the spinner, at a distance set by the Off - set null, the array itself does not rotate. In addition to spinning lights, Sasquatch provided us with some tools to soften the shadows. Between the two, the shadows were looking quite good on the fur. But the geometry was another matter. Due to heavy render times from the extremely dense fur we were using on our animals, we wanted to keep LightWave’s AA level down to Enhanced Low. Often, you can set Sasquatch to render its antialiasing in one pass; however, the fur will then not be calculated in LightWave’s motion blur. So we sometimes had to render the fur in each of Light - Wave’s AA passes. The disadvantage to Enhanced Low AA is that the spinning light rigs now have only five passes to try to blend shadows into a soft shadow. While this looked good on the fur, the AA stepping became completely obvious where geometry was casting shadows onto itself. The solution was to add a second set of lights. For example, instead of one key light, I would have two key lights, both the same color, intensity, angle, size, and everything, but one of them would only affect the fur and the other would only affect the geometry. The beauty of this solution was that I could turn shadow fuzzi- ness back on for the geometry lights, thereby blurring the AA stepping. In the Object Prop- erties panel, I excluded all the FUR lights from the geometry. In the Sasquatch pixel filter, I selected all the GEO lights as “Special Lights” and set the Special Light Strength to 0%, effec - tively excluding the GEO lights from Sasquatch and guaranteeing that all the GEO lights would not be used in the fur calculations. All our problems seemed to be solved. Except now when I wanted to aim the key light, I had to aim two key lights. When I wanted to change the intensity of the rim light, I had to change the intensity of two rim lights. This quickly became cumbersome. I decided the quickest solution was to target both key lights to a Key Target null, both the fill lights to a Fill Target null, and so forth. The target nulls were parented to the mm_Null so that they would Chapter 27 ······································ 472 Figure 27.11: You can see in the Scene Editor that there are now sets of lights exclusively for the geometry (GEO lights) and for the fur (FUR lights). always maintain a spatial orientation to the geometry, and the lights would, therefore, always maintain their spatial and rotational orientation correctly. Each of the target nulls could be independently moved and keyframed, so aiming the light pairs would become very easy. This prin - ciple was also applied to the entire array, now 16 lights, so that all lights would be aimed wherever the Array Target was placed. Imagine my horror, if you will, when I discovered that LightWave Targeting does not calculate properly if items are parented with expres - sions (i.e., Follower) instead of regular, hierarchical parenting. Suddenly all of the targeted lights were not aiming anywhere near the geometry. They were shooting out somewhere in space. Once again, I was faced with a choice. I could eliminate the expres - sions in my lighting rig, which would mean the entire rig would no longer maintain its rotational orientation, or I could find another way of dealing with the expressions. Enter Prem Subrahmanyam’s Relativity 2.0. I have used Relativity since version 1.0 was released several years ago. This plug-in has never failed me, and certainly did the job on this occasion as well. The main use of Relativity was to allow the Array_Main null (and therefore the light array) to match the position of the Spin Corrector null. No matter where the Spin Corrector null was located or oriented in the world, the Array_Main null had to occupy the same position. The Spin Corrector null was buried deep in a hierarchy of parenting and expressions. This made it impossible for LightWave’s Fol- lower plug-in to locate the correct position of this null. Once I finally had everything moving, spinning, following, and tar - geting correctly, I got to work on a couple of workflow problems. One of the problems was that, although the light array was to be treated as a single light, it was in fact composed of 16 lights. Changing the intensity and color of 16 lights was definitely going to be a downer, not to mention the huge potential for pilot error once we started production. So I added a slider panel and included four channels, one for array intensity and one for each of the RGB channels. ··························· Anatomy of a Production Lighting Rig 473 Figure 27.12 I then added a null called Array_Intensity and had the Array Intensity slider linked to the X channel of the null. If the slider was at 0, then the Array_Intensity null was at X=0.0. If the slider was at 1.0, then the Array_Intensity null was at X=1. I then applied Relativity Channeler to the intensity channel of every array light in the Graph Editor under the Modifiers tab, linking the intensity to the X position of the Array_Intensity null. So now, when you moved the slider, the Array_Intensity null would move in the X channel. When the Array_Intensity null moved in the X channel, the intensity of every array light would go up or down. Having the Array_Intensity null also meant that intensity values could be entered numerically by entering the X value of the null in the numeric box. Chapter 27 ······································ 474 Figure 27.13 Figure 27.14 Figure 27.15 I was also concerned that it would be time consuming to change the color of the array. With 16 lights, it would quickly become tedious to make even the smallest adjustment to hue or color temperature. So I applied the same thinking to the color channels that I had done to the intensity channel. I added one slider for each of the R, G, and B chan - nels. I added a null for each, and I connected the red value of each light to the X value of each null, then controlled the null’s X position with the slider. Creating specific colors this way is not exactly easy. I ended up find - ing a color I liked using the color picker, recording the RGB values on paper, and then applying those values to the sliders to replicate the color I had chosen. Since the key, fill, rim, and bounce lights were also arranged in GEO and FUR pairs, I decided to add four more sliders, one for each pair. My final slider panel had: • Array Intensity • Array Red Channel • Array Green Channel • Array Blue Channel • Key Intensity • Fill Intensity • Rim Intensity • Bounce Intensity Since sliding the RGB channels is a pretty primitive method of selecting colors, and since each of the light pairs has only two lights, I decided not to add sliders for the RGB values of the key, fill, rim, and bounce lights, since it was simple enough to select a color and copy it to the second light. After all, LightWave’s color picker has a sophisticated, full-featured set of color selection tools. Simply sliding RGB values actually kind of sucks. Finally, since this lighting rig was developed under LightWave 7.5, we did not have the option of selecting which lights would illuminate OpenGL. In those days, only the first eight lights would illuminate ··················· Anatomy of a Production Lighting Rig 475 Figure 27.16 OpenGL. Since my key, fill, rim, and bounce lights were the first eight I had added to the scene, OpenGL would not illumi - nate at all if I only had the array turned on. So I had to add a special OpenGL light. I cloned the key light, renamed the original key light OpenGL, and parented it to the mm_Null, just to be sure the head geometry was illuminated at all times. Under Light Properties, I then disabled both Affect Diffuse and Affect Specular, leaving only Affect OpenGL enabled. This light was then set at 100%. Now animators would always have illumina- tion in the OpenGL inter- face, regardless of the lighting setup, and that OpenGL lighting would never render. Perfect! It was a pretty complicated road that led to the development of this rig, but I hope I managed to describe not only the thinking process that was used to employ it but also the varied and unexpected production require - ments that crop up, forcing you to rethink your methods and come up with solutions to seemingly unsolvable problems. There is always a way to do it, if you just keep digging and thinking. Note: Since this chapter was written, the lighting rig went through a number of other changes to accommodate new infor - mation and new requirements. Chances are it will evolve until production is finished. But that’s the fun part! Chapter 27 ······································ 476 Figure 27.17 [...]... script analysis, 286 secondary colors, 253 Select All option, 149 shaders, 4 08 Shading Noise Reduction option, 92, 100 , 156, 362, 488 Shadow Designer 2, 195, shadow examples, 103 Shadow Fuzziness setting, 60, 88 , 117, 354, 4 38 shadow map shadows, 86 , 91, 117 Shadow Map Angle setting, 414 shadow map options, 117 Shadow Map Size setting, 88 , 117, 354 shadow mapping, 87 , 117 shadows, 11, 58 absence of, 119,... Projection Image setting, 86 , 121 496 properties, light, 3 proportion, 39 purple, 2 68 Q QuickColor pane, 107 R radiosity, 38, 92, 102 , 152, 3 78, 444, 459, 485 backdrop only, 153, 325, 372, 380 baking, 161, 406 cache, 386 , 411 faking, 401 interpolated, 382 Monte Carlo, 49, 154, 381 multi-bounce, 487 reflections, 401 tricks, 159, rainy day, 26 Range/Nominal Distance setting, 82 , 147 ray marcher fog, 179... Fit Spotlight Cone option, 88 flag, 124 494 floating-point color values, 245 flood, 1 18 fluorescent light, 37, 4 58 sources of, 58 focus, 304 fog, 175 fast, 179 ground, 1 78 linear/non-linear, 176 ray marcher, 179 Follower, 469 footlights, 8, 72 four-point lighting, 70 full precision, 477 G G2, 100 , 197, 322, 361, 4 48 gaffer, 9 gamma, 484 gamma rays, 239 General Options panel, 81 GI fill, 434 Global Illumination... 4 48 Global Lens Flare Intensity setting, 90 Global Light Intensity setting, 90 glossiness, 44, 135 gMil, 215 gobo, 13, 95, 2 38 gradient, 375 gradient backdrop, 373, 388 , 4 38 Graph Editor, 16, 81 green, 2 68 gray ball, 52, 320 ground fog, 1 78 H hard shadows, 12, 18, 37 HDRI, 163, 393, 445, 4 78 HDRShop, 167, 400 Height Wrap Amount setting, 399 High Dynamic Range Image, see HDRI highlight, 64 HSV 81 , 107 ... Check out Wordware s marketfeaturing the following new ShaderX2: Introductions & Tutorials with DirectX 9 ShaderX2: Shader Programming Tips & Tricks with DirectX 9 DirectX 9 Audio Exposed: Interactive Audio Development 1-55622-902-X • $44.95 6 x 9 • 384 pp 1-55622- 988 -7 • $59.95 6 x 9 • 7 28 pp 1-55622- 288 -2 • $59.95 6 x 9 • 5 68 pp Game Development and Production Game Design: Theory & Practice Games That... 2 98 three-point, 70 LightProbe image, 396, 445 lights, area, 98, 349, 360, 403, 447 distant, 93, 347, 369 linear, 100 objects as, 102 point, 97, 352, 402 spot, 94, 353 volumetric, 84 , 91, 181 LightWave color picker, 105 , 373 limited region, 315 linear falloff, 82 , 146 linear lights, 100 Linear/Area Light Quality setting, 84 LScript Commander, 217 LScripts, 194, 216 luminosity, 3, 49 luminosity map,... 253 Interpolated Radiosity, 154, 382 inverse falloff, 146 inverse square falloff, 82 , 146 inverse square law, 144 Invert Selection option, 149 inverted globe trick, 397 K Kelvin, 60, 373, 427 Kelvin pane, 110 key light, 6, 63 key/fill lighting, 68 L Lens Flare Options button, 84 Lens Flare setting, 84 lens flares, 84 , 91, 189 light, color of, 60, 81 designing, 230, 286 exterior, 450 fill, 63 interior,... < > RGB pane, 1 08 hue, 246 HWB, 1 08 · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · HyperVoxels, 179 surfaces, 180 I illumination, baking, 317 image-based lighting, 394 Image Editor, 377 image filters, 194 Image Viewer FP, 479 Image World plug-in, 170, 395, 445 implementation, 286 , 300 incandescent light, 36, 57, 453 indirect bounces, 387 infrared light, 239 intensity, 3, 82 , 139, 279 intensity... 314 Virtual Darkroom, 209, 4 78 497 Index · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · visual effects, xxv volumetric antialiasing, 179 Volumetric Light Options button, 84 volumetric lights, 84 , 91, 181 additive, 185 subtractive, 185 volumetrics, 124, 174 faking, 419 W warm colors, 267 Wavelength pane, 109 4 98 wavelengths, 241 waves, 127 weather, 280 white, 2 68 Width Wrap Amount setting,... blur, 4 18 double split complementary, 2 58 doughnut, 406 dramatic lighting, 8 E eclipse, 53 Edit mode, 80 Effects panel, 166, 169, 211, 381 , 395, 397, 434 electromagnetic radiation, 239 exclude options, 149 excluding lights, 89 objects, 89 , 1 48 exterior, 20 exterior light, 450 F faking radiosity, 401 soft shadows, 412 volumetrics, 419 falloff, 82 , 144 types of, 82 , 146 fast fog, 179 fast Fresnel, 213 . Renderer and You 481 2. Pre/post adjustment and exposure A. Processing and adjusting your renders Here’s where it gets really interesting The render that you see is not really the image that LightWave. OpenGL enabled. This light was then set at 100 %. Now animators would always have illumina- tion in the OpenGL inter- face, regardless of the lighting setup, and that OpenGL lighting would never render. Perfect! . night and near complete blackness into a day at the beach. It’s important to extend the camera analogy a bit further. Using tra - ditional methods of lighting, surfacing, and rendering with LightWave