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
_______________________________________________
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
