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

[Sebastian Messerschmidt]

Hi Robert,
> Hi Sebastian ,
>
>>>
>>> First of all, the lightning shader only illustrates one of the cases 
>>> where (optionally) repeating a code block containing substitution 
>>> parameter can be useful. I used the multi-light lightning as an 
>>> illustration only.
>>>
>>>>> 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.
>>>>
>>>
>>> Sorry, but that is not what I had in mind.  The problem here is the 
>>> management of the array uniform's content and not the reference to 
>>> it or the light count etc. Let say I only want to disable one of the 
>>> lights, say LIGHT0 eg. stateset->setDefines("LIGHT0", 
>>> osg::StateAttribute::OFF). What will you do?
>> Let's say you have a fixed maximum on N, than you create a UBO/Array 
>> of this size and provide a count-uniform for the maximum valid entries.
>> If a light gets disabled, you simply remove it, copy it to the back 
>> and set your count to N-1.
>> In the shader you simply loop from 0 to count instead of N. That 
>> might break compiler optimization, but it won't hurt too much I guess.
>> When using the setDefine, OSG will have to issue a recompile of this 
>> new variant, which will degrade performance if all combinations are 
>> needed.
>>
>> Assume 16 Lightsource, that will produce 65536 possible shader 
>> programs ... and that is only 16, not 500, or 1000 ...
>> Having 1024 individually switchable Lightsources would totally wreck 
>> your idea of having an alternative to my solution.
>> 2^1024 might exceed the numbers of atoms in the known universe, so 
>> there is not a remote chance to solve this with shader combinations...
>>
>
> The question was purely rhetorical. I just wanted to prove my point 
> regarding the uniform's content management vs already provided 
> setDefines("LIGHT0", osg::StateAttribute::OFF). I didn't expect all 
> that. Sorry for the fuzz :)  BTW, I'm not planing to toggle all 
> possible on/off combinations just to see all the permutations, the 
> normal graph usage is what I'm after.
Normal graph usage might exactly trigger a lot of combinations. My point 
is not that theoretical if you take into account that basically everyone 
could have used the feature if it was part of the core, thus the example 
is a practical one :-)
I didn't want to prove anything here, I simply wanted to point out some 
practical problems.

>
>> Exactly, that was my intention, to add a higher degree of complexity 
>> and hopefully solve some problems that "turing-complete" language can't.
>> Turing complete solves all computable problems ;-)
>> I do understand your motivation, but I still don't see the gain really.
>> I've presented some alternative ways to solve your problem, as I came 
>> across some of those challenges too.
>> The idea Robert mentioned might be a good one, basically we could use 
>> some kind of callback to let the user-code preprocess the shader, 
>> wait actually we can already do this, when it is loaded via a 
>> LoadCallback :-)
>> Actually I'm preprocessing my shader code when it's loaded to perform 
>> "include" and automated shader-define setup, so this might work for 
>> your "loop" too.
>>
>
> That would defeat the purpose of the #pragma(tic) shader composition. 
> You may then as well pre-parse #pragma import_defines and #pragma 
> requires and pre-generate all the shader permutations. The purpose of 
> #pragma(tic) shader composition is shader generation based on current 
> define set (see the osg::State).
Yes and? I'm parsing include hierarchies and therefore need to add the 
defines found there to the #pragma import_defines. The bulk work done by 
the osg::State is to determine if a new program needs to be compiled 
based on the set of defines.
My composition is purely to keep the shader code maintainable and 
reusable. Currently some of the "Ubershaders" have 20-30 defines, which 
seriously don't want to write in the the import_defines by hand.
Again I simply wanted to point out some possibilities to get you your 
loop-mechanism.

Cheers
Sebastian

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