On Sat, 18 Dec 2021 16:12:16 GMT, Kevin Rushforth <k...@openjdk.org> wrote:
>> Initially I went with the equality test, but it did not work well, probably >> since we are comparing floating points. This just seemed safer. If you want >> to try the equality test on you machine(s) it would be interesting, but I >> don't know if I would trust it. Same with the ES shaders. On the Java side I >> would trust it, but at this point it's a matter of consistency. >> >> I suspect that this also messed up with the computation approaches of spot >> light that check `falloff != 0` where we should be checking with a small >> delta: `abs(falloff) < EPSILON` instead. >> Performance should be revisited anyway I think at a later stage after the >> emissive color is added (where we need to figure out splitting shaders, >> which also has to do with the removal of the 3 lights restriction). > > It seems safer then to either leave it the way you have it (in which case, > please a comment), or change it to `abs(gLightAttenuation[i].w) < EPSILON` > both here and in the Java code (for consistency). I'll leave it up to you. > > For spot light, you might want to file a new bug to address the `falloff != > 0` problem. > > I agree about deferring the performance question. Btw, you don't need the "abs" for the gLightAttenuation check (you don't have it now when checking against 0.5) so you can just change it to `gLightAttenuation[i].w < EPSILON` which seems cleaner than testing against 0.5. ------------- PR: https://git.openjdk.java.net/jfx/pull/548
