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

Reply via email to