On Wed, 9 Dec 2020 00:54:14 GMT, Kevin Rushforth <k...@openjdk.org> wrote:
>> Similar to what I said about the falloff, I can remove the documentation, >> but I don't see a compelling reason to artificially limit the values. The >> equation is as described in the docs. If someone puts in values outside of >> physically realistic ranges they will still get whatever the equation spits >> out. Do you think that there would be a too-large surprise factor? >> >> One thing to note is that the user can do the clamping themselves (or we can >> do it later if we don't commit in the docs), but if we clamp, the user can't >> unclamp. > > The main issue I have is that the specified equation matches the proposed > implementation only for values that satisfy the range constraints: `0 <= > innerAngle <= outerAngle <= 180`. > > The reason for this is that the shader implementation compares cosines not > angles, and clamps the result of the division rather than testing whether the > angle is < inner or > outer. These are very reasonable implementation choices. > > We have a few options that I can see: > > 1. List the expected range, and specify that values outside the expected > range are clamped on usage. > 2. List the expected range, and specify that the results are undefined for > values outside the expected range. > 3. Describe the equation that is actually happening. > 4. Implement what the equation actually specifies, even for out-of-range > values. This would constrain the implementation and likely require extra if > tests in the shader. > > Option 4 makes no sense to me. I don't care for 3, since it is less easy to > explain and understand, and it precludes other implementations that are > equivalent for in-range values but might behave differently for out-of-range > values. > > So that leaves option 1 or 2 as workable options. I prefer option 1, although > I'll admit we aren't consistent on this point: we let the implementation do > whatever it will do with out of range color values for PhongMaterial or > Lights. I see. I also dislike 3 and 4. I prefer 2, but if you are convinced that 1 is better I'll go with it. ------------- PR: https://git.openjdk.java.net/jfx/pull/334
