On Thu, 25 Mar 2021 02:02:25 GMT, Nir Lisker <nlis...@openjdk.org> wrote:
>>> I the rotation needs to apply to whatever the direction vector is: whether >>> that's implicitly (0,0,1) if we don't provide a separate direction vector >>> or whether it's the user provided direction vector, it would be odd to >>> ignore transforms if you set the vector. >> >> I see, so we compose the transforms on top of the direction vector. It's an >> option indeed. >> >>> If we don't provide a vector, we could always add it later if people ask >>> for it, so maybe it is better to leave it off if we aren't sure. >>> >>> The question then becomes how easy is it to modify the direction vector >>> using the node transforms? >> >> Yes, the ease of use is the issue I brought up initially with this approach. >> The rotation transforms are non-commutable, so it's going to be unintuitive >> for complex operations. A look-at method could be very useful not only in >> this case, but for any node in a 3D scene (or even 2D). Do you think that >> this is a worthy addition? > > I think I corrected the GL pipeline issue. The dot product should have used > the negative light direction. It worked for me because I was testing in the > -1 z direction instead of the +1. I still don't know why Mac and Linux would > have given different results. This is what I get after the commit: > >  If you want to test aiming the light with transforms instead of a direction vector, I modified the `NGSpotLight` and `AttenLightingSample` files to use the rotation transforms. [transforms.zip](https://github.com/openjdk/jfx/files/6212221/transforms.zip) ------------- PR: https://git.openjdk.java.net/jfx/pull/334
