RFR: 8234920: Add SpotLight to the selection of 3D light types [v8]
Nir Lisker
nlisker at openjdk.java.net
Sat Jan 16 05:19:25 UTC 2021
> 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
>
> Testing 3 point lights in order to compare with the [pre-patch performance](https://github.com/openjdk/jfx/pull/43#issuecomment-600632114):
>
> Without the `falloff != 0` branching:
> sphere 1000 subdivisions: 120
> mesh 5000: 9.5
> mesh 200: 111.5
>
> With the `falloff != 0` branching:
> sphere 1000 subdivisions: 120
> mesh 5000: 9.3
> mesh 200: 112.5
>
> 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 two additional commits since the last revision:
- Merge remote-tracking branch 'nlisker/8234920_Add_SpotLight_to_the_selection_of_3D_light_types' into 8234920_Add_SpotLight_to_the_selection_of_3D_light_types
- Addressed review comments
-------------
Changes:
- all: https://git.openjdk.java.net/jfx/pull/334/files
- new: https://git.openjdk.java.net/jfx/pull/334/files/e699127d..db109b28
Webrevs:
- full: https://webrevs.openjdk.java.net/?repo=jfx&pr=334&range=07
- incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=334&range=06-07
Stats: 31 lines in 4 files changed: 20 ins; 0 del; 11 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
More information about the openjfx-dev
mailing list