Jump to content
  • Advertisement
Sign in to follow this  
nickyc95

OpenGL Best way to handle multiple lights

This topic is 804 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

Hi there,

I am currently in the process of developing a game engine and I am now at the point where I am going to implement lighting.

I have done lighting before, but wanted some input on the best way to handle multiple lights in a FORWARD RENDERER (I will implement Deferred later on).

(Currently using OpenGL 3.3)

There are 2 ways I can think of:

1 - Have a shader per light type and draw the mesh for each of the different lights, using each of the shaders

2 - Upload an array of lights into a single shader, and do a single draw of the mesh looping over the lights each frame


Can anyone provide me with some information regard the performance of the two methods, or any alternate methods that would be better than the ones provided.


Thanks

Share this post


Link to post
Share on other sites
Advertisement

If the result of my google-fu-ing is correct, OGL 3.3 is basicly targeting D3D10 level hardware, so Shader Model 4 equivalent GLSL is supported, meaning that there is no upper limit on the instruction count in one shader. In this case the second option will be the winner. With the first one you have to render every mesh N times if you have N lights in your scene, which gets really expensive really fast, and wastes a lot of resources (from the CPU side you have to send multiple draw commands per mesh, on the GPU side every pipeline stage would do the same thing, apart from the pixel shader, each time you render with a different light). The first option was what we used before SM4 hardware, where the length of the shaders were limited, it was basicly the reason why deferred rendering got so popular. (With N light and M meshes on SM3 level hardware you needed N*M draw calls with forward rendering, but only N+M with deferred.)

Share this post


Link to post
Share on other sites

If the result of my google-fu-ing is correct, OGL 3.3 is basicly targeting D3D10 level hardware, so Shader Model 4 equivalent GLSL is supported, meaning that there is no upper limit on the instruction count in one shader. In this case the second option will be the winner. With the first one you have to render every mesh N times if you have N lights in your scene, which gets really expensive really fast, and wastes a lot of resources (from the CPU side you have to send multiple draw commands per mesh, on the GPU side every pipeline stage would do the same thing, apart from the pixel shader, each time you render with a different light). The first option was what we used before SM4 hardware, where the length of the shaders were limited, it was basicly the reason why deferred rendering got so popular. (With N light and M meshes on SM3 level hardware you needed N*M draw calls with forward rendering, but only N+M with deferred.)

 

Hi , thanks for the reply.

 

This is what I thought, just wanted to make sure  :P

 

Although, I read somewhere that looping or branching in shaders is not very efficient. Is this true and would it cause an issue using method 2?

 

Thanks

Share this post


Link to post
Share on other sites

Assuming you're using shader based lights, and not hardware (which is limited), you'll find yourself running into problems with multiple lights in forward rendering.

For simple scenes, the forward rendering technique will be fast with lighting. But as you increase in the amount of lights in the scene along with geometry, you'll start slogging through a marsh of complexity.


To the related note:

It's pretty common to upload a list of effecting lights per object. Or to test against all lights within the scene or frustum.

Share this post


Link to post
Share on other sites

2 -Upload an array of lights into a single shader, and do a single draw of the mesh looping over the lights each frame


A modern variation on this would be tiled forward rendering or "Forward+", where you iterate over a list of lights per screen tile instead of per mesh.

Share this post


Link to post
Share on other sites

 

2 -Upload an array of lights into a single shader, and do a single draw of the mesh looping over the lights each frame


A modern variation on this would be tiled forward rendering or "Forward+", where you iterate over a list of lights per screen tile instead of per mesh.

 

I think you'd need compute shaders for that, which aren't available at the GL level he is targeting.

Share this post


Link to post
Share on other sites

 

 

2 -Upload an array of lights into a single shader, and do a single draw of the mesh looping over the lights each frame


A modern variation on this would be tiled forward rendering or "Forward+", where you iterate over a list of lights per screen tile instead of per mesh.

 

I think you'd need compute shaders for that, which aren't available at the GL level he is targeting.

 

 

Compute shaders in general can be simulated on old GL and DX levels with a little effort (although you need shaders at least). Use pixel shaders to do the compute shader work, receive all input you need from textures which don't contain image data and instead whatever application data you need, and set up render targets such that your pixel shaders output the stuff in some kind of format you can read from later. Of course, more expensive and restricted than actual compute shaders, but if you want to do stuff on the GPU and don't have compute available it often still is an easy performance win (for particle systems for example). 

 

Would be interesting to see those lighting and light culling algorithms applied to something like WebGL (if it is possible at all, given the limitations).

Edited by agleed

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.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!