OpenSceneGraph Forum Forum Index OpenSceneGraph Forum
Official forum which mirrors the existent OSG mailing lists. Messages posted here are forwarded to the mailing list and vice versa.
 
   FAQFAQ    SearchSearch    MemberlistMemberlist    RulesRules    UsergroupsUsergroups    RegisterRegister 
 Mail2Forum SettingsMail2Forum Settings  ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 
   AlbumAlbum  OpenSceneGraph IRC ChatOpenSceneGraph IRC Chat   SmartFeedSmartFeed 

The importance of using Camera::setDrawBuffer()+setReadBuffer() in application setup


 
Post new topic   Reply to topic    OpenSceneGraph Forum Forum Index -> General
View previous topic :: View next topic  
Author Message
robertosfield
OSG Project Lead


Joined: 18 Mar 2009
Posts: 12094

PostPosted: Wed Mar 07, 2018 9:57 am    Post subject:
The importance of using Camera::setDrawBuffer()+setReadBuffer() in application setup
Reply with quote

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.


------------------
Post generated by Mail2Forum
Back to top
View user's profile Send private message
robertosfield
OSG Project Lead


Joined: 18 Mar 2009
Posts: 12094

PostPosted: Wed Mar 07, 2018 11:08 am    Post subject:
The importance of using Camera::setDrawBuffer()+setReadBuffer() in application setup
Reply with quote

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


------------------
Post generated by Mail2Forum
Back to top
View user's profile Send private message
filnet
User


Joined: 10 Oct 2014
Posts: 55

PostPosted: Thu Mar 08, 2018 8:47 pm    Post subject:
Reply with quote

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].
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]. 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].
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
Back to top
View user's profile Send private message
mp3butcher (Julien Valentin)
Appreciator


Joined: 17 Feb 2010
Posts: 471
Location: France

PostPosted: Sat Mar 10, 2018 5:10 am    Post subject:
Re: The importance of using Camera::setDrawBuffer()+setReadBuffer() in application setup
Reply with quote

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.


------------------
Post generated by Mail2Forum
Back to top
View user's profile Send private message Visit poster's website
robertosfield
OSG Project Lead


Joined: 18 Mar 2009
Posts: 12094

PostPosted: Sat Mar 10, 2018 12:21 pm    Post subject:
The importance of using Camera::setDrawBuffer()+setReadBuffer() in application setup
Reply with quote

Hi Julien.

On 10 March 2018 at 05:10, Julien Valentin <> wrote:
Quote:
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.


------------------
Post generated by Mail2Forum
Back to top
View user's profile Send private message
mp3butcher (Julien Valentin)
Appreciator


Joined: 17 Feb 2010
Posts: 471
Location: France

PostPosted: Sat Mar 10, 2018 1:19 pm    Post subject:
Re: The importance of using Camera::setDrawBuffer()+setReadBuffer() in application setup
Reply with quote

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.


------------------
Post generated by Mail2Forum
Back to top
View user's profile Send private message Visit poster's website
Display posts from previous:   
Post new topic   Reply to topic    OpenSceneGraph Forum Forum Index -> General All times are GMT
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You cannot download files in this forum

Similar Topics
Topic Author Forum Replies Posted
No new posts ReaderWriterCFG - offset for single c... Marcin Prus Submission 0 Fri Jul 06, 2018 11:27 am View latest post
No new posts osgOcean - Render to Texture Camera rob_ewbank osgOcean [osgOcean] 3 Wed Jul 04, 2018 11:27 am View latest post
No new posts How to setup Msvcp2013 so that header... peter_k General 1 Tue Jul 03, 2018 3:14 pm View latest post
No new posts osgviewer camera initial angle. Vagn General 1 Wed Jun 20, 2018 2:31 pm View latest post
No new posts Positioning a Camera relative to anot... Takarashy General 0 Thu May 24, 2018 8:27 am View latest post


Board Security Anti Bot Question MOD - phpBB MOD against Spam Bots
Powered by phpBB © 2001, 2005 phpBB Group
Protected by Anti-Spam ACP