p3d_LightSourceParameters has no member that indicates light type, and also none to indicate whether it throws shadows

[ellie]

(Disclaimer: I'm not very good with shaders, so maybe I just missed an obvious way to do this)

p3d_LightSourceParameters appears to be lacking a member that indicates light type (point, spot, ..), and also none to indicate whether it has shadow casting enabled.

I tried to create shadowless point lights first and then shadow-throwing spot lights, but as soon as I use setShadowCaster(true, new_res, new_res) on an existing spot light, the order seems to be randomized and any assumption of point lights being first in the array appears to be impossible. Also, accessing shadowMap for lights that don't actually throw shadows seems to cause a GLSL error.

Therefore, it would be neat if the struct had a type member and a shadow casting enabled/disabled member.

[rdb (rdb)]

FWIW, the following can be used to check light type:
* position.w will be 0 for directional lights.
* spotCosCutoff will be -1 for non-spotlights.
* spotExponent will be 0 for non-spotlights.

Please note that if you have a custom configuration of lights, you can always use those explicitly using setShaderInput("mylight", light) and then access those via a p3d_LightSourceParameters input called "mylight" rather than p3d_LightSource[n].

In the future, rather than add a light type checker, we need to separate out p3d_LightSource into separate arrays for point, directional and spot lights. At very least point lights need to be separate, since they use a different type of shadow sampler.

I'm not sure how useful it would be to check whether a light has shadows enabled in the shader. It wouldn't solve any problems for you since you would still get an error and I doubt it would save you much performance. I would rather let Panda automatically bind a 1x1 pixel dummy shadow map for lights that cast no shadows.

[ellie (et1234567)]

In that case, both separate arrays and a dummy sampler would solve my problem. However, I need to run different fragment code depending on the light type - so if there are no separate arrays, a type member would still be useful to me (simply because checking for special magic values of spotCosCutoff seems a bit ugly to me). But separate arrays would be fine too.