Robert,
are there any changes in the shader management, I mean are the shaders
changed by the OSG code somehow (I am using the built-om uniforms)? Here is
my shader source line:
"varying vec4 projShadow;\n"
that apitrace logs as (this is being compiled but differs from the original
shader source
Makes sense. My situation is simple; I have no need to override parts of
shaders, just load a few fragment shaders from files. So I'm going with the
simple approach of an osg::Program per osg::Drawable, with a shared Vertex
osg::Shader and separate Fragment osg::Shaders.
Thanks for clearing thi
HI Ravi,
No matter what approach you take there will be separate OpenGL program
object built and need to be bound. You can do this explicitly by
creating your own osg::Program and assigning them to the scene graph
or have this done implicitly by the OSG's backend by the utilising the
#pragmatic sh
On 3 September 2016 at 22:56, Andreas Ekstrand
wrote:
> Thanks, Robert and Chris! I built the quadtree myself and I had indeed
> messed up the scene graph. Doing everything by the book works much better,
> it runs smoothly now.
That's great to hear.
Robert.
__
Hi Julien,
Updating VAO's isn't particularly costly in itself, the cost that
Jannik was seeing was entirely down to the fact that the when you use
DrawThreadPerContext the next frame is held back until all StateSet
and Drawable's that have been dispatched. The solution for Jannik was
nothing more
5 matches
Mail list logo