[osg-users] Pragmatic shader - a new #pragma directive proposition

[Sebastian Messerschmidt]

Am 14.01.2016 um 11:56 schrieb Robert Milharcic:
> On 14.1.2016 9:52, Sebastian Messerschmidt wrote:
>> Hi Robert,
>>
>> This seems more complicated than needed.
>> Why not pass the number of lights as a compile time constant
>>
>> #pragma import_defines (NUM_LIGHTS)
>>
>> shader_state->setDefine("NUM_LIGHTS",12);
>>
>> and use uniform arrays:
>>
>> uniform vec4 u_LightColor[NUM_LIGHTS];
>>
>> for (int i = 0; i < NUM_LIGHTS;++i)
>> {
>>     light+=calcLight(u_LightColor[i], ...):
>> }
>>
>> I feel your approach will bloat the preprocessor code path and will 
>> complicate the use. 
>
> Hi Sebastian,
>
> First, thank you for your input. Yes, that is more or less the same 
> approach I'm currently using. The downside of this approach is that it 
> requires additional nontrivial code logic for the uniform array 
> management (u_LightColor) and that is why I started to look at the 
> alternatives.
What could be more complicated there than to setup individual uniforms? 
Sorry this doesn't pass as a valid argument. If you have to hold the 
number of used lights somewhere you can hold a reference to the uniform 
as well.

> There is also an upper limit for the size of the array that needs to 
> be taken into account. 
At least 512. If this is not enough you can use Uniform buffer objects 
(UBO)[1] or Shader Storage Blocks[2] which support
If this is not enough for your light-count you will probably hit 
performance problems first.

> Also, the loop represents unnecessary overhead (though, this is not a 
> problem on a never hardware). 
That's an assumption of yours. Usually constant folded loops with single 
return and without break, continue-statements are unrolled by the compiler.
I'll accept performance comparisons however ;)

> On the other hand, my suggestion fits well into existing pragmatic 
> shader composition logic and probably has less downsides.
>
Downside is that you're trying to invent a meta-language here out of 
reasons that I commented on. The downside of your approach is a 
preprocessor language with no clear advantages over the tools already at 
your disposal.
So to say, the current language is already turing-complete and you're 
trying to put some syntactic sugar on top, which adds some high degree 
of complexity to the parser and to the shader-code.

An alternative for you is to manage this part yourself by simply 
overriding the parts managing the define-states. Maybe Robert O. can 
fill in on the details here.

Cheers
Sebastian


[1]https://www.opengl.org/wiki/Interface_Block_%28GLSL%29#Uniform_blocks
[2]https://www.opengl.org/wiki/Interface_Block_%28GLSL%29#Shader_storage_blocks


> Cheers,
> Robert Milharcic
> _______________________________________________
> osg-users mailing list
> osg-users at lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org