[osg-users] Core Profile: glEnable/glDisable GL_POINT_SPRITE

Daniel Emminizer, Code 5773 dan.emminizer at nrl.navy.mil
Mon Aug 20 06:25:25 PDT 2018


Hi Robert,

Still a low priority because I am able to work around in my own code.  But wanted to make sure this doesn't get lost in the traffic about texture modes in other threads.  The original message had an example .cpp that demonstrated the issue.

Is it worthwhile to create an issue on the github issue tracker?

Thanks.

 - Dan



> -----Original Message-----
> From: Daniel Emminizer, Code 5773
> Sent: Wednesday, August 01, 2018 7:25 AM
> To: OpenSceneGraph Users
> Subject: RE: [osg-users] Core Profile: glEnable/glDisable GL_POINT_SPRITE
> 
> Hi Robert,
> 
> I just started seeing something similar at the end of the day yesterday.  I am
> using osg::PointSprite, not using GL_POINT_SPRITE directly.  I have some
> more background too and I think I see the cause, but not the solution.
> 
> PointSprite::checkValidityOfAssociatedModes() is great, and it works great
> and is right when called.  But I found an edge case where it's not being called
> although PointSprite is in the scene.
> 
> I have a scene that is generated dynamically on user input.  When the Viewer
> starts, there are no points, and there is no PointSprite.  This is when the
> GLObjectsVisitor is called, who is responsible for (among other things) calling
> checkValidityOfAssociatedModes(), due to the
> Renderer::_compileOnNextDraw flag being set.
> 
> Later on in some GUIEventHandler, a GL_POINTS drawable is added with
> PointSprite in its stateset.  checkValidityOfAssociatedModes() is never called
> because the Renderer already did its compile pass.  Because it's never called,
> we never get to state.setModeValidity(GL_POINT_SPRITE_ARB, modeValid
> [false]).
> 
> Because of this, the associated mode of PointSprite ends up applying,
> causing a GL error.  Basically, checkValidityOfAssociatedModes() never gets
> called if that mode is not present under the scene, when the scene is first
> compiled.
> 
> 
> Things I tried:
> 
> * Adding PointSprite to the osg::View::getCamera() on start-up.  Did not
> work because GLObjectVisitor only visits scene data.
> checkValidityOfAssociatedModes() never called.
> 
> * Adding PointSprite to osgViewer::View's root node near setSceneData()
> call.  This did work.
> 
> 
> I can work around this because I do control my View/Viewer and I can add
> this PointSprite.  But this bug might have other side effects.   Though I'm
> seeing this in GL3/GLCORE, it is not a bug exclusive to GL core nor to Point
> Sprite. (I think)
> 
> Attached is a small example that demonstrates the bad behavior.  I know
> you're not currently working on OSG, for me at least this issue can sit for a
> while.  But I wanted to provide you with all the info I had while it was fresh in
> my mind.
> 
>  - Dan
> 
> 
> > -----Original Message-----
> > From: osg-users [mailto:osg-users-bounces at lists.openscenegraph.org] On
> > Behalf Of Robert Osfield
> > Sent: Sunday, July 29, 2018 10:28 AM
> > To: OpenSceneGraph Users
> > Subject: Re: [osg-users] Core Profile: glEnable/glDisable
> > GL_POINT_SPRITE
> >
> > Hi Damian,
> >
> > The glEnable/glDisable will be done directed by your scene graph via
> > the StateSet::setMode(GLenum,..), so simply remove the
> > setMode(GL_POINT_SPRITE).
> >
> > Robert.



More information about the osg-users mailing list