Errors with more than 5 lights / setShaderAuto()

[anon52635864]

When I add more than 5 lights / setShaderAuto() with shadows enabled, then I get some sort of Cg compilation error:

:shader(error): Failed to compile Cg shader created-shader:
(34) : error C5102: output semantic attribute “TEXCOORD” has too big of a numeric index (8)
(34) : error C5041: cannot locate suitable resource to bind parameter “l_lightcoord5”

I tested this both with AMD / radeon driver (Fedora Linux) and Intel / i915 driver (Fedora Linux), so this doesn’t seem to be a special hardware-specific limitation related to one of my GPUs. The shadow map size doesn’t seem to matter and setting it to something absolutely tiny doesn’t avoid this limit either: light.node().setShadowCaster(True, 64, 64)

Is this limit per design? For my game I’d need up to ~20 lights at the same time with often just a small resolution so the framerate shouldn’t take too much of a hit - but this hard limit prevents me from doing that.

For anyone who wants to try for themselves, I changed the basic.py shadows example code to add exactly 6 lights and this prompts the described error. As soon as the amount is lowered to 5, the error goes away.
basic.py (7.11 KB)

[wezu]

This is a limit of the Cg shaders on anything not Nvidia, but even with GLSL 20 shadow casting lights is a lot, even more - 20 lights without shadows is a lot in a forward shading scheme. For every shadow caster your entire scene needs to be rendered from the lights point of view (for point light shadows it’s rendered 6x, once for each face of the cubemap), even if it’s just the depth. Also, no matter how small your light is it affects everything in your scene (unless you do some clever tricks and apply the light only to a subset of nodes). 20 lights will not make your game 20x slower then with 1 light, but it might get 10x slower

For 20 lights you should look into deferred shading, there are some samples on the fora here, I know, I’ve made one not so long ago

[anon52635864]

@wezu

This is a limit of the Cg shaders on anything not Nvidia

Why 5 though? I would have understood 8, but 5? It seems excessively low.

@wezu

For every shadow caster your entire scene needs to be rendered from the lights point of view

Yes but at 64x64 this is really quick. Like, I actually tested it. Certainly not the slowdown 10x you are suggesting. I am using a lightmanager that scales down further away lights, so only 4-5 would actually be at any notable res, if at all.

@wezu

For 20 lights you should look into deferred shading, there are some samples on the fora here, I know, I’ve made one not so long ago

Any chance those are going to be integrated into setShaderAuto() in the future? (or some other similarly easy scheme) I’m not that much of a shader person, so an easy way to set that up would be nice.

[wezu]

Cg has these ‘Texcoords’ they are float4 (4 element vectors) passed from the vertex shader to the fragment shader, and you only get 8 of them. You may use up texcoords for:/
-normal vector
-tangent vector
-binormal vector
-texture uvs
-shadow uvs
-world position
-other stuff I don’t remember

You always need a normal, you need uvs for a texture, don’t know what the third thing is, but you’re left with 5 texcoords for shadow uvs.

I don’t think that anything will be a part of p3d, when I was making my solution the goal was to have a drop in replacement for the auto shader, but in the end I made the light API different. I still think it’s easy to use, take a look, say what you don’t like and I may improve it

Auto Deferred Shader

During the last weekend or two I’ve been making something that was meant as a drop-in replacement for the default, build in shader generator… that’s not actually generating any shader code (maybe apart from some tiny configuration header) but just works and is just as easy to use as render.setShaderAuto() The idea was, that you import a class, init it, maybe give it some optional configuration values depending on what features you’d want, and that’s it. The class would automagically make a new …

[anon52635864]

I didn’t know point lights were supported directly, which makes the limit less problematic for me. For now I’ll focus on other issues, but I’ll keep your deferred mechanism in mind - it looks quite useful indeed, might be worth trying at some point.