RFR: 8234920: Add SpotLight to the selection of 3D light types [v9]

[Nir Lisker]

On Thu, 25 Mar 2021 00:54:33 GMT, Nir Lisker <nlisker at 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:

![Screenshot from 2021-03-25 03-59-57](https://user-images.githubusercontent.com/37422899/112407458-c941cc80-8d1e-11eb-85c2-468508e5018a.png)

-------------

PR: https://git.openjdk.java.net/jfx/pull/334