Jump to content
  • Advertisement
Sign in to follow this  
Bow_vernon

OpenGL rendering map with more than 4 lights

This topic is 2583 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Sorry if the title is a bit unclear. I'm playing with shaders and now I can render objects with max 4 lights. Each object is assigned the most affecting lighting near them. Now I'm about to do lighting on the map. And here is the problem. When rendering objects, I can "cull" the closest lights for each object, but how about a map? should I cull per vertex of the map (which sounds CRAZY), or what? I have tried the deferred shading approach but it's too overkill for my simple case and I've seen many games (which do not use deferred shading) have more than 4 lights in their map, and they don't even use lightmap (cause the lights are moving).
Do you know any way that will work in my case? and if you need more info, just ask. I'll happily answer.

I program in C++ using SDL + OpenGL + GLSL. Thanks before!!

Share this post


Link to post
Share on other sites
Advertisement
I'll try to shoot in a few directions as an elaboration to your question.
When rendering objects, I can "cull" the closest lights for each object, but how about a map? should I cull per vertex of the map (which sounds CRAZY), or what?[/quote]But... there's no such thing as a "map" as a whole. At the very least, a "map" will be an assembly of static geometry. Various chunks of materials: ideally you could light each chunk independently. Ok, I admit it's no much of a big deal.

Back when GPUs were stupid, the CPU would light the vertices and upload a new stream of (per-vertex) lighting data each frame. Sounds horrible nowadays, but it works (albeit per-vertex lighting is not really a quality solution).

Multipassing is another possibility. Basically, to render N lights, the system would render N/M times the same frame (M being the number of lights to be computed in a single pass), accumulating the results. Then another frame would be rendered, and the colors would be multiplied by the pre-existing light data in the frame buffer. It has demonstrated to be a flexible technique with affordable cost.

There's always the opportunity to bump shader complexity - GeForce6 is able to compute like 30+ light per pass although performance will likely suffer (caveats apply), and it's also possible to just play tricks such as spherical harmonics or ambient cubes...

Share this post


Link to post
Share on other sites
Hi Krohm, and thanks for the respond :) btw my map is a tile-based map, and they're assembled into one big vertex buffer. Currently, I cull the lights for each for each vertex (it sounds horrible, I know) and I don't move the lights too much. Basically the light will traverse the octrees (which contain vertices at the leaf), and tell the vertices to add this light to its reference. It is done everytime the light changes position (for positional lights). It worked well, altho I'm a bit worried. But all in all, it just works.

Btw if anyone knows a way to optimize the method, I'm all ears :D

Share this post


Link to post
Share on other sites
Are these static lights or moving? You can pass a 1D texture that holds all the lights data in (rgb) pixel. Then for each vertex give it an attribute of rgba for 4 light indices. Those look into the 1D pixels to grab the positions. You can put the lights materials in another 1D texture as well.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!