## [Algorithms] Simplified Dynamic Lighting For Animated Characters

 [Algorithms] Simplified Dynamic Lighting For Animated Characters From: Eric Maslowski - 2001-08-30 21:07:29 ```Hello, I'm wondering if someone could shed some light, no pun intended, on a little lighting dilemma I'm having. It's a little rough and long, but it's an idea I'm playing with and would like to know what some others think about it. Motive: Basically, I want to achieve simplified dynamic lighting of sorts. Unfortunately, standard garaud shading "rounds out" the character models too much. I'm striving for a more cartoonish look, and garaud shading in many lighting conditions creates too large of a tonal range across the characters surface. Straight NPR is out of the question because another reason why I'm looking for other lighting solutions is to eliminate the need to calculate the characters normals every frame. I'm striving for advanced character physics so I need the CPU for that as well as some hefty AI. I've been toying with a couple ideas, but one in particular...It sounds like a hack that would have been done before the days of T&L, so it's probably not unique. In either case, I'd appreciate any feedback on it, especially if you implemented a similar system. I'm also open to alterations, suggestions, or completely different approaches. Specifics: - characters @ 300-500 polys each - possibility ~30+ on screen - cartoonish/simple texturing and visual appearance - PIII-700 w/ GeForce2 as target platform. Method: The artist defines clusters/groups of vertices on the character that would be affected if the light was in a particular location in relation to the character. (i.e. left, right, above, etc...) At run-time 3 planes are created centered on the character and going in the positive direction for each axis. (+x,+y,+z) With some simple range checks, the affecting lights are chosen. Cycle through each plane and figure out what clusters need to be lit by considering the lights position in relation to the plane. (in front of z plane = "front" cluster) W then feed the normal, center point, and the light's properties into a standard lighting equation to get the appropriate color. We then apply the calculated color to the characters vertex colors. Repeat for remaining planes then remaining lights. Drawbacks that I can foresee: - lighting won't be remotely accurate for dramatic/exaggerated poses. ex. light in front of character lighting the "front" cluster and the character then raises their arms straight up...These actions will probably be quick, and typically only happen in areas where the contrast in lighting is more subtle. So, I'm not too worried about this. - I was thinking of using ambient coloration as the "base" color which is then adjusted based on the lighting calculations. to do this successfully, would need to place volumes throughout world to specify the ambient color for particular regions. would allow the artist to choose the best ambient color for a particular lighting condition, but requires more work. Any thoughts on all of this? :P thanks E. --- Eric Maslowski Eric@... http://www.msu.edu/~maslows3/ PS. I faked this setup a little in MAX and it seemed to give some nice results, although I wasn't able to see it in motion...the illumination from a light gave a nice consistent value to all affected vertices without the "over-shaded" look that straight garaud shading created. with careful selection for each group/cluster, I was able to get some nice lighting effects in both subtle and dramatic lighting conditions. ```

 [Algorithms] Simplified Dynamic Lighting For Animated Characters From: Eric Maslowski - 2001-08-30 21:07:29 ```Hello, I'm wondering if someone could shed some light, no pun intended, on a little lighting dilemma I'm having. It's a little rough and long, but it's an idea I'm playing with and would like to know what some others think about it. Motive: Basically, I want to achieve simplified dynamic lighting of sorts. Unfortunately, standard garaud shading "rounds out" the character models too much. I'm striving for a more cartoonish look, and garaud shading in many lighting conditions creates too large of a tonal range across the characters surface. Straight NPR is out of the question because another reason why I'm looking for other lighting solutions is to eliminate the need to calculate the characters normals every frame. I'm striving for advanced character physics so I need the CPU for that as well as some hefty AI. I've been toying with a couple ideas, but one in particular...It sounds like a hack that would have been done before the days of T&L, so it's probably not unique. In either case, I'd appreciate any feedback on it, especially if you implemented a similar system. I'm also open to alterations, suggestions, or completely different approaches. Specifics: - characters @ 300-500 polys each - possibility ~30+ on screen - cartoonish/simple texturing and visual appearance - PIII-700 w/ GeForce2 as target platform. Method: The artist defines clusters/groups of vertices on the character that would be affected if the light was in a particular location in relation to the character. (i.e. left, right, above, etc...) At run-time 3 planes are created centered on the character and going in the positive direction for each axis. (+x,+y,+z) With some simple range checks, the affecting lights are chosen. Cycle through each plane and figure out what clusters need to be lit by considering the lights position in relation to the plane. (in front of z plane = "front" cluster) W then feed the normal, center point, and the light's properties into a standard lighting equation to get the appropriate color. We then apply the calculated color to the characters vertex colors. Repeat for remaining planes then remaining lights. Drawbacks that I can foresee: - lighting won't be remotely accurate for dramatic/exaggerated poses. ex. light in front of character lighting the "front" cluster and the character then raises their arms straight up...These actions will probably be quick, and typically only happen in areas where the contrast in lighting is more subtle. So, I'm not too worried about this. - I was thinking of using ambient coloration as the "base" color which is then adjusted based on the lighting calculations. to do this successfully, would need to place volumes throughout world to specify the ambient color for particular regions. would allow the artist to choose the best ambient color for a particular lighting condition, but requires more work. Any thoughts on all of this? :P thanks E. --- Eric Maslowski Eric@... http://www.msu.edu/~maslows3/ PS. I faked this setup a little in MAX and it seemed to give some nice results, although I wasn't able to see it in motion...the illumination from a light gave a nice consistent value to all affected vertices without the "over-shaded" look that straight garaud shading created. with careful selection for each group/cluster, I was able to get some nice lighting effects in both subtle and dramatic lighting conditions. ```
 Re: [Algorithms] Simplified Dynamic Lighting For Animated Characters From: David Hunt - 2001-08-30 23:37:12 ```Don't know if this completely relevant - but this is what I'm currently doing which is also HT&L friendly. For each moving object each frame I collect each of the affecting lights, pick the heaviest n of them then replace them with faked infinite/directional versions that approximate the same behaviour. Eg. A point light becomes a directional light with direction light->object centre and so on. The advantage of doing this is that an infinite light is considerably cheaper to do the light math on than any other type, it also unifies our light model so we don't have to worry about any strange light type types getting through to our render subsystem. At this point your characters will look very directionally lit - to get round this I juice a bit of each directional light off into the ambient for the object - and hey presto. I also have timers running on all dynamically lit objects which get reset each time it or a light near it moves, when the timer gets to 0 I bake the lighting into the vertices and turn off dynamic lighting. David ----- Original Message ----- From: Eric Maslowski To: Sent: Thursday, August 30, 2001 10:07 PM Subject: [Algorithms] Simplified Dynamic Lighting For Animated Characters > Hello, > I'm wondering if someone could shed some light, no pun intended, on a > little lighting dilemma I'm having. It's a little rough and long, but it's > an idea I'm playing with and would like to know what some others think > about it. > > Motive: > Basically, I want to achieve simplified dynamic lighting of sorts. > Unfortunately, standard garaud shading "rounds out" the character models > too much. I'm striving for a more cartoonish look, and garaud shading in > many lighting conditions creates too large of a tonal range across the > characters surface. Straight NPR is out of the question because another > reason why I'm looking for other lighting solutions is to eliminate the > need to calculate the characters normals every frame. I'm striving for > advanced character physics so I need the CPU for that as well as some > hefty AI. I've been toying with a couple ideas, but one in particular...It > sounds like a hack that would have been done before the days of T&L, so > it's probably not unique. In either case, I'd appreciate any feedback on > it, especially if you implemented a similar system. I'm also open to > alterations, suggestions, or completely different approaches. > > Specifics: > - characters @ 300-500 polys each > - possibility ~30+ on screen > - cartoonish/simple texturing and visual appearance > - PIII-700 w/ GeForce2 as target platform. > > Method: > The artist defines clusters/groups of vertices on the character that would > be affected if the light was in a particular location in relation to the > character. (i.e. left, right, above, etc...) At run-time 3 planes are > created centered on the character and going in the positive direction for > each axis. (+x,+y,+z) With some simple range checks, the affecting lights > are chosen. Cycle through each plane and figure out what clusters need to > be lit by considering the lights position in relation to the plane. (in > front of z plane = "front" cluster) W then feed the normal, center point, > and the light's properties into a standard lighting equation to get the > appropriate color. We then apply the calculated color to the characters > vertex colors. Repeat for remaining planes then remaining lights. > > Drawbacks that I can foresee: > - lighting won't be remotely accurate for dramatic/exaggerated poses. ex. > light in front of character lighting the "front" cluster and the character > then raises their arms straight up...These actions will probably be quick, > and typically only happen in areas where the contrast in lighting is more > subtle. So, I'm not too worried about this. > - I was thinking of using ambient coloration as the "base" color which is > then adjusted based on the lighting calculations. to do this successfully, > would need to place volumes throughout world to specify the ambient color > for particular regions. would allow the artist to choose the best ambient > color for a particular lighting condition, but requires more work. > > Any thoughts on all of this? :P > > thanks > E. > --- > Eric Maslowski > Eric@... > http://www.msu.edu/~maslows3/ > > PS. I faked this setup a little in MAX and it seemed to give some nice > results, although I wasn't able to see it in motion...the illumination > from a light gave a nice consistent value to all affected vertices without > the "over-shaded" look that straight garaud shading created. with careful > selection for each group/cluster, I was able to get some nice lighting > effects in both subtle and dramatic lighting conditions. > > > _______________________________________________ > GDAlgorithms-list mailing list > GDAlgorithms-list@... > http://lists.sourceforge.net/lists/listinfo/gdalgorithms-list ```
 Re: [Algorithms] Simplified Dynamic Lighting For Animated Characters From: Eric Maslowski - 2001-08-31 01:43:50 ```Hey David, clever method. I never really thought of treating omni's and such as directionals at run-time. makes sense. Are all lights treated equally? (i.e. same falloff and intensity?) Could you give me an example of when you'd bake the lighting calculations, I'm having difficult thinking of one. It seems like if an objetc is dynamic, even if it does come to rest, it has the potential of moving again. do you handle such an event? Now, unless I missed something, it sounds like the method you described, while greatly simplifing the lighting calculations for T&L, still falls victim to the same "over-shaded" look I'm trying to avoid. hmm...maybe I should post a couple screens to demonstrate what I'm talking about seeing as how I'm having difficulty finding the right words.. :) thanks for the response cheers E. On Fri, 31 Aug 2001, David Hunt wrote: > Don't know if this completely relevant - but this is what I'm currently > doing which is also HT&L friendly. > For each moving object each frame I collect each of the affecting lights, > pick the heaviest n of them then replace them with faked > infinite/directional versions that approximate the same behaviour. Eg. A > point light becomes a directional light with direction light->object centre > and so on. > The advantage of doing this is that an infinite light is considerably > cheaper to do the light math on than any other type, it also unifies our > light model so we don't have to worry about any strange light type types > getting through to our render subsystem. > At this point your characters will look very directionally lit - to get > round this I juice a bit of each directional light off into the ambient for > the object - and hey presto. I also have timers running on all dynamically > lit objects which get reset each time it or a light near it moves, when the > timer gets to 0 I bake the lighting into the vertices and turn off dynamic > lighting. > > > David > ```
 Re: [Algorithms] Simplified Dynamic Lighting For Animated Characters From: David Hunt - 2001-08-31 02:25:15 ```> Hey David, > clever method. I never really thought of treating omni's and such as > directionals at run-time. makes sense. Are all lights treated equally? > (i.e. same falloff and intensity?) Not sure what you mean - the system does rely on the assumption that an object is small(ish) relative to the radius of a light - ie a small light next to a large spaceship would fail but a person walking through a room light is fine. Every time the object moves relative to a point light for instance I replace the point light with a directional light which is attenuated by the distance to the light. >Could you give me an example of when > you'd bake the lighting calculations, I'm having difficult thinking of > one. It seems like if an objetc is dynamic, even if it does come to rest, > it has the potential of moving again. do you handle such an event? 1/Every time an object moves it gets thrown in a bucket of objects that need their lights updated. 2/Every time a light moves - all objects within it's influence get thrown in the bucket of objects that need their lights updated. 3/When we process the bucket we unbake all objects that are baked and reset all bake counters. 4/Each frame we count down the bake counter by 1 when it hits 0 we bake. > Now, unless I missed something, it sounds like the method you > described, while greatly simplifing the lighting calculations for T&L, > still falls victim to the same "over-shaded" look I'm trying to avoid. Yes that's true - if you skip the ambient bleed you'll get more dramatically directional light. If you increase the ambient bleed factor you'll feed most of the directional light intensity through to the ambient on the character giving you far flatter shading with subtle highlights. I guess you could consider unifying vertex normals to nearly the same direction over the groups defined by the artist. This still isn't going to give you cartoon shading though just less shading which will change dramatically at the boundaries between groups. > hmm...maybe I should post a couple screens to demonstrate what I'm talking > about seeing as how I'm having difficulty finding the right words.. Ok, good idea David ```
 Re: [Algorithms] Simplified Dynamic Lighting For Animated Characters From: Eric Maslowski - 2001-08-31 02:53:23 ```On Fri, 31 Aug 2001, David Hunt wrote: > Not sure what you mean - the system does rely on the assumption that an > object is small(ish) relative to the radius of a light - ie a small light > next to a large spaceship would fail but a person walking through a room > light is fine. Every time the object moves relative to a point light for > instance I replace the point light with a directional light which is > attenuated by the distance to the light. Ok, that clarifies it for me. thanks. > 1/Every time an object moves it gets thrown in a bucket of objects that need > their lights updated. > 2/Every time a light moves - all objects within it's influence get thrown in > the bucket of objects that need their lights updated. > 3/When we process the bucket we unbake all objects that are baked and reset > all bake counters. > 4/Each frame we count down the bake counter by 1 when it hits 0 we bake. nice. I thought you were originally talking about using some form of a timer where if an object/light hadn't moved for a particular amount of time, you would bake the lighting and never worry about it again regardless of what the object or light did. the above makes alot more sense. > I guess you could consider unifying vertex normals to nearly the same > direction over the groups defined by the artist. This still isn't going to > give you cartoon shading though just less shading which will change > dramatically at the boundaries between groups. I'm not really going for cartoon shading, I just wasn't happy with the shading that garaud did by default. So, yeah, I'm looking for a way to get less shading. I want to do it without using vertex or face normals too because one of the reasons, aside from aesthetic, for considering alternate methods was to eliminate the overhead of calculating vertex normals every update for skinned skeletal animated characters. thanks for your feedback. cheers. E. ```
 RE: [Algorithms] Simplified Dynamic Lighting For Animated Characters From: Jon Watte - 2001-08-31 14:09:36 ```> I'm not really going for cartoon shading, I just wasn't happy with the > shading that garaud did by default. So, yeah, I'm looking for a way to get > less shading. I want to do it without using vertex or face normals too > because one of the reasons, aside from aesthetic, for considering > alternate methods was to eliminate the overhead of calculating vertex > normals every update for skinned skeletal animated characters. thanks for Unfortunately, I think the idea of putting vertices into groups won't really work, because when you rotate an arm 45 degrees, some of the vertices will change groups, and others won't. Unless you do the classification per bone, which gets you into very small and inefficient chunks of vertices. If all you want is less of the goraud, you can try setting ambient around 155 and only let goraud contribute by 100 -- or maybe something even more extreme (200/55 ?) Also, any type of directionally based lighting (anisotropic, spotlight, toon shade, backlit, what have you) can be put in the second texture stage as a cube map in normal texgen mode instead of reflection (assuming OpenGL here). Anyway, I wouldn't worry too much about the overhead of calculating the normals when calculating the vertices in your skinning. With the appropriately strucutred code and render pipeline, it's really not all that much more expensive. In the renderer I'm working on, once we turned on SSE skinning code and proper vertex buffer streaming, the bottleneck clearly shifted to elsewhere. Cheers, / h+ ```
 RE: [Algorithms] Simplified Dynamic Lighting For Animated Characters From: Eric Maslowski - 2001-08-31 17:50:42 ```Hey Jon, > Unfortunately, I think the idea of putting vertices into groups won't really > work, because when you rotate an arm 45 degrees, some of the vertices will > change groups, and others won't. Unless you do the classification per bone, > which gets you into very small and inefficient chunks of vertices. I initially thought of doing a plane/group per bone, but, as you said, that is quite inefficient particularly with such low-poly characters. So, I was thinking of having the groups be fixed. this obviously introduces inconsistences when various limbs are at certain angles, but they may not be that noticeable at smaller angles and when in motion. If the dynamic lighting is used solely for adding subtle hints of specific light sources, I would think the inaccuracies would be even less noticeable. Now, there would a couple rare cases where the lighting is more dramatic. in these cases the inconsistencies would be highly noticeable; however, such scenes would also have alot of other things happening, so once again, not sure if it would be acceptable... > If all you want is less of the goraud, you can try setting ambient around > 155 and only let goraud contribute by 100 -- or maybe something even more > extreme (200/55 ?) I'll play with this a bit to see what kind of effects I can get, but I'm not sure if it can give me the uniform lighting I'm going for. It seems like it'll give me better contrast along the boundries of the lit/unlit surface, which is good, but I would think that it would still have a large tonal range between those boundaries. Do you think this will be the case? > Also, any type of directionally based lighting (anisotropic, spotlight, toon > shade, backlit, what have you) can be put in the second texture stage as a > cube map in normal texgen mode instead of reflection (assuming OpenGL here). true. didn't really consider this approach yet...wouldn't multiple light sources eat up all the available texture stages? (ie. one texture for each light) I'm not familiar with implementing these methods, so I really don't know how they explicitly work. > Anyway, I wouldn't worry too much about the overhead of calculating the > normals when calculating the vertices in your skinning. With the > appropriately strucutred code and render pipeline, it's really not all that > much more expensive. In the renderer I'm working on, once we turned on SSE > skinning code and proper vertex buffer streaming, the bottleneck clearly > shifted to elsewhere. Relatively speaking, you're probably right, it isn't that much more expensive. However, if by getting rid of it I can add 5 more characters on screen, use a really great physics system for the characters, or update the AI more frequently then that seems more beneficial to me...as long as it doesn't look like arse as a result of the cutbacks :P cheers E. ```
 RE: [Algorithms] Simplified Dynamic Lighting For Animated Characters From: Jon Watte - 2001-09-03 17:04:52 ```> > If all you want is less of the goraud, you can try setting > ambient around > > 155 and only let goraud contribute by 100 -- or maybe something > even more > > extreme (200/55 ?) > > I'll play with this a bit to see what kind of effects I can get, but I'm > not sure if it can give me the uniform lighting I'm going for. It seems > like it'll give me better contrast along the boundries of the lit/unlit > surface, which is good, but I would think that it would still have a large > tonal range between those boundaries. Do you think this will be the case? If all you want is to reduce the "tonal range" then having your diffuse light contribute only a little bit (the 200/55 division) will take care of that. However, the distance over which this range fades (the transition between lit and shaded) is still fairly wide, in angle-over-surface terms. > true. didn't really consider this approach yet...wouldn't multiple light > sources eat up all the available texture stages? (ie. one texture for each > light) I'm not familiar with implementing these methods, so I really don't > know how they explicitly work. Basically, the normal direction at the point you're rendering is used to look up a texel in a cube map (which consists of six separate square textures, conceptually) -- after that, it's all regular multitexturing. If you have multiple lights that you want to take into consideration, you'll have to generate the cube map once per frame, from the point of view of the object -- perhaps you could cache it and only regenerate it if the object/lights moved "enough". To get a crisp transition band, you'd render this cubic light maps as medium gray background (for shadow) with white, softed circles(*) for the positions of the lights. This may get expensive quick, though; especially if you want to do it once per skinned character per frame (although still cheaper than true dynamic environment maps, as the poly count is just one quad per light -- the cost should be all in the set-up overhead). > Relatively speaking, you're probably right, it isn't that much more > expensive. However, if by getting rid of it I can add 5 more > characters on screen, use a really great physics system for When I measured it, it was more like one-half more character on the screen. But the stuff I'm working on has substantial other costs per character, besides rendering. > the characters, or update the AI more frequently then that seems more > beneficial to me...as long as it doesn't look like arse as a result of > the cutbacks :P The only way to be sure is to code up a benchmark and profile it. Of course, correct profiling in today's world of highly cache dependent algorithms and hardware T&L & fill parallellism starts getting REALLY close to building the real thing. Cheers, / h+ (*) actually, you want circles as projected onto the cube map, which stretches them in funny shapes. Luckily, if you use hardware to render the cube maps, it does it for you as part of the projection matrix. ```
 RE: [Algorithms] Simplified Dynamic Lighting For Animated Characters From: Eric Maslowski - 2001-09-03 22:08:20 ```> If all you want is to reduce the "tonal range" then having your diffuse > light contribute only a little bit (the 200/55 division) will take care of > that. However, the distance over which this range fades (the transition > between lit and shaded) is still fairly wide, in angle-over-surface terms. Yeah, I'm looking for a combination of both effects. More contrast (ie. harsher transitions from lit to unlit) for the edges and less tonal variation within the lit and unlit portions. > Basically, the normal direction at the point you're rendering is used to > look up a texel in a cube map (which consists of six separate square > textures, conceptually) -- after that, it's all regular multitexturing. If > you have multiple lights that you want to take into consideration, you'll > have to generate the cube map once per frame, from the point of view of the > object -- perhaps you could cache it and only regenerate it if the > object/lights moved "enough". To get a crisp transition band, you'd render > this cubic light maps as medium gray background (for shadow) with white, > softed circles(*) for the positions of the lights. This may get expensive > quick, though; especially if you want to do it once per skinned character > per frame (although still cheaper than true dynamic environment maps, as the > poly count is just one quad per light -- the cost should be all in the > set-up overhead). Thanks for the update on cube maps. :P Sounds like updating the cube map every frame or so will cost too much for the project I'm working on... > When I measured it, it was more like one-half more character on the screen. > But the stuff I'm working on has substantial other costs per character, > besides rendering. thanks for doing the test. characters will have quite a few costs other than rendering for my project too. That's why I'm trying to get the rendering portion simplified enough so the rest of the features can make it into the project. You're right, that the only way to really know is profile and do a test app...thanks for your help. it definitely helped me realize the other options out there. Well, time to play around with this. :P thanks again for yours, and everyone else's help. E. ```
 Re: [Algorithms] Simplified Dynamic Lighting For Animated Characters From: Eric Maslowski - 2001-08-31 02:26:43 ```Ok, I did a real quick aproximation of what I'm trying to achieve. I put a directional light in MAX to light the character and took a screenshot of the viewport using the OpenGL renderer. I then aproximated the results of what I described before by selecting groups of vertices based that would be lit if the light was in a particular location, (left,right.etc..) and went through the motions described previously. Not accurate by any means, but it illustrates the general look I'm going for. (FYI: I'm going for the one on the right. ;) http://www.msu.edu/~maslows3/temp/lighting_compare.jpg E. ```