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

2018-07-29 Thread Damian Dixon
Hi,

I have a build of OSG 3.6.2 for GLCORE for Mesa 18.0.5, Intel HD Graphics
620.

I am seeing a lot of warnings/errors around the use of PointSprite.

The warnings/errors are (once per PointSprite):

Warning: detected OpenGL error 'invalid enumerant' at after
RenderBin::draw(..)
Mesa: User error: GL_INVALID_ENUM in glEnable(GL_POINT_SPRITE)

The Intel Mesa i965 driver is fairly strict with regards to Core Profile
and does
not provide a compatibility profile.

I'm using osgEarth so I have to build for Core Profile for osgEarth to work.

I've looked at trying to add additional logic to stop OSG from calling
glEnable/glDIsable for GL_POINT_SPRITE but I can't see a sensible place to
disable calling to glEnable/glDisable.

Core Profile says that GL_POINT_SPRITE is always on so I believe that all
that needs to be done is to not call glEnable/glDisable for GL_POINT_SPRITE.

Regards
Damian
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org


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

2018-07-29 Thread Robert Osfield
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.
On Sun, 29 Jul 2018 at 14:24, Damian Dixon  wrote:
>
> Hi,
>
> I have a build of OSG 3.6.2 for GLCORE for Mesa 18.0.5, Intel HD Graphics 620.
>
> I am seeing a lot of warnings/errors around the use of PointSprite.
>
> The warnings/errors are (once per PointSprite):
>
> Warning: detected OpenGL error 'invalid enumerant' at after 
> RenderBin::draw(..)
> Mesa: User error: GL_INVALID_ENUM in glEnable(GL_POINT_SPRITE)
>
> The Intel Mesa i965 driver is fairly strict with regards to Core Profile and 
> does
> not provide a compatibility profile.
>
> I'm using osgEarth so I have to build for Core Profile for osgEarth to work.
>
> I've looked at trying to add additional logic to stop OSG from calling
> glEnable/glDIsable for GL_POINT_SPRITE but I can't see a sensible place to
> disable calling to glEnable/glDisable.
>
> Core Profile says that GL_POINT_SPRITE is always on so I believe that all
> that needs to be done is to not call glEnable/glDisable for GL_POINT_SPRITE.
>
> Regards
> Damian
>
>
> ___
> osg-users mailing list
> osg-users@lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org


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

2018-08-01 Thread Daniel Emminizer, Code 5773
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-boun...@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.

#include 
#include 
#include 
#include 
#include 

osg::Node* createCircle(const osg::Vec4f& color, float radius)
{
osg::Geode* geode = new osg::Geode;
osg::Geometry* geom = new osg::Geometry;

// Draw a simple circle, every 3 degrees
osg::Vec3Array* vertices = new osg::Vec3Array();
for (int k = 0; k < 120; ++k)
{
  double asRadians = osg::DegreesToRadians(3.0 * k);
  vertices->push_back(osg::Vec3(radius * sin(asRadians), 0.0, radius * 
cos(asRadians)));
}

osg::Vec4Array* colors = new osg::Vec4Array(osg::Array::BIND_OVERALL);
colors->push_back(color);

geom->addPrimitiveSet(new osg::DrawArrays(GL_POINTS, 0, 120));
geom->setVertexArray(vertices);
geom->setColorArray(colors);
geode->addDrawable(geom);

return geode;
}

osg::Node* createScene()
{
osg::Group* group = new osg::Group;
group->addChild(createCircle(osg::Vec4f(0.5, 1, 0.5, 1), 85.f));

osgText::Text* text = new osgText::Text;
text->setText("Press any key to turn on PointSprite.");
text->setCharacterSize(10.f);
text->setFont("fonts/times.ttf");
text->setAxisAlignment(osgText::Text::XZ_PLANE);
text->setAlignment(osgText::Text::CENTER_CENTER);
group->addChild(text);

return group;
}

struct PointSpriteAdder : public osgGA::GUIEventHandler
{
  explicit PointSpriteAdder(osg::StateSet* stateSet)
: stateSet_(stateSet)
  {
  }

  virtual bool handle(const osgGA::GUIEventAdapter& ea, 
osgGA::GUIActionAdapter& aa, osg::Object* obj, osg::NodeVisitor* nv)
  {
if (ea.getEventType() == ea.KEYDOWN)
{
  //
  // PointSprite::checkValidityOfModes() never gets called here
  OSG_NOTICE << "Turning on Point Sprite.\n";
  stateSet_->setTextureAttributeAndModes(0, new osg::PointSprite);
}
return GUIEventHandler::handle(ea, aa, obj, nv);
  }

  osg::ref_ptr stateSet_;
};

int main(int argc, char** argv)
{
osg::ArgumentParser arguments(&argc, argv);

// construct the viewer.
osgViewer::Viewer viewer(arguments);
osg::Node* scene = createScene();
viewer.setSceneData(scene);
viewer.setUpViewInWindow(100, 100, 800, 600);
viewer.addEventHandler(new osgViewer::StatsHandler());


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

2018-08-20 Thread Daniel Emminizer, Code 5773
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-boun...@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.

___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org


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

2018-08-22 Thread Robert Osfield
Hi Dan,

On Tue, 21 Aug 2018 at 23:15, Daniel Emminizer, Code 5773
 wrote:
> 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?

If I am not able to address the problem right away then it would make
sense to put it into the Issue tracker to make it easier to find, a
reference back to any associated thread on osg-users ML/forum would
help too.

I will spend some time on it this morning, so no need to add it to
Issue right away, hopefully I'll have a fix before you get online!

Robert.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org


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

2018-08-22 Thread Robert Osfield
Hi Dan et. al,

To resolve this issue I have added a mode validity setting to
State::nitializeExtensionProcs(), this resolves the GL warning
generated by the checkvalidity_bug test program.  The fix is checked
into master, 3.6 branch and 3.6-TexStorage.

Cheers,
Robert.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org


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

2018-08-22 Thread Daniel Emminizer, Code 5773
Hi Robert,

It's on my list to swap over to 3.6-TexStorage to make sure it doesn't break 
anything.  I'll do that in the next couple of days and test this out.

The change looked good from a quick review on 3.6 branch.  But on master branch 
you have "if (false)" around the code block.  I'll point out on github to make 
it easier to find.  Looks unintentional and does not match 3.6 branch.

 - Dan


> -Original Message-
> From: osg-users [mailto:osg-users-boun...@lists.openscenegraph.org] On
> Behalf Of Robert Osfield
> Sent: Wednesday, August 22, 2018 6:23 AM
> To: OpenSceneGraph Users
> Subject: Re: [osg-users] Core Profile: glEnable/glDisable GL_POINT_SPRITE
> 
> Hi Dan et. al,
> 
> To resolve this issue I have added a mode validity setting to
> State::nitializeExtensionProcs(), this resolves the GL warning
> generated by the checkvalidity_bug test program.  The fix is checked
> into master, 3.6 branch and 3.6-TexStorage.
> 
> Cheers,
> Robert.
> ___
> osg-users mailing list
> osg-users@lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org


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

2018-08-22 Thread Daniel Emminizer, Code 5773
Disregard, looks like you already got it!  Thanks.


> -Original Message-
> From: Daniel Emminizer, Code 5773
> Sent: Wednesday, August 22, 2018 6:37 AM
> To: OpenSceneGraph Users
> Subject: RE: [osg-users] Core Profile: glEnable/glDisable GL_POINT_SPRITE
> 
> Hi Robert,
> 
> It's on my list to swap over to 3.6-TexStorage to make sure it doesn't break
> anything.  I'll do that in the next couple of days and test this out.
> 
> The change looked good from a quick review on 3.6 branch.  But on master
> branch you have "if (false)" around the code block.  I'll point out on github 
> to
> make it easier to find.  Looks unintentional and does not match 3.6 branch.
> 
>  - Dan
> 
> 
> > -Original Message-
> > From: osg-users [mailto:osg-users-boun...@lists.openscenegraph.org] On
> > Behalf Of Robert Osfield
> > Sent: Wednesday, August 22, 2018 6:23 AM
> > To: OpenSceneGraph Users
> > Subject: Re: [osg-users] Core Profile: glEnable/glDisable GL_POINT_SPRITE
> >
> > Hi Dan et. al,
> >
> > To resolve this issue I have added a mode validity setting to
> > State::nitializeExtensionProcs(), this resolves the GL warning
> > generated by the checkvalidity_bug test program.  The fix is checked
> > into master, 3.6 branch and 3.6-TexStorage.
> >
> > Cheers,
> > Robert.
> > ___
> > osg-users mailing list
> > osg-users@lists.openscenegraph.org
> > http://lists.openscenegraph.org/listinfo.cgi/osg-users-
> openscenegraph.org
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org


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

2018-08-22 Thread Robert Osfield
On Wed, 22 Aug 2018 at 12:54, Daniel Emminizer, Code 5773
 wrote:
> It's on my list to swap over to 3.6-TexStorage to make sure it doesn't break 
> anything.  I'll do that in the next couple of days and test this out.

Thanks.

> The change looked good from a quick review on 3.6 branch.  But on master 
> branch you have "if (false)" around the code block.  I'll point out on github 
> to make it easier to find.  Looks unintentional and does not match 3.6 branch.

I'm a bit confused by this assertion as I don't see the if (false) in
the master branch.

The if (false) was added to help test whether the GL warnings were
visible with/without the fix.  I checked in removal of this.  Master
shouldn't have this, and I removed this from the 3.6 and
3.6-TexStorage where it was unintentionally checked in.

Robert.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org


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

2018-08-24 Thread Daniel Emminizer, Code 5773
Hi Robert,

Don't worry about the assertion you mentioned below: I was looking at the wrong 
branch, and it looks like your removal occurred within the same hour as my 
email.  It was just a real-life race condition. :)

The code looks fine on my side.  Fixes the immediate problem presented.

So good so far on 3.6-TexStorage branch, running on win64 VC-14 (Visual Studio 
2015).  No issues seen yet.

 - Dan


> -Original Message-
> From: osg-users [mailto:osg-users-boun...@lists.openscenegraph.org] On
> Behalf Of Robert Osfield
> Sent: Wednesday, August 22, 2018 9:29 AM
> To: OpenSceneGraph Users
> Subject: Re: [osg-users] Core Profile: glEnable/glDisable GL_POINT_SPRITE
> 
> On Wed, 22 Aug 2018 at 12:54, Daniel Emminizer, Code 5773
>  wrote:
> > It's on my list to swap over to 3.6-TexStorage to make sure it doesn't break
> anything.  I'll do that in the next couple of days and test this out.
> 
> Thanks.
> 
> > The change looked good from a quick review on 3.6 branch.  But on master
> branch you have "if (false)" around the code block.  I'll point out on github 
> to
> make it easier to find.  Looks unintentional and does not match 3.6 branch.
> 
> I'm a bit confused by this assertion as I don't see the if (false) in
> the master branch.
> 
> The if (false) was added to help test whether the GL warnings were
> visible with/without the fix.  I checked in removal of this.  Master
> shouldn't have this, and I removed this from the 3.6 and
> 3.6-TexStorage where it was unintentionally checked in.
> 
> Robert.
> ___
> osg-users mailing list
> osg-users@lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org


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

2018-08-24 Thread Robert Osfield
On Fri, 24 Aug 2018 at 13:59, Daniel Emminizer, Code 5773
 wrote:
> So good so far on 3.6-TexStorage branch, running on win64 VC-14 (Visual 
> Studio 2015).  No issues seen yet.

Thanks for the testing.  Good to hear things are working fine.  If
there no reports of issues I'll merge 3.6-TexStorage with the main 3.6
branch and make a 3-6.3-rc1.

Cheers,
Robert.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org