On Thu, 25 Mar 2021 00:54:33 GMT, Nir Lisker <nlis...@openjdk.org> wrote:
>>> I would like to allow a developer to achieve a functionality like is shown >>> in https://www.youtube.com/watch?v=CFgwZX5dkcM at 9:50. The rotations are >>> intuitive there. If we allow both rotation transforms and a direction, >>> wouldn't that cause the direction to be unintuitive? Or do you mean that >>> the direction is always the look-at regardless of rotation transforms and >>> if it's `null` then the rotations take over? >> >> 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. >> >> 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? >> >>> > On Mac I no longer get a GLSL shader error at runtime, but spotlights >>> > aren't working correctly, either. >>> >>> I don't see this on Linux and I don't have a Mac. Can you try on Linux and >>> see what you get? If Linux works, I'm afraid I would not be able to debug >>> the Mac. >> >> It's broken on Linux, too -- more so, since there is no lighting most of the >> time. > >> 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:  ------------- PR: https://git.openjdk.java.net/jfx/pull/334
