Re: [osg-users] The importance of using Camera::setDrawBuffer()+setReadBuffer() in application setup

[Julien Valentin]

Sorry, false alarm (shouldn't post when tired)
It was my fault forgot to rebuild my nodekits... 


mp3butcher wrote:
> I haven't followed recent developpement this last 15 days but after merging 
> my fork with master todya, all my rtt stuff saved as osgb doesn't work 
> anymore(freeze).
> You said using using osgviewer would be okay but it doesn't seams to work 
> I had setted all my view and rtt cam Read/Draw buffer to GL_BACK but nothing 
> help...
> Any idea why?
> 
> 
> robertosfield wrote:
> > Hi All,
> > 
> > A recent investigation into a bug a user was seeing in their
> > application revealed that some applications that use 3rd party
> > windowing toolkits aren't setting up the viewer Camera's correctly,
> > and I've traced this back to the examples that the OSG provides.  To
> > fix these I checked in the followinig commit that patches the various
> > osgviewer* examples:
> > 
> > https://github.com/openscenegraph/OpenSceneGraph/commit/ee3e8202779f370501a1a27c83cb9a72ad009439
> > 
> > These fixes are now checked into the OpenSceneGraph-3.4 branch and
> > master.  The changes are all in form:
> > 
> > // set the draw and read buffers up for a double buffered
> > window with rendering going to back buffer
> > camera->setDrawBuffer(GL_BACK);
> > camera->setReadBuffer(GL_BACK);
> > 
> > This explicitly tells the OSG that you wish it to render to the back
> > buffer, rather than just leave it to OpenGL defaults.  Not having
> > these calls causes problems when you do RTT work where the draw/read
> > buffer state has to be toggled between different states.  You can
> > think this of a classic uninitialized variable issue - if you don't
> > set the value you can get undefined results.
> > 
> > If you are using native osgViewer windowing it's likely that you won't
> > need to make any changes as the code in osgViewer for setting up
> > various viewer configurations do the neccessary
> > setDrawBuffer+setReadBuffer() calls.  If you are are creating the
> > graphics context and setting up the Camera's yourself then you'll need
> > to above calls.
> > 
> > If you are using a Pixel Buffer then you'd set the values to GL_FRONT,
> > or if you are using stereo buffer then you'll won't to use
> > GL_BACK_LEFT, GL_BACK_RIGHT.
> > 
> > Cheers,
> > Robert.
> > ___
> > osg-users mailing list
> > 
> > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
> > 
> >  --
> > Post generated by Mail2Forum
> 


--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=73072#73072





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

Re: [osg-users] The importance of using Camera::setDrawBuffer()+setReadBuffer() in application setup

[Robert Osfield]

Hi Julien.

On 10 March 2018 at 05:10, Julien Valentin  wrote:
> I haven't followed recent developpement this last 15 days but after merging 
> my fork with master todya, all my rtt stuff saved as osgb doesn't work 
> anymore(freeze).
> You said using using osgviewer would be okay but it doesn't seams to work
> I had setted all my view and rtt cam Read/Draw buffer to GL_BACK but nothing 
> help...
> Any idea why?

I did change RenderStage so that it used a new
osg::State::glDrawBuffers(..) + State::glReadBuffers(..) that does
lazy state updating for these GL state variables to avoid calling GL
when not necessary.  If there is any third party code that calls
glDrawBuffers/glReadBuffers but the OSG doesn't know about I guess
this could introduce problems.

During this dev work I did accidentally check-in a "cleaned up"
implementation of osg::State::glDrawBuffers(..) that called itself
rather than ::glDrawBuffers(), this caused a infinite loop.  I fixed
this yesterday so git master should be fine now.

W.r..t setting Read/Draw buffers to GL_BACK, this should only be
required for top level/viewer Camera's.

I can look into the issue if you reproduce the problem with an
existing OSG example let me know I'll try to reproduce the issue.  It
might also be worth you trying a clean check out of the OSG to see if
that changes what happens.

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

Re: [osg-users] The importance of using Camera::setDrawBuffer()+setReadBuffer() in application setup

[Julien Valentin]

I haven't followed recent developpement this last 15 days but after merging my 
fork with master todya, all my rtt stuff saved as osgb doesn't work 
anymore(freeze).
You said using using osgviewer would be okay but it doesn't seams to work 
I had setted all my view and rtt cam Read/Draw buffer to GL_BACK but nothing 
help...
Any idea why?


robertosfield wrote:
> Hi All,
> 
> A recent investigation into a bug a user was seeing in their
> application revealed that some applications that use 3rd party
> windowing toolkits aren't setting up the viewer Camera's correctly,
> and I've traced this back to the examples that the OSG provides.  To
> fix these I checked in the followinig commit that patches the various
> osgviewer* examples:
> 
> https://github.com/openscenegraph/OpenSceneGraph/commit/ee3e8202779f370501a1a27c83cb9a72ad009439
> 
> These fixes are now checked into the OpenSceneGraph-3.4 branch and
> master.  The changes are all in form:
> 
> // set the draw and read buffers up for a double buffered
> window with rendering going to back buffer
> camera->setDrawBuffer(GL_BACK);
> camera->setReadBuffer(GL_BACK);
> 
> This explicitly tells the OSG that you wish it to render to the back
> buffer, rather than just leave it to OpenGL defaults.  Not having
> these calls causes problems when you do RTT work where the draw/read
> buffer state has to be toggled between different states.  You can
> think this of a classic uninitialized variable issue - if you don't
> set the value you can get undefined results.
> 
> If you are using native osgViewer windowing it's likely that you won't
> need to make any changes as the code in osgViewer for setting up
> various viewer configurations do the neccessary
> setDrawBuffer+setReadBuffer() calls.  If you are are creating the
> graphics context and setting up the Camera's yourself then you'll need
> to above calls.
> 
> If you are using a Pixel Buffer then you'd set the values to GL_FRONT,
> or if you are using stereo buffer then you'll won't to use
> GL_BACK_LEFT, GL_BACK_RIGHT.
> 
> Cheers,
> Robert.
> ___
> osg-users mailing list
> 
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
> 
>  --
> Post generated by Mail2Forum


--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=73067#73067





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

Re: [osg-users] The importance of using Camera::setDrawBuffer()+setReadBuffer() in application setup

[Philippe Renon]

Hi,

I am the "a user" and this is how, from my perspective, the fix came about

As a contributor to LibrePilot that integrates osgEarth, I wanted to test the 
new osgEarth rex engine on Qt.
I ran into an issue, but fortunately I'm not alone and end up here : 
https://github.com/gwaldron/osgearth/issues/853.
After quite some research and personal investment I come up with what I 
consider workarounds and describe them here.
Apparently the workarounds help others too.

I look more into the issue, think I found something, so open an issue on OSG's 
GitHub [1] (https://github.com/openscenegraph/OpenSceneGraph/issues/486).
Issue gets closed within 24 hours with useful feedback.

I continue looking into the issue and want to share my findings as comments in 
the code.
So I submit a first pull request [2] 
(https://github.com/openscenegraph/OpenSceneGraph/pull/489). Big mistake !
Closed within 24 hours with "words" from "openscenegraph".

Ok my bad... I continue looking into the issue and come up with some ideas for 
a fix.
This time, as told, I post a full length message to the forum and make 
proposals for a fix.
I create a second pull request with the fix proposals [3] 
(https://github.com/openscenegraph/OpenSceneGraph/pull/493).
Again closed within 24 hours (great SLA btw) and I get shouted at. I am 
basically told go "fix your app".

Day after, a series of fixes similar to my proposed workaround are committed to 
OSG.
And the above official message is posted to the forum informing all that "a 
user" has found an issue and describing the fix.
Why the formality ? Why the rush all of a sudden ? It is not as if the issue 
had any critical or life threatening implications.
Minor bug fixes never get that much honor from OSG. They usually just get 
committed. Puzzling...

And to finish, the killer, osgEarth then commits the official OSG fix to 
osgEarth.
osgEarth fully well knew the whole story as it unfolded under its eyes and 
regularly inquired about my progress.
Kinda bad cop / good cop situation here.

Not to mention that, the day before, osgEarth borrowed another PR of mine and 
committed it without due credit (the little credit I got was on my request).

Being replied to with words like "hack", "crap", "abuse" and being shouted at 
is not what I expect to get when contributing to an open source project.
Seems like "openscenegraph" is lacking basic courtesy and is treating its 
community in ways I have not seen elsewhere.

I'll continue to use OSG and osgEarth as both projects are great but will stay 
away from its community.

If you are a would be contributor, know that it can happen to you. I have 
witnessed it happen to other contributors too.

Cheers,
Philippe.

[1] https://github.com/openscenegraph/OpenSceneGraph/issues/486
[2] https://github.com/openscenegraph/OpenSceneGraph/pull/489
[3] https://github.com/openscenegraph/OpenSceneGraph/pull/493

--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=73054#73054





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

Re: [osg-users] The importance of using Camera::setDrawBuffer()+setReadBuffer() in application setup

[Robert Osfield]

I have now created a branch on openscenegraph/osgQt repository for the
required fixes to osgQt based viewers:

   https://github.com/openscenegraph/osgQt/pull/12/files
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

[osg-users] The importance of using Camera::setDrawBuffer()+setReadBuffer() in application setup

[Robert Osfield]

Hi All,

A recent investigation into a bug a user was seeing in their
application revealed that some applications that use 3rd party
windowing toolkits aren't setting up the viewer Camera's correctly,
and I've traced this back to the examples that the OSG provides.  To
fix these I checked in the followinig commit that patches the various
osgviewer* examples:

https://github.com/openscenegraph/OpenSceneGraph/commit/ee3e8202779f370501a1a27c83cb9a72ad009439

These fixes are now checked into the OpenSceneGraph-3.4 branch and
master.  The changes are all in form:

// set the draw and read buffers up for a double buffered
window with rendering going to back buffer
camera->setDrawBuffer(GL_BACK);
camera->setReadBuffer(GL_BACK);

This explicitly tells the OSG that you wish it to render to the back
buffer, rather than just leave it to OpenGL defaults.  Not having
these calls causes problems when you do RTT work where the draw/read
buffer state has to be toggled between different states.  You can
think this of a classic uninitialized variable issue - if you don't
set the value you can get undefined results.

If you are using native osgViewer windowing it's likely that you won't
need to make any changes as the code in osgViewer for setting up
various viewer configurations do the neccessary
setDrawBuffer+setReadBuffer() calls.  If you are are creating the
graphics context and setting up the Camera's yourself then you'll need
to above calls.

If you are using a Pixel Buffer then you'd set the values to GL_FRONT,
or if you are using stereo buffer then you'll won't to use
GL_BACK_LEFT, GL_BACK_RIGHT.

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