The reason is simply because I’ve run complex demos with more than 8 lights that use PS and VS along with very high poly models and while performance wasn’t the best it was certainly playable.
My point? The limitation does nothing good and hardware speed increases so fast it makes no sense to limit the number of lights, especially since lighting makes the scene feel alive.
I am in middle of working on a system to handle more then 8 lights. I was forced to redesign the system so it may take a while but I am working on it.
Ahh cool.
Why was the limitation put in place originally?
Just wandering.
Thanks. 
It is a opengl limit. My system finds the best lights to use and then creates a light state for them.
I think I can give you the code I have sofar today just so you can have something until I am done.
Don’t worry about it.
I’m still learning the jME system.
By the time you’re done with the final thing I still wouldn’t have a need for more than 8 lights.
However, future projects there will be a want for it.
Thanks for the offer though. 
You must understand that even with Badmi’s addition you will still only get 8 lights at a time. (They’ll just be the 8 with the most impact).
These are OpenGL lights… lights that aren’t used that much anyways.
I think I need to read up on the OpenGL spec.
It looks like my knowledge is failing me. XD
So basically we are can create our own lights and we can use those limitlessly?
most solutions involve lightmaps (multi-texturing) for static scenes, and lights (OpenGL or otherwise) for dynamic. There are also dynamic lightmaps, etc.
It should be said that this doesn’t limit you to 8 lights in the entire scene, just 8 lights for single vertices. Meaning you can have multiple lightstates scattered throughout your scene, with multiple lights, but only 8 lights can affect a single piece of Geometry. Which is quite a few lights if you think about it.
Ahhh, that makes more sense.
8 per vertice is more than enough.
I was thinking 8 for an entire scene.
Thanks.