Hi all;
Im falling back to lightmaps lighting (my engine currently does only dynamic lights), but im having some troubles about lighting in dynamic objects…
I saw in games such CS that they use the lightmap value under the character to calculate the ilumination…how to do that, if my textures r in video ram? i wanna make something like this: whn a player leaves the outdoor, where the Sun is the main light, and enter in a building, the Sun doesnt affect it anymore, but when the plaers stands on an opened window, the Sun hits him again …how to fake this?
i assume u mean static lights, i believe most games devide the gamearea up into many subareas eg octree, and then check what area the thing is in, in this area u precompute what lights are visable, sun through a window is nicely done with a projected texture
Ok, i get what u mean…but does anybody know how to get the lightmap intensity at a given point, like its done in HL?
You can figure out what triangle he’s standing on, yes? So now you need to know what the uv coordinates are at that point on the triangle. Then you can just use the uv’s to look up the luminance value from your lightmap texture.
It’s pretty much dependent on your render architecture, so there’s no single answer to your question, besides the fact that it has absolutely nothing to do with opengl.
Thanx for replying…my problem is: my lightmaps r in video memory, so to get a value, the easiest(but most expensive i think) is to render a pixel with the UV coordinate of current player position, with the lightmap binded, and do glReadPixels(…), getting the color…but i think its not the fastest way…
Quake (including Half-Life) uses a light grid, much like zed said. A low-res 3D-texture covering the scene with light intensity values. Generated in the light mapping process.
No quake3 uses the lightgrid, quake1 just keeps the textures in system memory (besides the copy in texture mem). Just check the code in the quake1 engine if you want to know how it is done exactly.
I think lightgrids (3d texture style) are more interesting on modern systems tough.
Originally posted by Coluna:
Thanx for replying…my problem is: my lightmaps r in video memory, so to get a value, the easiest(but most expensive i think) is to render a pixel with the UV coordinate of current player position, with the lightmap binded, and do glReadPixels(…), getting the color…but i think its not the fastest way…
You put the data into the lightmap, right? It should be trivial to just keep a copy. This is your best bet if you’re concerned about performance. Keeping copies costs only virtual memory space, and that’s not generally a huge problem.
If it is, use glGetTexSubImage to get a texel directly out of the light map. But that may be just as inefficent as glReadPixels, depending on whether or not the GL driver keeps a system memory copy itself.
If you really want to avoid all the other (preferred) solutions you’ve been proposed, then you could compute on the CPU the u/v coordinates of your player standing on the ground, bind the ground lightmap, bind these values as constants, and fetch the lightmap value in a fragment program, then do what you need to do depending on the result of that fetch.
The only part you need to do on CPU is get the corresponding lightmap, and get the u/v of your player on that lightmap. Anyway, this is a bad idea, as the “ground value” is not relevant (your player could have the sun light its torso, but not its feet). What’s more, the routine that will get these values could easily be extended to do what previous posters suggested.
SeskaPeel.
I might have the wrong idea of what you’re looking for, but you could create a sort of Static “Light Volume”, the opposite of a shadow volume. You could increase the light intensity of objects inside the volume, or similarily to demo programs that “display the shadow volume” you could use the technique to render a “shaft of sunlight” coming in through a window.
… of course you’d have to render shadows for all ojects entering into the light volume…
Later,
Mike