Was just about to post about this myself. @nehon : Seems to happen when a normal map is not set in a material file (.j3m) using Lightning.j3md, as I’ve been able to get rid of the error by setting it. The error only appears in the above scenario, not when creating a material directly without .j3m file and leaving out the normal map file.
Here is my system info:
26.jul.2011 18:49:08 com.jme3.system.lwjgl.LwjglContext printContextInitInfo
INFO: Vendor: NVIDIA Corporation
26.jul.2011 18:49:08 com.jme3.system.lwjgl.LwjglContext printContextInitInfo
INFO: OpenGL Version: 2.1.2
26.jul.2011 18:49:08 com.jme3.system.lwjgl.LwjglContext printContextInitInfo
INFO: Renderer: GeForce 7900 GS/PCI/SSE2/3DNOW!
26.jul.2011 18:49:08 com.jme3.system.lwjgl.LwjglContext printContextInitInfo
INFO: GLSL Ver: 1.20 NVIDIA via Cg compiler
26.jul.2011 18:49:08 com.jme3.system.lwjgl.LwjglTimer
INFO: Timer resolution: 1 000 ticks per second
26.jul.2011 18:49:08 com.jme3.renderer.lwjgl.LwjglRenderer initialize
INFO: Caps: [FrameBuffer, FrameBufferMRT, FrameBufferMultisample, OpenGL20, OpenGL21, ARBprogram, GLSL100, GLSL110, GLSL120, VertexTextureFetch, FloatTexture, FloatColorBuffer, NonPowerOfTwoTextures, VertexBufferArray]
are you testing with the last svn ?
the number of varying varies depending on what attribute you use in the material
Don’t know who you’re talking to so I answer anyways:p Last nightly, not svn. I’ve tried looking for a cause, but i don’t speak glsl 
Error also exists when spotlight is not present.
Was talking to both of you ^^
Ok it was supposed to be fixed, maybe it’s not yet in last nightly, but that would be strange.
It’s pretty hard to test it since my card accept 128 varyings, I don’t know if there is a good tool that could debug shader and display those kinds of metrics…
I’m gonna see what i can do 
I’ll have a go if it doesn’t work in svn by now, can’t promise anything though.
Lighting.j3md used to work, so I’ll try to figure out what change caused it not to.
Lack of some resource in the card doesn’t seem likely since lighting.j3md works when :
- you add normal map.
- it’s being used through code instead of defined in a j3m file.
FYI: I have no idea what I’m doing, just trying to use common sense.
@makeshift then hereby, I declare you a superhero:
http://demotivationalblog.com/demotivational/2010/03/common-sense.jpg
Haha My lifelong goal has been reached!
I might buy a suit, guess what kind…
makeshift said:
Lack of some resource in the card doesn't seem likely since lighting.j3md works when :
- you add normal map.
Common sense is not always a good ally :p (usually is though, don't give up ;) )
When you have a normal map, the normal is sampled in the pixel shader for each pixel. When you don't have a normal map, the vertex normal is used, so it has to be passed from the vertex shader to the pixel shader by using a vec3 varying -> that's 3 varrying 'slots' over 32 that you don't need when you have a normal map.
This is clearly the issue, for sure, now what's difficult is to reduce the number of varying used without lowering the performances of the shaders.
Could the problem be that the driver does not support more? Because I’m pretty sure that the card would not be limited that low.
don’t know if it’s the driver or the card, but that’s limited…
Ok, common sense lost this time, @nehon thanx for explanation 
“-it’s being used through code instead of defined in a j3m file” is not correct either.
Off to shader camp with me.
I just updated my drivers, didn’t help.
Mega bug : Spotlight brightness depends on position of the camera. What you thought you will get away without me detecting this bug ?
What this means ? Player that holds the spotlight will barely see anything at all because it is barely lit, while enemy that looks towards the player will be blinded to death by extreme light.
I used TestSpotLight to demonstrate this bug : i paused the spotlight at float angle = 4.0f; so it doesnt move.
Results :
Barely lit depending on camera
Please not that this bug renders spotlight unusable in a real case scenario. Ground isn’t lit at all because it is parallel to the spotlight and walls are totally white because they are vertical to the spotlight.
Real case scenario pictures :
Almost no lighting when camera behind spotlight
too much light when facing towards spotlight
Real case spotlight code :
[java]playerLight.setSpotRange(30);
playerLight.setSpotInnerAngle(5FastMath.DEG_TO_RAD);
playerLight.setSpotOuterAngle(10FastMath.DEG_TO_RAD);
playerLight.setPosition(player.getWorldPosition());
Vector3f direction = player.getForward().subtractLocal(player.getWorldPosition());
playerLight.setDirection(direction);
playerLight.setColor(ColorRGBA.White.mult(2));
rootNode.addLight(playerLight);[/java]
uh?
I don’t see any issue in your screen shots, the first shot is brighter because of specular highlighting. Set the shininess of the ground to 0 and you’ll get the same result as shot 2.
Also…if you made a test case, could be handy that you post the code.
o didnt know it was the shiness that messed everything.
After i set shiness to 0 the ground was lighting correctly thank you.
mhh it’s not really messing things…it does what it’s made for 
Jme’s shiness violates the laws of physics:
- Using pointlight :
How can a stationary light move and face towards the camera just because it has 5.0f shiness.
- Using spotlight :
How can a stationary light change its brightness depending on camera position ?
Either its a bug in lighting shader, or a weird concept.
Shininess determines how much a surface reflect light where 0 would be a blackhole.
a i see now.
tralala said:
Jme's shiness violates the laws of physics:
true....it uses an approximation, but that's how it usually done in the game industry. There are several model to compute specular highlights but we uses 3 depending of the quality requested, Blinn - Phong, Standar phong and Isometric ward. I encourage you to google that if you want more details, but all of them are approximations.
tralala said:
How can a stationary light change its brightness depending on camera position ?
Either its a bug in lighting shader, or a weird concept.
You don't get it, the light does not change it's brightness, it's the way it reflects on the surface that changes.
That's not a weird concept, it's what's happening in real life, and that's the very effect all this shininess thing try to simulate.