Hi Hartwig, I can't see how you can reuse shaders that are from applications that do their own shader preprocessing. The @ usage in question isn't supported by GLSL or the OSG, and given both the OSG and GLSL support #define's and there usage this is how those OpenMW probably should have been written, especially given how the OSG's #pragma(tic) shader composition system provide inserting of variables automatically for you without an application special preprocessing.
Robert On 3 April 2018 at 09:28, Ralf Habacker <[email protected]> wrote: > Am 14.03.2018 um 10:55 schrieb Robert Osfield: > Hi Robert, > >> For integration of new features such as support additional >> functionality from plugins like obj that aren't natively supported by >> fixed function GL I would suggest levering the StateSet::setDefine() >> to enable/disable controls, then have the uber shader have this in >> them. This way you needn't deeply couple ShaderGen to the various >> plugins, instead just the uber shaders and plugins need to be >> coordinated. > This looks nice - thanks for your work. > > I tried to adapt the shaders from > https://github.com/OpenMW/openmw/tree/master/files/shaders and detected > an issue, which seems to not be supported with the current implementation. > > At > https://github.com/OpenMW/openmw/blob/master/files/shaders/objects_vertex.glsl#L67 > there is > > diffuseMapUV = (gl_TextureMatrix[@diffuseMapUV] * > gl_MultiTexCoord@diffuseMapUV).xy; > > which uses a macro @diffuseMapUV for generating index values and is > expanded for example to > > diffuseMapUV = (gl_TextureMatrix[0] * gl_MultiTexCoord0).xy; > > To be able to use the mentioned shader directly in osg I renamed the > defines named @<name> to _<name>. but got a problem with the following term: > > gl_MultiTexCoord@diffuseMapUV > > which generates a variable name created from a variable name suffix and > the value from the macro @diffuseMapUV by the preprocessor: > > gl_MultiTexCoord <concat> _diffuseMapUV > > According to https://gcc.gnu.org/onlinedocs/cpp/Concatenation.html in > regular C I would use > > gl_MultiTexCoord ## _diffuseMapUV > > or > > gl_MultiTexCoord/**/_diffuseMapUV > > but at least the nvidia glsl compiler does not understand this and > returns a compile error. An internet search for a solution inside the > glsl compiler gave no results. > > Than I took a look at osg shader loading implementation to see if there > would be another way to solve this, because the shader source code is > already parsed by osg (in Shader::PerContextShader::compileShader) and > performs some replacements (In openmw, where the mentioned shaders came > from, the @<name> replacements are also performed in the framework by a > class named ShaderManager). > > It looks possible to add some macro replacement from the given state set > to solve this issue, but before I'm going to start writing a related > patch I would like to know if there would be better (or easier) solution ? > > Ralf > _______________________________________________ > osg-submissions mailing list > [email protected] > http://lists.openscenegraph.org/listinfo.cgi/osg-submissions-openscenegraph.org _______________________________________________ osg-submissions mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-submissions-openscenegraph.org
