Best Dynamic Lighting method for levels?
Blitz3D Forums/Blitz3D Programming/Best Dynamic Lighting method for levels?
| ||
| I've got player/prop lighting sorted, thanks to cube maps. But the level is lightmapped, so no good for vertex lighting. I could map a light texture to the level, but that means multiple passes(1 for each light)..So, is there a better way to do it all in one pass(or two/three, as long as it doesn't mean more passes for each each additional light). I've heard of dynamic sphere mapping..can't find any tutorials on it though. |
| ||
| "But the level is lightmapped, so no good for vertex lighting." Not true. It is possible to render a level so that vertex lighting brightens lightmaps. This comes at the cost of one additional surface for every surface in your level supporting up to 8 vertex lights. However the only other method I can think of which you might use, dynamic lightmaps, would come at an even greater cost, of one additional surface per surface, per light. Here's how to set up the lightmaps so vertex light affects them: Imagine you have a mesh with a simple quad. This represents a wall. First, you add a surface to the mesh which contains the quad. This is textured with the texture normally. Lighting is disabled for this surface. Second, you add another surface to the mesh. This surface should contain new polygons at the same location as those in the first. This surface IS affected by lighting, and is textured with the lightmap, but the lightmap is set to ADD blend. Now here's what happens: Blitz renders surface 1... all polygons within it, with the texture, to the screen, fullbright. Blitz then render surface 2 and all it's polygons on top of the first set of polygons. Now assuming you have no dynamic lights, the underlying mesh color will go from white to black, because it is not being lit. HOWEVER, the lightmap layer is set to add blend, so when this is blended with the object color, black, because we have no lights, this becomes white where there is light, or other colors where the lightmap is other colors. On the other hand, if you add a light to the scene, or have ambient light, this light will make the lightmap surface base color lighter in those locations. The lightmap then adds with that. And everywhere where the object is no longer black because of a lack of light, the blackness of the lightmap in those locations will not show, as black + some base color = base color. A few last things... The ligthmap surface (not the texture layer) can be set to multiply x2 so that the lightmaps brighten the textures as well as darken them. This looks better than just darkening them. With this method, fog may not work properly. I beleive the lightmaps will lighten some areas of the fog. I'm pretty sure fog will not affect add blended textures. One more thing... For vertex lighting to look okay you'll have to subdivide the walls a bit. But cards today can push so many polygons that's probably not a problem. |
| ||
| Nice and thorough explanation swifty -- all very straightforward and logical. Thanks for sharing. |
| ||
| I think "decal" lights, where a texture is rendered on the wall in a second pass, are best for weapon flashes, etc. If you terrain is high-res enough, use hardware lights, otherwise use decal lights. They look about the same on a high-res terrain, but decal offers a little more control. Your characters and moving things should each be rendered in a separate pass, where you set up lighting based on what lights are visible to the player. Use a visibility line check, and you will get a good approximation of the correct lighting when standing in the shadows or in direct light. |
| ||
| Yeah thanks swwift/halo. Think I'm going to try dynamiclightmaps first..can't stand the idea of additional passes per light. Halo, the only problem I see with the decal method is on curve geo. Do you wrap the decal around it, or just align a quad to the surface normal? |
| ||
| I only use these on brush geometry. |
| ||
| "Think I'm going to try dynamiclightmaps first..can't stand the idea of additional passes per light." Dynamic lightmaps are what require additional passes per light, not dynamic vertex lights. One additional pass is required for X number of vertex lights, X being the number of dynamic lights your card supports. You can't exceed X, but X is probably 4 or 8 which is better than 4 or 8 passes with dynamic lightmaps either way. |
| ||
| I only use these on brush geometry. Brush geometry can still have bevelled edges and such. Are you wrapping to the shape of the geometry or just aligning a quad? |
| ||
| Dynamic lightmaps are what require additional passes per light, not dynamic vertex lights. One additional pass is required for X number of vertex lights, X being the number of dynamic lights your card supports. You can't exceed X, but X is probably 4 or 8 which is better than 4 or 8 passes with dynamic lightmaps either way. Yeah, I mean in additional passes in terms of gpu hits. The method I'm using, goes through all recievers and sets up a list of tris, and does all the prep work, so come run time I just have to render 16x16 (or less if I want, variable) pixels per poly. Since the texture is flat, I can probably trform it into a already rendered spherical light and can then reduce it to one copyrect per poly, per light, hardly any maths.. Should mean per-pixel lights/fast enough for high speed set ups.(Not up and running yet..will post a demo if it goes well anyway) Halo, I meant level wise. The lights I'm using only need to light level geo, which is curved/flat..never use brushes myself. |
| ||
| Unless Halo is not wrapping his "decal" to the surface of the level... Which would produce really stupid looking results, (a big fuzzy circle pressed up against the wall that sticks out when it is a near a corner) then the method he suggests is likely too slow to use. If you're talking about rendering Quake-like dynamic lights, by using a spherical lightmap, comprised of one 2d map and one 1d map mapped on perpendicular axes to produce a "spherical" region of light, then that is stimply not going to be fast enough fro realtime except on the simplest of levels. I can say this with fair certainty, because in essence, doing this is very much like rendering shadows in my shadow system. For maximum speed, what you would end up doing is having to clip all the polygons in your level, or at least, all those in sections that are currently visible, using sutherland-hodgeman clipping. You would clip them to a cube which defines the region of the spherical light, with the cube's borders being the maximum extent of the light. The result of this clipping is a list of clipped polygons that you then need to build into a new mesh with proper lightmap coordinates. But clipping polygons is not free, nor is building new meshes. And because this is so similar to how my shadow system works... except for the fact that you will be "shadowing" roughly six times as many polygons per light, as each light effectively casts in all directions whereas a shadow casts in only one, this is how I can predict the speed of such a system as being slower than my shadow system by a significant degree. Plus, because lights will cover such large areas in all likelyhood, they will create more overdraw than my shadow system as well. |
| ||
| It's easy. Your system sucks. |
| ||
| His shadow system works fines. In the current built of cryo there's two static lights casting 4 shadows of 1,000poly+ animated characters+weapon, plus a moving light, in total 6 shadows, plus every gun shot casts shadows from the muzzle, + all the game's other stuff/lighting, and still runs ok on a p-800. I don't think you could do shadows much faster in blitz alone. though I'm going to port as much as I can to C++, use coldet for collisions..should speed it up even more. Anyway, swwift, when you say it's too slow are you on about what I suggested or halo? The way I does only updates polys within the light's radius, and they don't cast shadows. (only characters cast real time shadows, done seperately) And does it all in one pass(accumlative r+g+b) on the original mesh, no copies generated. |
| ||
| Halo: Your wit is razor sharp as always! Dude: If I am not mistaken, my last benchmarks showed that the major bottleneck is not the actual clipping of the polygons, but rather, the creation of the shadow mesh itself. And by that I mean, the act of adding polygons to a mesh, not of determining the locations of said polygons. Perhaps I will do another check now and be sure of this. |
| ||
| Oooh, this thread is good enough to eat. Shame none or it is any good for my text adventure game - unless, I use a 3D, stone effect, alphabet. |
| ||
| sswifts system is too slow for general levels. I suspect something similar would be ideal if used on bsp style levels with proper culling. The 2 surface idea is good but it's the same as overlaying another mesh isn't it? So thats like 2 pass rendering. |
| ||
| Anyone who uses the word "wit" is looking for a good ass-kicking. What are you, British? BL, I use multipass and 2 surfaces interchangably, since they are really the same thing. Using 2 surfaces in one pass does give a little better results when z-fighting is an issue. You have the right idea with BSP. Just use a point-plane distance function to see if the light affects the plane, then offset and scale the light texture to fit the setting (faster than changing UV coords) and render a copy of the plane. It's really fast, and works fine for big maps. You probably only have a light calculation every other second, and maybe a couple of moving dynamic lights. |
| ||
| I can't help but laugh at Americans who think they're being clever demeaning British people. Without us, there would be no you. I repeat, YOU WOULD NOT EXIST. At the very least you'd all be speaking french! Is that what you want!? You'd all be canadadian bacon hey. Anyway seriously, Halo, a few issues pop up in my head trying to visulize your technique, again curved surfaces. In case I'm doing an half arsed job of explaining it, Imagine any non flat surface in game...(Like say a lamp shade, or a football. Any back ground non moving geo) There's no way a plane can wrap around those sort of surfaces, as far as I can see. (Automatically that is, obviously nothing's impossible if you're manually wrapping the plane.. but then it wouldn't be a plane except for it's initial projection. I'm not knocking it, just trying to understand how you're avoiding these problems, or if you just live with them? |
| ||
| You only use these for walls and floors, stuff made out of brushes. There is no good way to dynamically light your merged static meshes. I am assuming all your lamps, etc. will be merged into a single mesh, or groups of meshes. You might be able to render a copy of the mesh in a second pass, with a light mapped into it. |
| ||
| "Anyone who uses the word "wit" is looking for a good ass-kicking. What are you, British?" Anyone who thinks the word "wit" is used solely by the British must have an incredibly small vocabulary. What are you, from California? |
| ||
| There is no good way to dynamically light your merged static meshes. I am assuming all your lamps, etc. will be merged into a single mesh, or groups of meshes. You might be able to render a copy of the mesh in a second pass, with a light mapped into it. Actually nah, as actors/props(Be it soldier or say computers) are seperate for lod, and cos they use a custom cubic lighting engine the game has, per pixel lights, which believe it or not is done with 1 texture in one pass, no matter how many lights there are. Character lighting will be the same again ;) if only levels were so damned easy.. Will give your method a go anyway, the real-time lightmap idea is too slow currently.. |
| ||
| Dude, I am smarter than you, and cooler. |
| ||
| Dude, I am smarter than you, and cooler. That's like a nickel bragging to a penny. |
| ||
| Dude, I am smarter than you, and cooler. I would disagree, but you've managed to sell thoushands of copies of programs that don't work...so you must have something going on up there. as for the cool remark, i'll reserve judgement until your next political rant. They're ice baby. |
| ||
| Actually, I mean that towards "swift" not "dude". |
| ||
| Actually, I mean that towards "swift" not "dude". Oh...well in that case sorry. I oughta change my name, too many californians around here.;p |
| ||
| erm... Ok... back to dynamic lighting... Can anyone link some Kewl example code or NEthing to help me or NEone else? That would be nice... |
   |