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

[Robert Milharcic]

Hi Robert Osfield,

On 14.1.2016 10:10, Robert Osfield wrote:
> Hi Robert M, et. al,
>
> I understand the motivation the proposal but it does look like it'll
> complicate the parsing significantly so am inclined to suggest we look
> at the problem at look for easier ways to implement it.

Actually, while I was waiting for a feedback I made a proof of concept implementation which turns out to be relatively straightforward task. For the parser part I have to add only a few more lines (excluding sanity checks):

void Shader::_computeShaderDefines()
{
     ...

     if (keyword == "import_defines") _parseShaderDefines(str, _shaderDefines);
     else if (keyword == "requires") _parseShaderDefines(str, _shaderRequirements);
     else if (keyword == "repeat_begin")
     {
         ShaderDefines shaderCodeBlockIdentifers;
         _parseShaderDefines(str, shaderCodeBlockIdentifers);

         ShaderCodeBlock shaderCodeBlock;

         shaderCodeBlock._begin = eol;
         shaderCodeBlock._end = std::string::npos;

         shaderCodeBlock._identifier = *shaderCodeBlockIdentifers.begin();
         _shaderCodeBlocks.push_back(shaderCodeBlock);
     }
     else if (keyword == "repeat_end")
     {
         ShaderCodeBlock& shaderCodeBlock = _shaderCodeBlocks.back();
         shaderCodeBlock._end = _shaderSource.find_last_not_of(" \t", pos - 8);
     }

     ...
}
> In terms of code bloat in shaders, the #pragma(tic) shader composition
> ensures that the final code passed the OpenGL will have all the
> unimplemented paths removed so performance won't be an issue.  For
> developers code bloat in shaders is an potential issue, one thing you
> do to help would be to wrap up all the lighting calls into a small set
> of functions that are called from the main, these functions are
> implemented in separate shaders that handle all the different code
> paths so at least the complexity is kept in one place and can be
> reused easily.
Agreed.

> A second possibility would be to have developers auto generate shaders
> so avoid creating bloated shaders directly.
>
> A third approach might be to have the ability to provide a custom
> parser to the OSG so that it can handle custom syntax that developers
> feel suits their needs better than the default set of features
> provided by the core #pragma(tic) shader composition.
>
Third approach is the approach I like most. I wonder what others have to say about this, though...

Robert Milharcic