> Added a SpotLight only to the D3D pipeline currently. > > ### API discussion points > > - [X] Added `SpotLight` as a subclass of `LightBase`. However, it could also > be a subclass of `PointLight` as it's a point light with direction and extra > factors. I saw that `scenario.effect.light.SpotLight` extends its respective > `PointLight`, but it's not a perfect analogy. In the end, I think it's a > questions of whether `PointLight` will be expanded in a way which doesn't not > suit `SpotLight`, and I tend to think that the answer is no. > > - [X] The inner and outer angles are the "diameter angles" as shown > [here](https://docs.microsoft.com/en-us/windows/win32/direct3d9/light-typeshttps://docs.microsoft.com/en-us/windows/win32/direct3d9/light-types). > I, personally, find it more intuitive that these are the "radius angles", > so half these angles, as used in the spotlight factor formula. Do you think I > can change this or do you prefer the current definition of the angles? > > - [ ] The current implementation uses an ad-hoc direction property (using a > `Point3D`). It crossed my mind that we could use the rotation transforms of > the node to control the direction instead, just like we use the > translation/layout of the node to get the position (there is an internal > Affine3D transform for lights, not sure why `AmbientLight` needs it). > Wouldn't that make more sense? When I rotate the light I would expect to see > a change in direction. > > ### Implementation discussion points > > - [ ] I've gotten advice from a graphics engineer to treat point lights as > spot lights with a 360 degrees coverage, which simplifies a few places. We > can still try to optimize for a point light by looking at the light > parameters: `falloff = 0` and `outerAngle = 180`. These possible optimization > exist in `ES2PhongShader.java` and `D3DMeshView.cc`, and in the > pixel/fragment shaders in the form of 3 different ways to compute the > spotlight factor (the `computeLightN` methods). We need to check which of > these give the best results. > > ### Performance > > Win 10 > Testing 3 point lights compared with the `master` branch shows a small drop > in fps (5-10 in the mesh 200 test and ~5 in the mesh 5000 test). I repeated > the tests on several occasions and got different results in terms of absolute > numbers, but the relative performance difference remained more or less the > same. Out of the 3 `computeSpotlightFactor` methods, > `computeSpotlightFactor3`, which has no "optimizations", gives slightly > better performance. The "optimizations" in `D3DMeshView.cc` didn't make a > difference, which is not so surprising considering these are on the CPU. > The sphere with 1000 subdivisions always gives 120 fps. > > Ubuntu 20: > With the patch: > Mesh 200: 60 fps > Mesh 5000: 15 fps > Sphere 1000: 60 fps > > Without the patch (master branch) > Mesh 200: 60 fps > Mesh 5000: 16.3 fps > Sphere 1000: 60 fps > > So no major changes. I will repeat these tests to make sure there was no > mistake.
Nir Lisker has updated the pull request incrementally with three additional commits since the last revision: - Merge remote-tracking branch - Speculative fix for Mac - Fixed shader field name ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/334/files - new: https://git.openjdk.java.net/jfx/pull/334/files/db109b28..d1bc9af5 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=334&range=08 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=334&range=07-08 Stats: 40 lines in 4 files changed: 0 ins; 0 del; 40 mod Patch: https://git.openjdk.java.net/jfx/pull/334.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/334/head:pull/334 PR: https://git.openjdk.java.net/jfx/pull/334
