Hi Bin, I think I know what modification you mean so I've moved the uniform substitution block infront of the attribute substution block but without your modified source code there is no way for me to know 100%. I have checked what change I think you mean into svn/trunk and the OSG-3.2 branch.
Could you please checked them out and let me know if this has been done correctly. Robert On 20 April 2015 at 00:50, Bin Chen <[email protected]> wrote: > Hi, Robert, > > I managed to build OSG for our WinCE 7 platform and Android platforms with > GLES2 for our devices and discovered a bug introduced from 3.2.1. (3.2.0 is > fine) > It is in the function > State::convertVertexShaderSourceToOsgBuiltIns(std::string& source) of > osg\State.cpp > > The line > // replace ftransform as it only works with built-ins > State_Utils::replace(source, "ftransform()", > "gl_ModelViewProjectionMatrix * gl_Vertex"); > > should be in front of State_Utils::replaceAndInsertDeclaration(source, > declPos, _vertexAlias._glName, _vertexAlias._osgName, > _vertexAlias._declaration); > > Otherwise it ends up with invalid glsl shader source and not render > anything. I checked the 3.2.2 and 3.3.0, the bug is not addressed in either > versions. > > The fix is moving > > if (_useModelViewAndProjectionUniforms)... section > in front of > if (_useVertexAttributeAliasing)... section. > > > Cheers! > > Bin > > > On Thu, Apr 16, 2015 at 7:39 PM, Robert Osfield <[email protected]> > wrote: >> >> Hi Roman, >> >> On 16 April 2015 at 08:58, Roman Grigoriev <[email protected]> wrote: >>> >>> Hi, Robert! >>> Have you looked in patches or what is you decision about VAO? >> >> >> Have just had a look at your changes to osg::Geometry/osg::DrawElements >> and osgText and they aren't any where near close enough to a form that is >> suitable for merging with the core OSG. The code as is will only work with >> a single graphics context, and for very specific combinations of >> osg::Geometry usage, outside of this it would cause crashes. While these >> bugs could be resolved the overall approach is awkward and adds a >> performance overhead to all users of the OSG, even ones that don't required >> VAO support. >> >> I will spend some time reviewing the VAO extension and have a think about >> how it should be done. >> >> Robert. >> >> >> >> >> _______________________________________________ >> 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 > _______________________________________________ osg-submissions mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-submissions-openscenegraph.org
