Hi Gordon,
My program is working ok when I load the scene the first time, including
my shader program with vertex attributes. However, when I clear the
SceneView (yes, I know, this should be osgViewer based once, if there's
time) and load another scene, or the same, I got a crash which makes me
think that the vertex attribute unit that was used before, is still
activated.
When I use (abuse?) the built-in variable gl_MultiTexCoord6 it's also
working fine. Actually, I am following the same approach as in the
example file in osg toy: osgtoy-data/trunk/compactdisc-texcoord.osg
Using this built-in variable was just a test.
Thanks, best regards
Raymond
Gordon Tomlinson wrote:
Are you sure you have 8 texture units many cards still also only support 4
, see GL_MAX_TEXTURE_UNITS_ARB for the number on your card..
Also just to confuse the issue in the Pipeline there is also
GL_MAX_TEXTURE_IMAGE_UNITS_ARB which >= GL_MAX_TEXTURE_UNITS_ARB
Also I assume you have called glActiveTexture(....) and glBindTexture() or
set the OSG texture state up.
Do your arrays have the correct number of verts /indices in them?,
Have you check your indices to see that they contain correct numbers.
__________________________________________________________
Gordon Tomlinson
Email : [EMAIL PROTECTED]
Website : www.vis-sim.com www.gordontomlinson.com
__________________________________________________________
"Self defence is not a function of learning tricks
but is a function of how quickly and intensely one
can arouse one's instinct for survival"
-Master Tambo Tetsura
-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Raymond de
Vries
Sent: 31 May 2008 08:55
To: OpenSceneGraph Users
Subject: Re: [osg-users] Vertex attributes: how does implementation of
osg::State::disableVertexAttribPointersAboveAndIncluding() work, it is
almost never called
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
_______________________________________________
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
