Spotlight falloff_angle

[recp]

I'm sorry to bringing a COLLADA issue to here but since glTF has same attribute it's good to hear from glTF team. Because I really tried to get an answer from COLLADA side and on resources (books, online resources, collada forum, open sources...) but there is no answer :/

Actually it seems my renderer renders fine as others (Blender, FBXReview...) with an assumption which is that falloff_angle is full angle of spot shape.

This is my spotlight GLSL func (returns attenuation)

...
 
float
spot(Light light, inout vec3 l) {
  float dist;
  float spotCos;

  l    = l - vPosition;
  dist = length(l);
  l    = l / dist;

  spotCos = dot(light.direction, -l);
  if (spotCos < light.cutoffCos)
    return 0.0;

  return pow(spotCos, light.cutoffExp) / (light.constAttn
                                           + light.linAttn * dist
                                           + light.quadAttn * dist * dist);
}
...

Currently I'm sending cosf(rad(falloff_angle/2.0f)) as cutoffCos then everythings seems perfect! COLLADA specs say nothing about this param is full angle or not or how to process in shader I mean a formula like this (https://msdn.microsoft.com/en-us/library/windows/desktop/bb172279(v=vs.85).aspx):

Blender:

  light.spot_cutoff = RAD2DEGF(la->spotsize * 0.5f);
  light.spot_exponent = 128.0f * la->spotblend;

Also I check cesium sources and it seems cesium also uses falloff_angle/2.0 in shader:
cesium modelMaterialsCommon.js#L401

My shader works fine with comparing falloff_angle/2.0 with dot product but it would be nice to get confirmation

Thanks

[javagl]

Parts of the sketched code are not entirely clear (for me), regarding the inputs, and how the output will be used.

However, I think that the definitions go back to the ancient definitions of OpenGL 1.x. And looking at the Spotlights section in the redbook, the cutoff is indeed supposed to be half of the total opening angle of the cone:

(Otherwise, the limits for this value would not make sense: It has a valid range of [0,90]. If this was supposed to be the full opening angle, then spotlights with an opening angle of more than 90° could not be represented)

Maybe this is already sufficient. But as an aside, I have recently worked on an implementation of shaders that are supposed to emulate the OpenGL fixed function pipeline. Here are some code snippets that may be relevant:

//Compute the contribution of the given spot light
//to lightsAmbient, lightsDiffuse and lightsSpecular
void processSpotLight(in Light light)
{
    // The eye position in view space is constant
    vec3 eye = vec3(0.0, 0.0, 1.0);

    // Normalize the input normal
    vec3 normal = normalize(fragmentNormal);

    // Compute vector from surface to light position
    vec3 lightVector = vec3(light.position) - fragmentPosition;

    ...
    
    // Normalize the vector from surface to light position
    lightVector = normalize(lightVector);

    ...

    // Check if the surface point is inside the light cone
    float spotDot = dot(-lightVector, normalize(light.spotDirection));
    float spotAttenuation = 0;
    if (spotDot >= cos(radians(light.spotCutoff)))
    {
        spotAttenuation = pow(spotDot, light.spotExponent);
    }
    ...
}

This yields a result that is equal to that of the OpenGL fixed function pipeline:

(Left is fixed function, right is programmable)

[recp]

Okay cutoff is half no doubt but what about falloff_angle in glTF and COLLADA? Is it half angle or full angle, if it is half then we can say that falloff_angle is cutoff angle in shader but it seems it is not :/

According cesiumjs, Blender and my renderer :) it seems cutoff_angle = falloff_angle * 0.5, here the results: spotlight test, when I used falloff_angle as cutoff_angle then I get the bigger cone. Let's assume that I'm doing wrong but as I shared before cesium and blender also divide the value (comes from glTF/COLLADA) by 2

I think the spotlight parameters and their relationship between fixed function pipeline or shader (I mean falloff_angle <-> cutoff_angle) need to be clarified in specs

[javagl]

Sorry, I now see the main source of confusion was the term (cutoff vs. falloff). Admittedly, the only reasonable interpretation for me would have been that the terms are used synonymously. The COLLADA light properties and the materials_common light properties map 1:1 to the GL fixed function properties. Introducing a "similar but different and easily to be confused" term here would be great way to generate issues and ambiguities. But your test suggests that this might indeed be the case, and that falloff != cutoff - let's see whether someone can make a definite statement here.

[m-7761]

You mentioned that this is unanswered. Anyway, recall we discovered that COLLADA does not match OpenGL in this regard. (I think it uses the full angle.) COLLADA-CTS is the authority on the matter, even though I'm very disheartened by the fact that COLLADA-CTS does not have surface normals in its samples. I may look at ( https://www.khronos.org/collada/wiki/COLLADA_Refinery ) to see if it can be revived and used to improve the COLLADA-CTS files.

[pjcozzi]

@McNopper is this relevant to #945?

[UX3D-nopper]

Yes, as the same topic is also discussed in #945

[pjcozzi]

@UX3D-nopper could you add a summary of this thread to #945 - if needed - and close this?

[UX3D-nopper]

Continued here:
#945