GEM: is there a way to increase (perhaps hack) the limit on the number of GEM/OpenGL lights above 8
PD-0.42.5-extended-20100501 on Mac OS X 10.8.5.
I have just returned to examining an old GEM project that uses an ambitious (or foolish) 60 (!) GEM lights to simulate 30 real LEDs, using 1 [light] and 1 [spot_light] combined for each LED, achieving a nice effect. But only some of the GEM lights seemed to have any effect. On reading the GEM manual again I easily found out why (I had not paid enough attention to the console error messages).
At http://puredata.info/downloads/gem/documentation/manual/manual/lighting it clearly states:
'GEM has only a maximum of 8 lights at one time. If you try to create more lights than that, you will get an error message.'
(BTW it might be a good idea to include this fact in the basic help docs for [light] and [spot_light] if it has not already been included in a more recent version of Pd, I am using an older version).
Q: Is there any known way to "hack" GEM+OpenGL to increase the number of supported lights ?
I found a discussion on the limit of 8 light as stated in the OpenGL Redbook from 31 Aug 2010 at:
http://stackoverflow.com/questions/3583735/opengl-lights-limit
'8 lights is the limitation of fixed GL pipeline, where you enable each of them, set mode, parameters, etc. Now you have pixel shaders, and lighting is done within shader. There you can use large number of dynamic (not backed into textures) lights. You only need to supply all these lights' parameters sufficiently (maybe, in a texture), and test how many lights your shader is able to process. Also, in shader you can cull too weak lights (contributing too little into pixel value) or just too distant ones.
Update: complex shader with branching can even generate lights (think of long street or christmas tree). It could be more efficient than supply large number of parameters. (alxx)'
I appreciate any feedback on how one might get around this 8 GEM light limit. I am willing to play with code hacks and recompilations on Mac OS X for this particular task. Indeed I am basically willing to melt my MacBook Pro to get this to work with 60 GEM lights.
For the sake of this forum question, it does not matter why I need to have a whopping 60 GEM lights; The real-world system I am simulating with GEM has 30 actual LEDs in it, there is just no way around that. And the LEDs have to be able to move (translate/rotate), and they have to really act like moving, shining, driven lights.
I can compromise a bit on the combination of [light] + [spot_light] for each simulated LED but it's not as nice (noting each LED also has a backing reflector, also simulated in GEM).
The effect with just 4 simulated LEDs = 8 GEM lights (3 x ([light]+{spot_light]) is quite gorgeous already.
But I do really need 60 GEM/OpenGL lights in one scene somehow to complete this simulation properly (noting the main point of the exercise is to actually simulate many LED lights, it's just a light-rich problem). The effect with the real-world system with lots of real LEDs is absolutely stunning.
Ultimately, I want to have many sets (each in a Pd patch) of 30 simulated LEDs, i.e. many sets of 60 GEM/OpenGL lights. It's easy of course to wish for things.
Glad for any tips,
Darren Kelly
PS: And in case you are wondering, not it's not a simulation of an Xmas tree full of LEDs, although being able to simulate 30 LEDs or more in GEM would be a nice early Xmas prezzie for me.
Hi Darren,
You will need to write a shader to do your lighting. You could put the light information (coordinates, direction, etc) into a uniform array, but last time I tried uniform arrays in Gem (maybe a couple of years ago) I had some problems and had to patch the Gem source - I can't remember the details now, sorry.
You won't be able to use the Gem objects for lighting once you use a shader, they work in a different way (only for fixed function pipeline, without shaders). With shaders you need to send messages to the glsl_program object to set uniform variables. This also means you have to do your own maths for the transformations, not using translate/rotate objects.
Claude
On 08/12/14 12:20, darren@webel.com.au wrote:
PD-0.42.5-extended-20100501 on Mac OS X 10.8.5.
I have just returned to examining an old GEM project that uses an ambitious (or foolish) 60 (!) GEM lights to simulate 30 real LEDs, using 1 [light] and 1 [spot_light] combined for each LED, achieving a nice effect. But only some of the GEM lights seemed to have any effect. On reading the GEM manual again I easily found out why (I had not paid enough attention to the console error messages).
At http://puredata.info/downloads/gem/documentation/manual/manual/lighting it clearly states:
'GEM has only a maximum of 8 lights at one time. If you try to create more lights than that, you will get an error message.'
(BTW it might be a good idea to include this fact in the basic help docs for [light] and [spot_light] if it has not already been included in a more recent version of Pd, I am using an older version).
Q: Is there any known way to "hack" GEM+OpenGL to increase the number of supported lights ?
I found a discussion on the limit of 8 light as stated in the OpenGL Redbook from 31 Aug 2010 at:
http://stackoverflow.com/questions/3583735/opengl-lights-limit
'8 lights is the limitation of fixed GL pipeline, where you enable each of them, set mode, parameters, etc. Now you have pixel shaders, and lighting is done within shader. There you can use large number of dynamic (not backed into textures) lights. You only need to supply all these lights' parameters sufficiently (maybe, in a texture), and test how many lights your shader is able to process. Also, in shader you can cull too weak lights (contributing too little into pixel value) or just too distant ones.
Update: complex shader with branching can even generate lights (think of long street or christmas tree). It could be more efficient than supply large number of parameters. (alxx)'
I appreciate any feedback on how one might get around this 8 GEM light limit. I am willing to play with code hacks and recompilations on Mac OS X for this particular task. Indeed I am basically willing to melt my MacBook Pro to get this to work with 60 GEM lights.
For the sake of this forum question, it does not matter why I need to have a whopping 60 GEM lights; The real-world system I am simulating with GEM has 30 actual LEDs in it, there is just no way around that. And the LEDs have to be able to move (translate/rotate), and they have to really act like moving, shining, driven lights.
I can compromise a bit on the combination of [light] + [spot_light] for each simulated LED but it's not as nice (noting each LED also has a backing reflector, also simulated in GEM).
The effect with just 4 simulated LEDs = 8 GEM lights (3 x ([light]+{spot_light]) is quite gorgeous already.
But I do really need 60 GEM/OpenGL lights in one scene somehow to complete this simulation properly (noting the main point of the exercise is to actually simulate many LED lights, it's just a light-rich problem). The effect with the real-world system with lots of real LEDs is absolutely stunning.
Ultimately, I want to have many sets (each in a Pd patch) of 30 simulated LEDs, i.e. many sets of 60 GEM/OpenGL lights. It's easy of course to wish for things.
Glad for any tips,
Darren Kelly
PS: And in case you are wondering, not it's not a simulation of an Xmas tree full of LEDs, although being able to simulate 30 LEDs or more in GEM would be a nice early Xmas prezzie for me.
Claude Heiland-Allen wrote:
You will need to write a shader to do your lighting. ..
You won't be able to use the Gem objects for lighting once you use a shader, they work in a different way (only for fixed function pipeline, without shaders). With shaders you need to send messages to the glsl_program object to set uniform variables. This also means you have to do your own maths for the transformations, not using translate/rotate objects.
Thanks Claude for reply.
I just invested some time studying some shader tutorials and examples. I can see how I could use them for a number for other related tasks.
But the inability to use translate/rotate objects with shaders is probably a killer for my current simulation, as I am simulating LEDs that have to be able to move, and that movement is relative to (and bound to) other non-light objects in the scene.
I can see from some of the shader examples how one might be able to simulate some glowing effects nicely, such as for the halo around a street lamp, to evoke the impression of many lights in a row.
But I am not sure whether one could use shaders to create a really clear pointing light effect with clear shining of the light projected onto distant objects.
One of the main points of the demonstration is to show the result of the projection of many (30) driven LEDs onto other surfaces.
The (transformable) [light]+[spot_light] work together nicely for this for my LED simulation.
Darren
-
Claude Heiland-Allen -
darren＠webel.com.au