@Ignatz (And anyone else) I’ve uploaded a simple benchmark shader to CC. It’s interesting. There are a few tests in there (in the fragment shader for now). All other things aside, conditionals are a bit more expensive than doing it mathematically, but actually using variables is the surprising cost. It is far better to hard code explicit numbers than have variables. It’s also quicker to use the *= and += type operators than to do it by a fresh assignment.
So the fastest is to have a different shader for each possibility and to load it in accordingly, and to have as few actual variables as possible.
But this is only if speed becomes important, and conditionals are not so bad as I thought.
@Andrew_Stacey - I’ve seen the recommendation of using multiple shaders. The problem, of course, is code duplication and bloat. I’ve built a lighting library that is versatile, but would have dozens of different combinations.
I guess the answer is to maybe build some lightweight shaders that handle the most common variations and then have the kitchen sink version for when you need it.
I also saw in the link I sent you, that one of the biggest performance hits is from fragment uniforms.
@Ignatz If you’re defining your shaders from within Codea rather than the Shader lab then you can build them conditionally. So you have a shader template with slots for the optional bits, but when you assign the shader to the mesh then you fix those options. Much as I did in the benchmark code.