That works. I’ve never been good with quaternions.
Perhaps when @tlf30 gets back from his trip and confirms, we can coordinate his punctual lights PR along with a second PR adding this code to the standard LightControl. Beyond that, I have also noticed that lightToSpatial is also incomplete in the spot-light field, so the LightControl PR would be a good opportunity to finish that (it doesn’t look too hard anyway).
I submitted it earlier today. I’m just waiting for @sgold to check out the latest commit to that.
This looks great. I have not had time to dive into the exact details, but it makes way more sense then what I was seeing. I will be home is a week (I am ready to be home for a while…), and can do a more thorough review then, but I think you are correct that perhaps a PR just needs to be done to the LightControl and we remove the GltfLightControl.
It is a wonderful -41 F outside right now (yes that is a negative sign), and the sun came entirely over the horizon for the first time this year a couple days ago. I am currently hiding in my office
The PR with the LightControl fixes has been submitted, and the checks are in progress.
I am a little concerned that, during my tests of lightToSpatial, the differences in the quaternion’s direction and the light’s direction did differ as much as by 4 units (squared length), but I didn’t see anything too wonky with the tests, and the vectors did look fairly close upon inspection of the output. I’m attributing this to rounding error with the quaternion math, but someone with more experience with quaternions may want to double-check that method.
When I set a spatial to use the transformation data of a light, I need to adapt the light’s direction into a rotation quaternion. However, I can’t just use spatial.setLocalRotation(new Quaternion().lookAt(light.getDirection(), Vector3f.UNIT_Y));, as that doesn’t account for the fact that light directions are independant of the scene graph and work in global coordinates. I need to do a whole bunch of other stuff to account for that, since there is no setWorldRotation method.
In my tests, though, I essentially reverse that process to get what I hope is the original direction (much easier, spatial.getWorldRotation().mult(Vector3f.UNIT_Z); or spatial.getWorldRotation().getRotationColumn(2);). I then compare it to the original direction of the light to see if they match. However, my tests show that the vectors are off by a rather disturbing angle as far as numbers go. However, despite the warnings, the visuals don’t seem to be affected. This is a little confusing to me.
I mean spatial units. When I normalize both vectors and subtract one from another, the difference vector has a length of 2 spatial units (4 if using squared length, which I do for efficiency since square roots aren’t cheap). If my calculations are correct, this means that the difference in angles is over 63°.
Rotation not equal: is (0.0, 0.0, 1.0) ((0.0, 0.0, 1.0)), needs to be (0.0, 0.0, -1.0)
It would seem that my reverse engineering results in one vector pointing in the opposite direction as the other. If I negate one of them, the errors stop.
I’ll add the change to the PR.
