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
