[osg-users] Lazy Disabling without VertexFuncsAvailable
Fabian Wiesel
fabian.wiesel at gmail.com
Wed Sep 21 04:45:06 PDT 2016
Hi,
I have converted my fixed function OSG program to a shader pipeline
(using setVertexAttribArray and shaders instead of the setVertexPointer et al)
and did run into some issues when disabling "UseVertexAttributeAliasing", and OSG is compiled with OPENGL_PROFILE=GLCORE
(So OSG_GL_VERTEX_FUNCS_AVAILABLE is unset). I tested the same code on a linux with OSG compiled for a FFP.
And there, the code works as expected.
A simple test program is here: https://github.com/fwiesel/vertexarrayfunctest
An API trace of the failing case shows the following interesting part:
...
glEnableVertexAttribArray(0)
glVertexAttribPointer(0, 3, GL_FLOAT, GL_FALSE, 0, NULL) # NULL is okay, the Array has been bound before
glDisableVertexAttribArray(0)
glDisableVertexAttribArray(1)
glDisableVertexAttribArray(2)
glDisableVertexAttribArray(11)
glDisableVertexAttribArray(12)
glDrawArrays(GL_POINTS, 0, 500)
...
No prior call to enable the array 1,2, 11, or 12 are issued.
The glDisableVertexAttribArray calls are coming from osg::State::applyDisablingOfVertexAttributes()
https://github.com/openscenegraph/OpenSceneGraph/blob/master/src/osg/State.cpp#L1296-L1304
as _useVertexAttributeAliasing is false, and each "<array>._lazy_disable" is true.
The state of "<array>._enabled" is never checked, as "disable<array>Pointer" is unconditionally mapped to the aliased "disableVertexAttribArray"
I think, the bug lies in the assumption of the lazy disabling, that if we do not use the aliasing, that there is a fixed function pipeline.
But if OSG_GL_VERTEX_FUNCS_AVAILABLE the functions are unconditionally mapped to aliased vertex attributes.
I think, the whole lazy disabling of aliased attributes is superfluous in that context, as each vertex attribute tracks its own state already,
and have proposed a patch accordingly: https://github.com/openscenegraph/OpenSceneGraph/pull/125
With the patch applied, the code runs as expected.
Does anyone have a different explanation or a better proposal for solving the issue? It doesn't seem to be the acceptable solution.
Cheers,
Fabian
More information about the osg-users
mailing list