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

darren at webel.com.au darren at webel.com.au
Mon Dec 8 13:20:18 CET 2014


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.

-- 
Webel IT Australia, "The Elements of the Web"
http://www.webel.com.au



More information about the Pd-list mailing list