Hi Robert, good morning,
No, I am not writing custom OpenGL code, I am 'just' adding vertex
attributes to the precipitation geometry and use them in the shader
program. I am perfectly aware that this was not a fix for osg, and
indeed I know that the glGet funcs are round-trip funcs that hurt the
performance a lot. But at least it is not crashing anymore for me, it's
one way or the other (first make it work, then optimize).
It certainly has to do with enabling and disabling the vertex attribute
units because when I disable my vertex attributes the crash doesn't
happen (and I tested other possibilities a lot). And with vertex
attributes I get an OpenGL error.
These are snippets from the code (unfortunately I cannot send everything)
#define VERTEX_ATTRIBUTES_ARRAY_INDEX 6
osg::ref_ptr<osg::Vec3Array> vertexAttributes = new
osg::Vec3Array(numParticles * 4);
quad_geometry->setVertexAttribArray(VERTEX_ATTRIBUTES_ARRAY_INDEX,
vertexAttributes.get());
quad_geometry->setVertexAttribBinding(VERTEX_ATTRIBUTES_ARRAY_INDEX,
osg::Geometry::BIND_PER_VERTEX);
program->addBindAttribLocation("delta", VERTEX_ATTRIBUTES_ARRAY_INDEX);
Another test that I did is that I use the built-in variable
gl_MultiTexCoord6 instead of the vertex attribute. This crashes as
well... Hmm, I don't know what to think of this, the multi texturing
exists sooo long already.
But apart from this, the implementation of the func
disableVertexAttribPointersAboveAndIncluding() doesn't seem to match the
func name, imho. But again, I am not aware of all the details.
Best regards, thanks for your time
Raymond
btw this is on win xp, osg 2.2.0 / svn, nvidia (multiple cards)
btw I won't respond in a week or so, I will be away from the computer
Robert Osfield wrote:
Hi Raymond,
Are you writing your own custom OpenGL code? If so then it's likely
that you aren't telling the OSG about the state changes you are
making, or you are assuming OpenGL state is in a certain configuration
in your own code, but this state isn't actually current. For instance
if a vertex array is enabled by you don't provide a valid pointer then
you'll like get a crash.
The "fix" you've made effectively discards lazy state updating and
even using a glGet, glGet being the worst offender as it can stall the
graphics pipeline so is only something you'll want to call on start
up, not during rendering.
As for giving you guidance on what you are doing wrong, this is hard
given I don't really know what you are doing. In general you'll need
to make sure the OpenGL state is the one you want before you doing you
own OpenGL code, and any state changes you make you need to tell the
OSG about afterwards so its lazy state updating can work correctly.
The haveApplied methods help with this, as do the vertex pointer
methods provided in osg::State. Review how osg:::Geometry does
things for inspiration.
Robert.
On Fri, May 30, 2008 at 3:59 PM, Raymond de Vries <[EMAIL PROTECTED]> wrote:
Hi,
I just wanted to let you know that I fixed my crash with a straight forward
implementation of the function that I mentioned earlier today. This is of
course by no means a real fix in the osg way but for that I simply don't
know all the tiny details of the optimizations.
The problem occured when I reloaded my scene with (a changed version, with
vertex attributes, of) precipitation. What I suspect what happened is that a
vertex attribute unit was still activated from the previously loaded scene,
while it should have been disabled after loading the scene again.
Of course it should be fixed elsewhere, but this is how I fixed it, in a
straightforward way, unconditionally:
void State::disableVertexAttribPointersAboveAndIncluding( unsigned int index
)
{
if (_glDisableVertexAttribArray)
{
// Fix by RdV, to avoid a crash when a non-existing vertex array is still
bound, 20080530
#if 0
while (index< _vertexAttribArrayList.size())
{
EnabledArrayPair& eap = _vertexAttribArrayList[index];
if (eap._enabled || eap._dirty)
{
eap._enabled = false;
eap._dirty = false;
_glDisableVertexAttribArray( index );
}
++index;
}
#else
int maximumNoOfVertexAttributes;
glGetIntegerv(GL_MAX_VERTEX_ATTRIBS, &maximumNoOfVertexAttributes);
while (index < maximumNoOfVertexAttributes) {
_glDisableVertexAttribArray( index );
index++;
}
#endif
}
}
and I needed an unconditional enabling of the vertex attribute unit as well:
void State::setVertexAttribPointer( unsigned int index,
GLint size, GLenum type, GLboolean
normalized,
GLsizei stride, const GLvoid *ptr )
{
if (_glVertexAttribPointer)
{
if ( index >= _vertexAttribArrayList.size())
_vertexAttribArrayList.resize(index+1);
EnabledArrayPair& eap = _vertexAttribArrayList[index];
// Fix by RdV, to avoid a crash when a non-existing vertex array is
still bound, 20080530
#if 0
if (!eap._enabled || eap._dirty)
{
eap._enabled = true;
_glEnableVertexAttribArray( index );
}
#else
_glEnableVertexAttribArray( index );
#endif
//if (eap._pointer != ptr || eap._normalized!=normalized ||
eap._dirty)
{
_glVertexAttribPointer( index, size, type, normalized, stride, ptr
);
eap._pointer = ptr;
eap._normalized = normalized;
}
eap._dirty = false;
}
}
I did this fix in osg-2.2.0 but the func still exists as-is in svn.
Hopefully this triggers a fix in the osg way by you.
Cheers
Raymond
Raymond de Vries wrote:
Hi,
I am trying to add vertex attributes to my shader program and I am having
a crash when I reload the geometry with vertex attributes.
Now I am looking into the source and came across the func
osg::State::disableVertexAttribPointersAboveAndIncluding(). Looking at the
func name I would expect that the vertex attribute units would be disabled,
but it doesn't count up. I am really new in this area and would like to
learn. Is there someone who can explain this piece?
Mike Weiblen, could you take a look maybe, you're a shader expert!
A related question: I see that 'some' vertex attribute units are used in
examples like the glsl_confetti.osg. Can any unit be used arbitrarily,
without 0 which seems to be used for the vertex coordinates?
thanks a lot for explaining, best regards
Raymond
this is in the svn btw
_______________________________________________
osg-users mailing list
[email protected]
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
_______________________________________________
osg-users mailing list
[email protected]
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
_______________________________________________
osg-users mailing list
[email protected]
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
_______________________________________________
osg-users mailing list
[email protected]
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
