2010-09-08, 12:43 PM
The most interesting unified map lighting model I can come up with off hand would be to "repaint" the per vertex colours generated by the light calculation algorithm with 24bit lighting normals (not quite the usual 96bit but probably acceptable) then use the remaining 8bits as a lookup into a palette with 256 slots that store 4 light ids. Every light in Som has an id which is probably stored in the maps but basically I think whenever Som opens a map it reserves that many D3D lights. So each component of the texture is one of these light IDs (up to 256 lights) which basically defines up to four lights to knockout for per vertex shadows. With that capability it should be possible to replicate the classic lighting model while unifying it with the object lighting.
The lights you'd knockout that way would most likely be fixed in location relative to the map piece. You could move the lights around at that point but the shadow would not move. You could change the color/intensity of the light, turn it off and on for example without any trouble.
This idea came pretty quick but I had to really think about how to figure out if a light was knocked out in the vertex shader for a while... then I realized you could subtract the lights id from each id in the set of four ids... then if it matched one that component would end up to be zero, then multiply the four components by themselves and if one is zero they all become zero... then depending on what shader model you're in you can conditionally skip the light or do the calculation and multiply it by the zero to get no light contribution.
A program could be written to automate everything / spit out a new map file, and you could store both sets of map files (old and new) in your game and let the player decide which set to use. It might even be possible to tessellate the map so the vertex lighting would be more uniform/precise.
At that point you really do some interesting things with lights like make magic fireballs be a new "lamp" in the map or let the player cast a spell to create a light source around them (or equip a torch) or whatever.
EDITED: Also I think it might be way more efficient to replace the global map lighting with a cubemap because that's really all it's doing (versus 4 lighting calculations) and you could even have a bit more control with a cubemap.
The lights you'd knockout that way would most likely be fixed in location relative to the map piece. You could move the lights around at that point but the shadow would not move. You could change the color/intensity of the light, turn it off and on for example without any trouble.
This idea came pretty quick but I had to really think about how to figure out if a light was knocked out in the vertex shader for a while... then I realized you could subtract the lights id from each id in the set of four ids... then if it matched one that component would end up to be zero, then multiply the four components by themselves and if one is zero they all become zero... then depending on what shader model you're in you can conditionally skip the light or do the calculation and multiply it by the zero to get no light contribution.
A program could be written to automate everything / spit out a new map file, and you could store both sets of map files (old and new) in your game and let the player decide which set to use. It might even be possible to tessellate the map so the vertex lighting would be more uniform/precise.
At that point you really do some interesting things with lights like make magic fireballs be a new "lamp" in the map or let the player cast a spell to create a light source around them (or equip a torch) or whatever.
EDITED: Also I think it might be way more efficient to replace the global map lighting with a cubemap because that's really all it's doing (versus 4 lighting calculations) and you could even have a bit more control with a cubemap.