[PD] GEM: is there a way to increase (perhaps hack) the limit on the number of GEM/OpenGL lights above 8

[Claude Heiland-Allen]

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 at 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.
>

-- 
http://mathr.co.uk