I copied your class and tested first applying the lightcontrol, but don’t move it around. Then setting the light position without using a LightControl (ie just matching translation of the node and position of light). Here they are at red: 10, 2, 10 and green: 20, 2, 20, and blue: 30, 2, 30.
So something seems to be up.
It’s a material thing. Here’s the same example with PBRLighting. Example above (and original test) uses Lighting.j3md:
@ndebruyn can you try with different JME versions (e.g. 3.3, 3.4, 3.5, 3.6) and see if it happens in all versions? Finding the version that regression happened might be of great help to detect the issue.
Thanks for checking.
Yes, let me take some time and check in which version it started.
I do however remember from long ago, like jME 3.3 or 3.2 that it happend.
But that might have been something else.
Let me check.
Okay I have done a quick test on 3.3.0 and it happens there as well.
So maybe we should go even further back.
EDIT: Happens on 3.2.2-stable also.
OMG!
Could the issue be this:
vec3 viewDir = normalize(-wvPosition);
viewdir is defined in the vertex shader, so it would be affected by the vertex position? Edit: Wrong explanation, but you know what I mean. It introduces an error due to interpolation.
Ref different scales on the board changes apparent error:
So the error is more noticable in simple geometries than complex ones.
So what is the solution here?
So what is the solution here?
subdivide the mesh, I think
Curious why this is only happening with the Lighting material but not PBRLighting?
I think PBR does things in world space instead of view space and thus avoids a bunch of interpolation issues. Also the nature of PBR means that it will calculate some things per fragment that lighting tries to do per vertex.
This is without looking at the code again and only going from memory and remembering long-ago discussions. (I always wished Lighting.j3md had been done in world space also because then I wouldn’t have needed to write my own for trilinear mapping and stuff.)
I think the same issue was discussed in this thread:
I have a side question relating to pointlights and spotlights.
The question is, if I want shadows on my spotlights or pointlights do I need to add a SpotLightShadowRenderer or PointLightShadowRenderer for each light to the viewPort?
Do we not have one for them all?
An what will the performance impact be with lets say 10 or 20 shadow renderers?
Yes, that seems so.
Thank you so much.
Another link 
Deferred rendering:
That depends on your scene, every geometry rendered by a shadow casting light will get rendered two additional times.
But note: every geometry with light cast upon it was already rendering once per light.
…shadows add one extra render.
10 objects lit by 5 lights: 50 draw calls.
10 objects lit by 5 lights with shadow renderers: 100 draw calls.
Dynamic lights are expensive which is why there are techniques to use baked lighting.
Deferred rendering is the other solution… with it’s own set of completely different trade offs.
Jme does have singlepass lighting. without checking it should come down to:
10 objects 5 lights: 10 draw calls
10 objects 4 lights + 1 shadow casting: 10 + (10 + 10) = 30
10 objects 3 lights + 2 shadow casting: 10 + (10 + 10) + (10 +10) = 50
Yes, single pass lighting is not the default and then it will depend on how many lights-per-pass you setup.
…and as you say, does not solve the render-per-shadow issues.
