Poor Support for Dynamic Number of Lights in GLSL Mode #40086

New Issue

Mitchell Stokes · 2014-05-08T02:50:53+02:00

Mitchell Stokes commented

2014-05-08 02:50:53 +02:00

Our GLSL shaders assume a fixed number of lights (the lights available in the Blender scene when the shader is generated). This causes issues when adding lamps to the scene with add object (#20275) or adding new lights via libload (#27030).

Some possible solutions:

Recompile shaders when the number of lights change. The problem with this is recompiling shaders can be slow, especially with lots of materials and no shader cache (I think only NVIDIA cards have a shader cache at the moment).

Change where shaders get light data from. We could pass an array of light structs (e.g., via uniform buffer objects) to shaders. This would allow us to change the number of lights in a scene (up to some maximum array size, unless we do texture objects, but that seems silly) without recompiling shaders. Unfortunately, this would introduce looping and branching into the generated code, which could slow down our shaders.

Move away from forward rendering. Techniques such as deferred/inferred rendering/lighting grab light data from a buffer that is filled at render time. This allows for a lot of dynamic lights, but we probably wouldn't want to drop our forward rendering, so this would only be a partial solution.

Our GLSL shaders assume a fixed number of lights (the lights available in the Blender scene when the shader is generated). This causes issues when adding lamps to the scene with add object (#20275) or adding new lights via libload (#27030). **Some possible solutions:** **Recompile shaders when the number of lights change.** The problem with this is recompiling shaders can be slow, especially with lots of materials and no shader cache (I think only NVIDIA cards have a shader cache at the moment). **Change where shaders get light data from.** We could pass an array of light structs (e.g., via uniform buffer objects) to shaders. This would allow us to change the number of lights in a scene (up to some maximum array size, unless we do texture objects, but that seems silly) without recompiling shaders. Unfortunately, this would introduce looping and branching into the generated code, which could slow down our shaders. **Move away from forward rendering.** Techniques such as deferred/inferred rendering/lighting grab light data from a buffer that is filled at render time. This allows for a lot of dynamic lights, but we probably wouldn't want to drop our forward rendering, so this would only be a partial solution.

Mitchell Stokes commented

2014-05-08 02:50:53 +02:00

Changed status to: 'Open'

Mitchell Stokes commented

2014-05-08 02:50:53 +02:00

Added subscriber: @Moguri

blender-admin commented

2014-05-08 02:50:53 +02:00

#27030 was marked as duplicate of this issue

blender-admin commented

2014-05-08 02:50:53 +02:00

#20275 was marked as duplicate of this issue

Mitchell Stokes commented

2014-05-08 02:51:13 +02:00

Added subscriber: @kupoman

Mitchell Stokes commented

2014-05-08 02:52:36 +02:00

Added subscribers: @qwertyuiopia, @iflowproduction, @ideasman42, @brecht, @chewbacca, @dfelinto

Mitchell Stokes commented

2014-05-08 02:52:36 +02:00

◀ Merged tasks: #27030, #20275.

Jorge Bernal commented

2014-05-09 08:10:00 +02:00

Added subscriber: @JorgeBernalMartinez

solarlune commented

2014-05-09 17:21:44 +02:00

Added subscriber: @solarlune

Kevin Ednalino commented

2014-05-17 02:07:38 +02:00

Added subscriber: @mahalin

Mitchell Stokes changed title from ~~Poor Support Dynamic number of Lights in GLSL Mode~~ to Poor Support for Dynamic Number of Lights in GLSL Mode

2014-05-20 08:40:17 +02:00

Jacob Merrill commented

2014-05-20 08:47:58 +02:00

Added subscriber: @JacobMerrill-1

Mircea Kitsune commented

2015-02-10 21:35:52 +01:00

Added subscriber: @MirceaKitsune

Jacob Merrill commented

2015-02-10 21:47:36 +01:00

I would love to see support for deferred rendering,
would it simplify the rendering code or complicate it more?

would the core dvelopers need deferred rendering of openGL
in the UI? for creating and viewing game assets like maps?

maybe you could work together to impliment it in the UI /ainimation suite first
then adapt the code for the bge? roll in OpenES support while your at it.....

I wish I were a better coder so I could help, but I am still learning,

I would love to see support for deferred rendering, would it simplify the rendering code or complicate it more? would the core dvelopers need deferred rendering of openGL in the UI? for creating and viewing game assets like maps? maybe you could work together to impliment it in the UI /ainimation suite first then adapt the code for the bge? roll in OpenES support while your at it..... I wish I were a better coder so I could help, but I am still learning,

Kevin Ednalino commented

2015-02-11 23:24:25 +01:00

Removed subscriber: @mahalin