Re: [osg-users] OpenSceneGraph-3.2.3 maintenance release tagged

[Daniel Emminizer]

Hi,

I have downloaded and built the OSG 3.2.3 release, it works well.  But I 
noticed the version on OpenThreads is still marked as 3.2.1 (as per 
OPENTHREADS_PATCH_VERSION in src/OpenThreads/CMakeLists.txt).

Is this intentional?

Thank you.

Cheers,
Daniel

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





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

Re: [osg-users] StatsHandler missing numbers

[Daniel Emminizer]

aroth wrote:
> 
> I'm quite interested if this issue also occurs on a different OS. Let's see 
> if the OS world is different with this great new Windows 10 ;-)
> 


I've been lurking on this thread for a while.  I know it's old, but I finally 
got some time to track it down.  I've seen the exact same problems on my Intel 
4600 on Windows 10.  We've seen the problem on pretty much every Intel 4000+ 
card tested on every version of Windows for the last couple of years.  Most of 
our Linux machines with Intel also have Optimus, and we disable the Intel side 
through BIOS, so I don't have any useful Linux input.

I finally tracked down a fix, and I think it suggests a bug in the Intel 
drivers.  The problem appears to be due to issues with the textures that are 
loaded from glTexSubImage2D in Glyph.cpp.  The following patch worked well for 
us and fixed the disappearing text glyphs problem on Intel.  It works by 
reapplying the texture min filter right before the glTexSubImage2D().

Without this, depending on the size of the font, glyphs that are loaded after 
the initial set will show up either grey, or completely transparent.  NVidia 
drivers do not suffer the same problem.

I've tested on Intel 4600 and NVidia K2100m.  I've also tested the state values 
with glGetTexParameteriv(), and it appears correct prior to this code.  That 
implies to me that this is a driver bug, but I don't have enough experience to 
say for certain.  If it is a driver bug, it's been outstanding for at least a 
year, if not several years.

I could not find a way to fix this in our own code without modifying OSG code.  
I hope someone finds this useful.  I realize it is a bit of a hack.

Thanks,

 - Dan

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




Attachments: 
http://forum.openscenegraph.org//files/patchsrcosgtextglyph_159.cpp


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

Re: [osg-users] Vanishing letters in osg::Text

[Daniel Emminizer]

Hi,

We used to see this problem a lot.  The OSG_TEXT_INCREMENTAL_SUBLOADING advice 
did not help.  What did help was explicitly setting the GL_TEXTURE_MIN_FILTER 
at a slightly different place in osgText/Glyph.cpp.

Around line 373 you'll see a call to glPixelStorei() before the 
glTexSubImage2D() near the bottom of GlyphTexture::apply().  I add the 
following:

Code:

glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MIN_FILTER, 
getFilter(osg::Texture::MIN_FILTER));




Then around line 517 you'll see another call to glPixelStorei() before 
glTexSubImage2D() in Glyph::subload().  I add:


Code:

if (_texture)
glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MIN_FILTER, 
_texture->getFilter(osg::Texture::MIN_FILTER));
else
glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MIN_FILTER, 
GL_LINEAR_MIPMAP_LINEAR);




This worked on the Intel cards.  I expect it's some sort of driver bug, but I'm 
not sure.

I hope this helps.

 - Dan

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





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

Re: [osg-users] Vanishing letters in osg::Text

[Daniel Emminizer]

Hi Robert, sure thing.  I created PR 
https://github.com/openscenegraph/OpenSceneGraph/pull/251 based on 
OpenSceneGraph-3.4 branch (where I made and tested locally last year).  Thank 
you.

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





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

Re: [osg-users] Show part of geometry which intersects a specific area

[Daniel Emminizer, Code 5773]

Hi Robert,

This morning I tried the OSG 3.6.0-rc3 tag and started getting errors.  I 
tracked down the problem to the commit you reference in this email below:

https://github.com/openscenegraph/OpenSceneGraph/commit/9d5a22a0aa88125c3d41fc05bff72ae188b1a00b

Specifically the shader lines:

#ifndef GL_ES
gl_ClipVertex = gl_ModelViewMatrix * gl_Vertex;
#endif


We're trying to target the graphics cards that are supporting OpenGL Core 
profile, but not a compatibility profile.  When I run anything with text, I get 
awkward quads on the screen with various colors because this shader no longer 
compiles on the card.  It was working with the 3.6.0-rc2.

My general configuration is configuring OSG with OPENGL_PROFILE="GLCORE", then 
running with environment variable "OSG_GL_CONTEXT_VERSION=3.3".

Unfortunately I do not have any suggestions on what to do in this case; I do 
not know offhand if there is a #ifdef that you can natively use to test, but I 
can say that GL_ES is not defined in this configuration.  But I hope this email 
is helpful at least for testing the RC3 tag.  If you have any ideas I'm happy 
to test out on my side.

Thanks,

 - Dan


-Original Message-
From: osg-users [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf 
Of Robert Osfield
Sent: Friday, March 30, 2018 11:21 AM
To: OpenSceneGraph Users
Subject: Re: [osg-users] Show part of geometry which intersects a specific area

Hi Ali,

I had some time for looking into bugs this afternoon so I have modified the 
osgclip example to allow one to pass in a osgText::Text as the subgraph for 
clipping and this confirmed that clipping isn't working for osgText::Text in 
the 3.4 branch.

  osgclip --text MY_TEST

Is sufficient to run the new test.  You'll need update to 3.4 banch,
3.6 branch or master to get this example.  The commit that provides the new 
test code is:

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

I have done a review of the osgText::Text implementation in the 3.4 branch and 
can't see any where when clipping is explicitly disabled so I'm surprised it's 
not functioning OK.  Unfortunately I couldn't spot any good lead to 
investigate, I can only guess that there is some interaction with the way the 
the old osgText 3.4 code renders text using a multi-pass approach where is 
toggles on/off the color mask and depth writes.  Without an obvious reason for 
failure I can't see a way of resolving the problem for the 3.4 branch.

The test also failed with OSG master and the new OpenScenGraph-3.6 branch, but 
this was easy to fix as osgText implementation has been almost completely 
rewritten since 3.4, and now uses shaders.  The fix was simply the add setting 
of the gl_ClipVertex into the shader and then the everything works fine.  The 
new osgText implementation doesn't implement using lots of toggling of state or 
is saddled with multi-pass approach so is cleaner, as well as provides better 
visual quality and some new approaches such as using Signed Distance Function 
(you need to enable this on osgText::Font to use it.)

The fix to the OpenSceneGraph-3.6 branch is:


https://github.com/openscenegraph/OpenSceneGraph/commit/9d5a22a0aa88125c3d41fc05bff72ae188b1a00b

I also updated the OpenSceneGraph-Data as this contains the shaders/text.vert 
this is embedded in the source of the osgText library - which the above commit 
modifies.

As the OpenSceneGrpah-3.6.0 stable release is imminent, I would suggest just 
moving to the 3.6 branch or the release candidate 3 branch I'll be making this 
afternoon, as this should resolve the problem you are seeing.

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] Show part of geometry which intersects a specific area

[Daniel Emminizer, Code 5773]

Hi Robert,

I was able to test your patch and it works great.  Thank you for the support.

 - Dan


-Original Message-
From: osg-users [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf 
Of Robert Osfield
Sent: Monday, April 02, 2018 11:24 AM
To: OpenSceneGraph Users
Subject: Re: [osg-users] Show part of geometry which intersects a specific area

On 2 April 2018 at 16:13, Robert Osfield  wrote:
> Hi Dan,
>
> I think an addition of the __VERSION__ check to the text.vert shader 
> should be sufficient. I am doing a GL3 build to see if I can reproduce 
> the issue, once I have I'll figure out a fix in the shader.

I have checked in a fix to master and 3.6 branch:

/https://github.com/openscenegraph/OpenSceneGraph/commit/6c055e34003312d54ffde87b881d71080361041b

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

[osg-users] CompositeViewer Bug with Scroll Events

[Daniel Emminizer, Code 5773]

Hello,

I've been working on testing the 3.6.0-rc3 OpenSceneGraph in an application 
that was previously using 3.4.1.  I found what I think is a bug with the 
GUIEventAdapter::SCROLL handling when using a CompositeViewer.  I also come 
with a potential fix.

The symptom I'm seeing is that when I use CompositeViewer, I'm getting a SCROLL 
event in my GUIEventHandler, one for each view.  In 3.4.1 I was only getting it 
for the view under the mouse, same as clicks and other mouse operations.

Looking at old 3.4.1 CompositeViewer, the SCROLL event is being sent by default 
to only the focus view.

In the 3.6 CompositeViewer, the SCROLL event defaults to EVENT_FOR_ALL_VIEWS.  
I think the focused view for SCROLL seems more correct.


I am submitting a PR on the 3.6 branch for this.  I'm happy to redo the PR if I 
messed something up.  The PR is at: 

https://github.com/openscenegraph/OpenSceneGraph/pull/518


Thanks,

 - Dan

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

Re: [osg-users] OpenScenGraph 3.6 release candidate 5 tagged

[Daniel Emminizer, Code 5773]

Hi Robert,

Looking good so far here with testing on GL Core 3.3.  Main concerns is that 
it's noisy on the console.  You just pushed a commit that helps with this in 
DisplaySettings::setShaderHint().  But I still see:

1) osgText prints errors about "Error reading file shaders/text.frag: file not 
found", but correctly falls back to built-in shader.  Same with text.vert.  One 
fix for this is to use a custom version of readRefShaderFileWithFallback() in 
osgText/Text.cpp but obviously that's messy.

Other options include requiring end user apps to always package those files, or 
to always intercept the search with osgDB tricks.


2) Drawable::createVertexArrayStateImplementation() still has an OSG_NOTICE 
that spams the console in some of our apps.  Would recommend OSG_INFO or 
commenting out.


No other concerns at this point.  Thank you for the excellent software.

 - Dan


-Original Message-
From: osg-users [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf 
Of Robert Osfield
Sent: Wednesday, April 04, 2018 10:46 AM
To: OpenSceneGraph Users
Subject: [osg-users] OpenScenGraph 3.6 release candidate 5 tagged

Hi All,

I have just tagged 3.6.0-rc5:

   https://github.com/openscenegraph/OpenSceneGraph


I'm pretty well ready to release now.  But is the code?  I need feedback from 
the community now on build and runtime performance.

All going well I'll tag 3.6.0.

Thanks in advance for all the final testing you can do.  As before let me know 
of success as well as failure.

Cheers,
Robert.

-- ChangeLog since rc4:


Wed, 4 Apr 2018 15:09:43 +0100
Author : Robert Osfield
Fixed threading crash in osgFX that occurred when an osgFX node is added to the 
scene being rendered in multiple threaded windows.

Wed, 4 Apr 2018 13:40:51 +0100
Author : Robert Osfield
Added focus classifiction of handling of keyboard events

Wed, 4 Apr 2018 13:40:06 +0100
Author : Robert Osfield
Added EventHandler to report key and mouse events for debugging purposes

Wed, 4 Apr 2018 12:26:53 +0100
Author : Robert Osfield
Added -4 command line entry that creates two seperate windows within 
CompositeViewer

Wed, 4 Apr 2018 08:50:39 +0100
Author : Frank Bausch
When testing XYZ/ECEF coordinate values that convert to LLA points with 
latitude = 90.0 or latitude = -90.0, the heights calculated by 
EllipsoidModel::convertXYZToLatLongHeight have substantial errors.
With the provided change, points at
 the pole are handled more correctly. This has been tested against US NGA 
GoldData.

Tue, 3 Apr 2018 17:21:47 +0100
Author : Robert Osfield
Updated rc to 5

Tue, 3 Apr 2018 17:17:59 +0100
Author : OpenSceneGraph git repository
Merge pull request #518 from
emminizer/fix-scroll-eventCompositeViewer: SCROLL event now only goes to view 
with focus.  Incl…

robert@katrine:~/temp/OpenSceneGraph-3.6$ more ChangeLog Wed, 4 Apr 2018 
15:09:43 +0100 Author : Robert Osfield Fixed threading crash in osgFX that 
occurred when an osgFX node is added to the scene being rendered in multiple 
threaded windows.

Wed, 4 Apr 2018 13:40:51 +0100
Author : Robert Osfield
Added focus classifiction of handling of keyboard events

Wed, 4 Apr 2018 13:40:06 +0100
Author : Robert Osfield
Added EventHandler to report key and mouse events for debugging purposes

Wed, 4 Apr 2018 12:26:53 +0100
Author : Robert Osfield
Added -4 command line entry that creates two seperate windows within 
CompositeViewer

Wed, 4 Apr 2018 08:50:39 +0100
Author : Frank Bausch
When testing XYZ/ECEF coordinate values that convert to LLA points with 
latitude = 90.0 or latitude = -90.0, the heights calculated by 
EllipsoidModel::convertXYZToLatLongHeight have substantial errors.
With the provided change, points at
 the pole are handled more correctly. This has been tested against US NGA 
GoldData.

Tue, 3 Apr 2018 17:21:47 +0100
Author : Robert Osfield
Updated rc to 5

Tue, 3 Apr 2018 17:17:59 +0100
Author : OpenSceneGraph git repository
Merge pull request #518 from
emminizer/fix-scroll-eventCompositeViewer: SCROLL event now only goes to view 
with focus.  Incl… ___
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] OpenScenGraph 3.6 release candidate 5 tagged

[Daniel Emminizer, Code 5773]

Hi Robert,

Minor build error on Windows.  Missing "extern OSGDB_EXPORT" on the function 
change in ReadFile.  Once I fixed that -- 
https://github.com/openscenegraph/OpenSceneGraph/pull/525 -- everything in your 
change works great.  Thank you,

 - Dan


-Original Message-
From: osg-users [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf 
Of Robert Osfield
Sent: Thursday, April 05, 2018 9:23 AM
To: OpenSceneGraph Users
Subject: Re: [osg-users] OpenScenGraph 3.6 release candidate 5 tagged

Hi Dan,

On 5 April 2018 at 13:18, Daniel Emminizer, Code 5773 
 wrote:
> Looking good so far here with testing on GL Core 3.3.  Main concerns is that 
> it's noisy on the console.  You just pushed a commit that helps with this in 
> DisplaySettings::setShaderHint().  But I still see:

Thanks for the testing.

> 1) osgText prints errors about "Error reading file shaders/text.frag: file 
> not found", but correctly falls back to built-in shader.  Same with 
> text.vert.  One fix for this is to use a custom version of 
> readRefShaderFileWithFallback() in osgText/Text.cpp but obviously that's 
> messy.
>
> Other options include requiring end user apps to always package those files, 
> or to always intercept the search with osgDB tricks.
>
>
> 2) Drawable::createVertexArrayStateImplementation() still has an OSG_NOTICE 
> that spams the console in some of our apps.  Would recommend OSG_INFO or 
> commenting out.

I have checked in a fix for this noisy debug output:


https://github.com/openscenegraph/OpenSceneGraph/commit/914e60a8723b0306daef7dd7d8b3839f4b84d84b

> No other concerns at this point.  Thank you for the excellent software.

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] OpenSceneGraph-3.6.0 release candidate 6

[Daniel Emminizer, Code 5773]

Hi Robert,

I've been testing the RC5 and I have a problem with text.  I saw PR # 523 and 
thought it might be the same problem.  It looks quite similar to the issue I'm 
seeing.  I updated to RC6 (includes PR 523) and things look a lot better, but 
not completely fixed.

I have finally been able to reproduce this in native OSG without any extra 
libraries.  Attached is a .cpp modification of the osgtext example that 
demonstrates the problem.  This is tested on RC6.


The text "Left" is on the left side, and (correctly) shifts position each frame 
(up and down).  This is important, because the position changes every frame.  
But the bounding box on the Left text (incorrectly) keeps getting bigger and 
bigger.

The text "Right" is on the right side, and its position is set to the right 
side of "Left" text, based on Left's bounding box.  You'll see it float to the 
right as the frames redraw.  I would expect "Right" to stay in the same place 
horizontally, but it does not.


The problem seems to be related to:
1) Changing the position of the text to a new position
2) Having a drop shadow


Unfortunately I do not know how to fix this.  I can work on it if you 
want/need, but perhaps you see the problem right away?  Please let me know if 
the attachment osgtext.cpp doesn't come through for some reason.

 - Dan


-Original Message-
From: osg-users [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf 
Of Robert Osfield
Sent: Friday, April 06, 2018 10:02 AM
To: OpenSceneGraph Users
Subject: [osg-users] OpenSceneGraph-3.6.0 release candidate 6

Hi All,

I have just tagged release candidate 6:


https://github.com/openscenegraph/OpenSceneGraph/tree/OpenSceneGraph-3.6.0-rc6

I'm really hoping this is now and we are good to go.  If things are
building and running OK I'll tag 3.6.0 tomorrow.   So yet another big
PLEASE test :-)

Let us know about success or failures so we know where we are at for the 
release.

Thankyou!
Robert.

--Changes since rc5

Fri, 6 Apr 2018 14:47:54 +0100
Author : Robert Osfield
Updated for rc6

Fri, 6 Apr 2018 14:17:35 +0100
Author : Robert Osfield
Fixed warning

Fri, 6 Apr 2018 14:07:58 +0100
Author : Robert Osfield
Changed TextBase::setAlignment() to use computeGlyphRepresentation(); rather 
than computePositions(); to address issues seen with calling
Text::setAlignment() after calls to Text::setText()

Fri, 6 Apr 2018 14:06:50 +0100
Author : Robert Osfield
Added osgtext --alignment test to look the effect of calling
Text::setAlignent() before and after the Text::setText().

Thu, 5 Apr 2018 18:00:30 +0100
Author : OpenSceneGraph git repository
Merge pull request #525 from emminizer/fix-windows-exportosgDB: Added missing 
extern OSGDB_EXPORT.

Thu, 5 Apr 2018 10:51:24 -0400
Author : Daniel Emminizer
osgDB: Added missing extern OSGDB_EXPORT.

Thu, 5 Apr 2018 14:14:49 +0100
Author : Robert Osfield
Quietened down debug message output for osgText shader setup and 
Drawable::createVertexArrayStateImplementation

Thu, 5 Apr 2018 12:35:36 +0100
Author : Robert Osfield
Changed DisplaySettings::setShaderHint(..) messages to INFO

Thu, 5 Apr 2018 12:19:56 +0100
Author : Robert Osfield
Updated ChangeLOG and news

Thu, 5 Apr 2018 11:21:55 +0200
Author : Philippe Renon
mingw: fix compile error in GraphicsWindowWin32.cppcompilation error was 
introduced by msvc specific change see 
https://github.com/openscenegraph/OpenSceneGraph/commit/bb169979a1054e2fa63a7ea82c9c8bec87e90494
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
/* OpenSceneGraph example, osgtext.
*
*  Permission is hereby granted, free of charge, to any person obtaining a copy
*  of this software and associated documentation files (the "Software"), to deal
*  in the Software without restriction, including without limitation the rights
*  to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
*  copies of the Software, and to permit persons to whom the Software is
*  furnished to do so, subject to the following conditions:
*
*  THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
*  IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
*  FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
*  AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
*  LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
*  OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
*  THE SOFTWARE.
*/

#include 
#include 

#include 
#include 
#include 

#include 

#include 
#include 

class UpdateText : public osgGA::GUIEventHandler
{
public:
  UpdateText(osgText::Text* left, osgText::Text* right)
: left_(left), right_(right), flipText_(false)
  {
  }

  virtual bool handle

Re: [osg-users] OpenSceneGraph-3.6.0 release candidate 6

[Daniel Emminizer, Code 5773]

Hi Robert,

Thanks again for the support.  I pulled your latest with this fix and it fixes 
my small demo app and the bigger application I'm building too!  I'm sorry to 
drop bugs on you last minute, I only was able to verify it was an OSG issue 
finally this morning.

I do not think I have any other bugs on the horizon!  Looks good from here.  
Have a good weekend,

 - Dan



-Original Message-
From: osg-users [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf 
Of Robert Osfield
Sent: Friday, April 06, 2018 3:15 PM
To: OpenSceneGraph Users
Subject: Re: [osg-users] OpenSceneGraph-3.6.0 release candidate 6

Hi Dan,

I was s hoping that all would be OK and I could take the whole evening 
off...  However, It's far better to catch stuff before a release than after 
though, so I appreciate your efforts on testing.

I have reproduce the ever expanding bounding box thanks to the you test 
program, and a bit of debugging revealed that it's the increase in _textBB size 
due to apply margin and the shadow offsets on each
setPosition() call.  The only proper fix I could come up with was to introduce 
a _textBBWithMargin so that the margin+shadows don't affect the main _textBB.  
This change required far more lines of code to be changed than I'd like to do 
this close to a release, but I feel it's worth the risk to solve the problem.  
Fingers crossed I don't introduce any regressions with this change.

I have checked in the changes to OSG master the and the
OpenSceneGraph-3.6 branch.

   
https://github.com/openscenegraph/OpenSceneGraph/commit/6bfca1582efae9606e18883971c95eb734d70058

If this works OK then I'll tag a rc7.

Cheers,
Robert.



On 6 April 2018 at 17:08, Daniel Emminizer, Code 5773 
 wrote:
> Hi Robert,
>
> I've been testing the RC5 and I have a problem with text.  I saw PR # 523 and 
> thought it might be the same problem.  It looks quite similar to the issue 
> I'm seeing.  I updated to RC6 (includes PR 523) and things look a lot better, 
> but not completely fixed.
>
> I have finally been able to reproduce this in native OSG without any extra 
> libraries.  Attached is a .cpp modification of the osgtext example that 
> demonstrates the problem.  This is tested on RC6.
>
>
> The text "Left" is on the left side, and (correctly) shifts position each 
> frame (up and down).  This is important, because the position changes every 
> frame.  But the bounding box on the Left text (incorrectly) keeps getting 
> bigger and bigger.
>
> The text "Right" is on the right side, and its position is set to the right 
> side of "Left" text, based on Left's bounding box.  You'll see it float to 
> the right as the frames redraw.  I would expect "Right" to stay in the same 
> place horizontally, but it does not.
>
>
> The problem seems to be related to:
> 1) Changing the position of the text to a new position
> 2) Having a drop shadow
>
>
> Unfortunately I do not know how to fix this.  I can work on it if you 
> want/need, but perhaps you see the problem right away?  Please let me know if 
> the attachment osgtext.cpp doesn't come through for some reason.
>
>  - Dan
>
>
> -Original Message-
> From: osg-users [mailto:osg-users-boun...@lists.openscenegraph.org] On 
> Behalf Of Robert Osfield
> Sent: Friday, April 06, 2018 10:02 AM
> To: OpenSceneGraph Users
> Subject: [osg-users] OpenSceneGraph-3.6.0 release candidate 6
>
> Hi All,
>
> I have just tagged release candidate 6:
>
> 
> https://github.com/openscenegraph/OpenSceneGraph/tree/OpenSceneGraph-3
> .6.0-rc6
>
> I'm really hoping this is now and we are good to go.  If things are
> building and running OK I'll tag 3.6.0 tomorrow.   So yet another big
> PLEASE test :-)
>
> Let us know about success or failures so we know where we are at for the 
> release.
>
> Thankyou!
> Robert.
>
> --Changes since rc5
>
> Fri, 6 Apr 2018 14:47:54 +0100
> Author : Robert Osfield
> Updated for rc6
>
> Fri, 6 Apr 2018 14:17:35 +0100
> Author : Robert Osfield
> Fixed warning
>
> Fri, 6 Apr 2018 14:07:58 +0100
> Author : Robert Osfield
> Changed TextBase::setAlignment() to use computeGlyphRepresentation(); 
> rather than computePositions(); to address issues seen with calling
> Text::setAlignment() after calls to Text::setText()
>
> Fri, 6 Apr 2018 14:06:50 +0100
> Author : Robert Osfield
> Added osgtext --alignment test to look the effect of calling
> Text::setAlignent() before and after the Text::setText().
>
> Thu, 5 Apr 2018 18:00:30 +0100
> Author : OpenSceneGraph git repository Merge pull request #525 from 
> emminizer/fix-windows-exportosgDB: Added missing extern OSGDB_EXPORT.

Re: [osg-users] Please test OpenSceneGraph-3.6 branch in prep for 3.6.1

[Daniel Emminizer, Code 5773]

Hi Robert,

> Please let me know of success and failures, or any bugs you've seen in
> 3.6.0 but haven't reported yet :-)

We've had a lot of success, and a couple of minor issues.  Most of our issues 
are with either running in GL Core 3.3, or using osgText.  I'm trying to narrow 
down the scope a bit but thought I should send an email before too long.


1) Default GL version with GLCORE

During start-up of most applications we see:
GL3: Non-GL3 version number: 1.0

I can mitigate this by manually setting OSG_GL_CONTEXT_VERSION=3.3 in 
environment.  Would it make more sense to, in GLCORE config, to default the 
DisplaySettings.cpp _glContextVersion to "3.3" instead of "1.0" ?  I can submit 
a PR if desired.


2) osgText backdrop looks very poor with smaller fonts

We have a HUD in our application that uses "normal" sized text -- about what 
you'd see in a typical console application.  We've been using 
osgText::Text::DROP_SHADOW_BOTTOM_RIGHT but in 3.6.x it looks much worse than I 
remember it looking in 3.4.  You can see what I mean by editing osgtext.cpp and 
adding the DROP_SHADOW_BOTTOM_RIGHT to text5.  It's more apparent with smaller 
text at about character size 24.

It's almost like there's too much alpha blending in the text and it just isn't 
crisp and readable.  You can see similar effects with OUTLINE, but it's still 
nowhere as crisp as NONE.

The osgText demo (even with those edits) does not do justice to the problem I'm 
seeing.  I'm working on a good demonstration of the problem I'm seeing.



3) Text Bounding Box calculation changes per frame

I'm seeing incorrect bounding box calculations on text still that uses drop 
shadows.  This matters for us because we have column based HUD text that 
depends on the width of the previous column.  I have been able to duplicate 
this in osgtext.cpp example.  I am attaching a osgtext.cpp that reproduces it 
with cout statements.

I want to come up with a better example, but in the interest of time I hope 
this suffices.  In our real code, we're seeing a horizontal shift of 0.5 
pixels, but the example here only shows a shift of 0.02.  In the real example, 
the shift is dramatic enough, that when coupled with #2, it looks like the text 
shimmers bright and dark with the drop shadow showing through sometimes.  It's 
very distracting, and not seen in the 3.4.

In the change, I added UpdateTextCallback to text5 instance.  It updates the 
text string, and makes sure the drop shadow is right.  I then call 
getBoundingBox() and print out xMax() - xMin(), yMax() - yMin(), etc.  If there 
is no drop shadow, then there's no change in values.  If there is a drop 
shadow, the values change every frame.

Also, the text's actual drawn bounding area (white square from 
setDrawMode(TEXT|BOUNDINGBOX)) is correct at all times.  Can you explain why 
that is not the same bounding area as getBoundingBox(), which does change?  
Probably a misunderstanding on my part.


4) BOUNDINGBOX Draw Mode Offset Issue

This one is completely cosmetic and possibly working as intended.  In 
osgtext.cpp there's an osg::Sequence that shows alignments around a crosshair.  
The RIGHT_BOTTOM text is not lined up with the bounding box square.  Is this 
intentional?  I attached a screenshot of the blown up portion.  It looks 
completely aligned with the backdrop disabled (NONE).



I'm still working on trying to get an example of #2 together if I can.

Thanks for your time,

 - Dan

/* OpenSceneGraph example, osgtext.
*
*  Permission is hereby granted, free of charge, to any person obtaining a copy
*  of this software and associated documentation files (the "Software"), to deal
*  in the Software without restriction, including without limitation the rights
*  to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
*  copies of the Software, and to permit persons to whom the Software is
*  furnished to do so, subject to the following conditions:
*
*  THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
*  IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
*  FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
*  AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
*  LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
*  OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
*  THE SOFTWARE.
*/

#include 

#include 
#include 
#include 

#include 
#include 
#include 

#include 
#include 
#include 
#include 
#include 
#include 

#include 
#include 

osg::Group* createHUDText()
{

osg::Group* rootNode = new osg::Group;

osg::ref_ptr font = 
osgText::readRefFontFile("fonts/arial.ttf");

//osg::setNotifyLevel(osg::INFO);

osg::Geode* geode  = new osg::Geode;
rootNode->addChild(geode);

float windowHeight = 1024.0f;
float windowWidth = 1280.0f;
float margin = 50.0f;

/

Re: [osg-users] Please test OpenSceneGraph-3.6 branch in prep for 3.6.1

[Daniel Emminizer, Code 5773]

Hi Robert,

> I am not at my dev system right now

No problem, I just didn't want to miss the window for bug reporting.  I'm about 
to head out for the day so I'll put together that PR for the version tomorrow 
morning.


> Given it's just a debug feature it only using the inner text bounding box is 
> OK with me.

Sounds good to me too then.


> I haven't looked at your modified code yet, as a general comment, then more 
> focused a test case is at reproducing
> the problem at hand the easiest it is for me to confirm the issue and then 
> use it as a test case.

Agreed, I've been working on that today.

I think I found the missing link for my significant text issues.  The problem 
is much worse with arial.ttf than it is with the default times.ttf.  Instead of 
seeing a difference of +/- 0.02 units of width, I'm seeing a difference of 3.0 
units of width.  The "Long Text String" text shifts left and right constantly.

I also added a status display text to the lower left that is similar to 
something we're doing in our HUD.  In arial you can see the text bouncing.  If 
you press "2", it changes between Times and Arial:
- Times looks worse than Arial with a drop shadow, at the same font size
- You can see the fading effect in Arial as the text moves left and right

You can also toggle the lower-left corner's drop shadow using the "1" key.  The 
intent is to demonstrate that the shifting text is not due to the shadow as I 
first thought.  It also is intended to demonstrate the visibility problems I am 
having.  We had been using drop shadows to make the text more readable against 
similar colored backgrounds.  But in 3.6, it actually makes it harder to read 
the same text, especially at smaller font size.

You can find demonstrations of this in the attached osgtext.cpp.  Feel free to 
ignore the first attachment -- this includes those changes and more, with only 
the relevant code and not the rest of osgtext.

I hope this example helps demonstrate the problems I'm seeing.

As always, thanks for your time with this issue.

 - Dan

/* OpenSceneGraph example, osgtext.
*
*  Permission is hereby granted, free of charge, to any person obtaining a copy
*  of this software and associated documentation files (the "Software"), to deal
*  in the Software without restriction, including without limitation the rights
*  to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
*  copies of the Software, and to permit persons to whom the Software is
*  furnished to do so, subject to the following conditions:
*
*  THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
*  IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
*  FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
*  AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
*  LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
*  OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
*  THE SOFTWARE.
*/

#include 
#include 

#include 

#include 
#include 
#include 

#include 
#include 

#include 
#include 



std::string printRightText(double angle)
{
std::stringstream ss;
ss << "Press 2 to change the font between\n"
<< "arial and times.\n"
<< std::fixed << std::setprecision(1) << angle << "\n";
return ss.str();
}

struct UpdateColumnPosition : public osg::Callback
{
UpdateColumnPosition(osgText::Text* leftText, osgText::Text* rightText)
  : angleValue(0.0),
left(leftText),
right(rightText)
{
}

virtual bool run(osg::Object* object, osg::Object* data)
{
angleValue = fmod(angleValue + 1.7, 360.0);
right->setText(printRightText(angleValue));

// Position the text appropriately
left->setPosition(osg::Vec3f(10.0, 10.0, 0.0));
osg::BoundingBox bb = left->getBoundingBox();
const float width = bb.xMax() - bb.xMin();
right->setPosition(osg::Vec3f(10.0 + width + 30.0, 10.0, 0.0));

return traverse(object, data);
}

double angleValue;
osg::ref_ptr left;
osg::ref_ptr right;
};

struct ToggleLeftRightTextSettings : public osgGA::GUIEventHandler
{
ToggleLeftRightTextSettings(osgText::Text* leftText, osgText::Text* 
rightText)
  : left(leftText),
right(rightText),
useShadow(true),
useArial(true)
{
}

virtual bool handle(const osgGA::GUIEventAdapter& ea, 
osgGA::GUIActionAdapter& aa, osg::Object*, osg::NodeVisitor*)
{
if (ea.getEventType() == ea.KEYDOWN)
{
if (ea.getKey() == '1')
{
useShadow = !useShadow;
left->setBackdropType(useShadow ? 
osgText::Text::DROP_SHADOW_BOTTOM_RIGHT : osgText::Text::NONE);
right->setBackdropType(left->getBackdropType());
return true;
}
  

Re: [osg-users] Please test OpenSceneGraph-3.6 branch in prep for 3.6.1

[Daniel Emminizer, Code 5773]

Hi Robert,

This looks much more crisp and easier to read both in the modified osgtext 
example and in our end application.  The difference is night and day.  Thanks 
for taking a look at this.

I am currently testing the OSG_GL3_FEATURES change for defaulting version to 
3.3, and still plan to have a PR in the next hour or two once my builds finish.

 - Dan


-Original Message-
From: osg-users [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf 
Of Robert Osfield
Sent: Tuesday, April 24, 2018 7:22 AM
To: OpenSceneGraph Users
Subject: Re: [osg-users] Please test OpenSceneGraph-3.6 branch in prep for 3.6.1

Hi Daniel,

On 23 April 2018 at 20:46, Daniel Emminizer, Code 5773 
 wrote:
> I also added a status display text to the lower left that is similar to 
> something we're doing in our HUD.  In arial you can see the text bouncing.  
> If you press "2", it changes between Times and Arial:
> - Times looks worse than Arial with a drop shadow, at the same font 
> size
> - You can see the fading effect in Arial as the text moves left and 
> right
>
> You can also toggle the lower-left corner's drop shadow using the "1" key.  
> The intent is to demonstrate that the shifting text is not due to the shadow 
> as I first thought.  It also is intended to demonstrate the visibility 
> problems I am having.  We had been using drop shadows to make the text more 
> readable against similar colored backgrounds.  But in 3.6, it actually makes 
> it harder to read the same text, especially at smaller font size.
>
> You can find demonstrations of this in the attached osgtext.cpp.  Feel free 
> to ignore the first attachment -- this includes those changes and more, with 
> only the relevant code and not the rest of osgtext.
>
> I hope this example helps demonstrate the problems I'm seeing.

The example makes the shadow quality clear. In the case of arial.ttf, it's a 
font that has body of the glyph pixel wide or even alpha'd at the default font 
resolution of 32x32 so causes more problems when you start blending, which is 
why things look worst for arial.ttf.

I have experimented with various changes to the 
OpenSceneGraph-Data/shaders/text.frag shader that does the fragment shading for 
osgText (in 3.6 onwards). I've found that applying a power function to the 
alpha value of the glyph and it's shadow results in clear text and shadow, and 
overall I think this is a decent enough improvement to consider.  I've attached 
my OpenSceneGraph-Data/shaders/text.frag, could you copy this into your 
OpenSceneGraph-Data/shaders directory (if you don't have one yet check it out 
and then make sure OSG_FILE_PATH points to the location of your
OpenSceneGraph-Data.)  If this works better then I'll regenerate the shaders 
that are built into osgText (see src/osgText/shaders/*.cpp.)

I have yet looked at the bounding box side of things in detail.

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

Re: [osg-users] Please test OpenSceneGraph-3.6 branch in prep for 3.6.1

[Daniel Emminizer, Code 5773]

Hi Terry,

Hey I might know this one.  Thanks for that additional info about your driver.  
Do you mind retesting with a change?

See references:

- 
https://devtalk.nvidia.com/default/topic/971330/opengl/bug-report-crash-in-glcompileshader-if-using-pragma/
- 
https://software.intel.com/en-us/forums/graphics-driver-bug-reporting/topic/623485
- https://github.com/gwaldron/osgearth/issues/1017
- https://github.com/gwaldron/osgearth/pull/1106
- https://github.com/gwaldron/osgearth/pull/1100

There are some older intel drivers that crash on shaders that include pragmas 
with too many "arguments".  The spec says that pragmas should be ignored.  But 
testing demonstrates severe problems with several intel drivers over a few 
years' period where lines like:

#pragma import_defines( BACKDROP_COLOR, SHADOW, OUTLINE, SIGNED_DISTANCE_FIELD, 
TEXTURE_DIMENSION, GLYPH_DIMENSION)

... could cause a failure.  Breaking it up into separate lines of no more than 
2 arguments each works.

We found that the magic number for drivers is 3 -- once you get over 3 
parameters, it starts to break (depending on driver version).  Could you try to 
edit your text.frag file to change:

#pragma import_defines( BACKDROP_COLOR, SHADOW, OUTLINE, SIGNED_DISTANCE_FIELD, 
TEXTURE_DIMENSION, GLYPH_DIMENSION)

To:

#pragma import_defines( BACKDROP_COLOR, SHADOW, OUTLINE)
#pragma import_defines( SIGNED_DISTANCE_FIELD, TEXTURE_DIMENSION, 
GLYPH_DIMENSION)

This breaks it into 2 lines of 3 params each.  If it's the same bug that we 
encountered, this might fixyour problem.

Robert, I haven't reported this because we haven't explicitly ran into this 
same problem with 3.6 and text shaders yet, because we haven't run on those 
drivers.  Newer drivers do fix the issue.

 - Dan


-Original Message-
From: osg-users [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf 
Of Terry Welsh
Sent: Wednesday, April 25, 2018 11:10 AM
To: osg-users@lists.openscenegraph.org
Subject: Re: [osg-users] Please test OpenSceneGraph-3.6 branch in prep for 3.6.1

Looks like I had a graphics driver problem. Originally, I didn't think
that was the problem because the computer I'm working on has dual
graphics and it was crashing in Intel graphics mode and AMD graphics
mode. As it turns out, my dual graphics was broken and running Intel
graphics the whole time.

Now that's fixed and both drivers are broken, but at least they're
broken in different ways :P Sorry for the false alarm.
- Terry

P.S. Buy NVidia graphics.

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

Re: [osg-users] Please test OpenSceneGraph-3.6 branch in prep for 3.6.1

[Daniel Emminizer, Code 5773]

Hi Robert,

> Head in hands moment...

Tell me about it!  Took quite a long time to narrow down the crash to this one 
issue.

> If it is a case that a driver update fixes it so that very few machines out 
> there will ever hit this issue then perhaps just telling users to update 
> drivers is the thing to do.

Depends on your perspective of "very few machines".  We have many users on the 
old drivers that can't update due to their IA environment and other 
administrative reasons.  I think this was only fixed in drivers in the last 
year or so.  However, we can always ship out an updated text.frag when/if it 
gets to that point.

In our field we're seeing a lot of those Intel graphics chips out there.  I'd 
estimate a solid half of our users are still on Intel.  I personally think it's 
worth a fix (and I'm happy to PR it if desired), but I'm biased too. :)

Thanks,

 - Dan


-Original Message-
From: osg-users [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf 
Of Robert Osfield
Sent: Wednesday, April 25, 2018 12:41 PM
To: OpenSceneGraph Users
Subject: Re: [osg-users] Please test OpenSceneGraph-3.6 branch in prep for 3.6.1

Hi Dan & Terry,

Oh boy, that's a classy driver bug.  You would have thought a company
that develops CPU compilers would know how to write a parser that
handles #pragma properly... you really have to try hard to write bad
code to come up with a bug like this.

Head in hands moment...

Given the possible fix is so simple I'm inclined to merge it rather
than just push the problem back on users.  Terry could you modify
OpenSceneGraph-Data/shaders/text.vert and text.frag to make sure that
#pragma lines are all three or less parameters.

If it is a case that a driver update fixes it so that very few
machines out there will ever hit this issue then perhaps just telling
users to update drivers is the thing to do.

Robert.


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

Re: [osg-users] Please test OpenSceneGraph-3.6 branch in prep for 3.6.1

[Daniel Emminizer, Code 5773]

Hi Robert,

Sorry, was already out for the day yesterday by the time this was sent.  It 
looks like you already took care of it.

I will be rebuilding the 3.6.1 RC then I'll coordinate with my colleague who 
has the Intel machine when he's in for testing confirmation.  Will report back 
in a few hours when he's in.

 - Dan
 

-Original Message-
From: osg-users [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf 
Of Robert Osfield
Sent: Wednesday, April 25, 2018 2:55 PM
To: OpenSceneGraph Users
Subject: Re: [osg-users] Please test OpenSceneGraph-3.6 branch in prep for 3.6.1

Hi Dan,

Could you get teh text.frag working on your machines and then a PR for
OpenSceneGraph-Data for it.  I can then run osg2cpp on it to update
the OSG version.

Thanks,
Robert

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

Re: [osg-users] Please test OpenSceneGraph-3.6 branch in prep for 3.6.1

[Daniel Emminizer, Code 5773]

Hi Robert,

I was able to test on the Intel machine a few minutes ago.  It indeed did work 
with your updated shader.  It also crashed as expected when I backed out your 
pragma change.  So your change works.  All good from this side.

I'll pass along word if I run into any problems in the new release candidate.

Thanks,

 - Dan


-Original Message-
From: Daniel Emminizer, Code 5773 
Sent: Thursday, April 26, 2018 6:11 AM
To: OpenSceneGraph Users
Subject: RE: [osg-users] Please test OpenSceneGraph-3.6 branch in prep for 3.6.1

Hi Robert,

Sorry, was already out for the day yesterday by the time this was sent.  It 
looks like you already took care of it.

I will be rebuilding the 3.6.1 RC then I'll coordinate with my colleague who 
has the Intel machine when he's in for testing confirmation.  Will report back 
in a few hours when he's in.

 - Dan
 

-Original Message-
From: osg-users [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf 
Of Robert Osfield
Sent: Wednesday, April 25, 2018 2:55 PM
To: OpenSceneGraph Users
Subject: Re: [osg-users] Please test OpenSceneGraph-3.6 branch in prep for 3.6.1

Hi Dan,

Could you get teh text.frag working on your machines and then a PR for
OpenSceneGraph-Data for it.  I can then run osg2cpp on it to update
the OSG version.

Thanks,
Robert

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

Re: [osg-users] OpenSceneGraph-3.6.1 release candidate 2 tagged

[Daniel Emminizer, Code 5773]

Hi Robert,

I'm trying to track down a problem now with osgText.  There's a behavior change 
that we're seeing that I'm trying to narrow down.  I have not yet attempted to 
replicate in the osgtext example (but that's coming up soon).

In this application, we basically are doing a 2D plotting display.  There's a 
good bit of text.  As we change the aspect ratio of the host window however, 
the text skews abnormally and gets out of proportion.  This is with 
SCREEN_COORDS and auto-rotate-to-screen enabled.

In OSG 3.4, I sometimes see this skewing for a single frame, then it jumps into 
place on the next frame.  In 3.6 I never see that "jump" back to correct.

I originally thought this was in our own code -- we have a derived version of 
osgText::Text we're using -- but I am now pretty confident that it's in 
"vanilla" osgText (not our derived class).

Once I can get a smaller example duplicating the problem, or resolving the 
problem, I will pass along.  I'm going to work on trying to reproduce now but 
wanted to pass along the bug report. 

Thanks,

 - Dan



-Original Message-
From: osg-users [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf 
Of Robert Osfield
Sent: Wednesday, May 02, 2018 4:23 AM
To: OpenSceneGraph Users
Subject: [osg-users] OpenSceneGraph-3.6.1 release candidate 2 tagged

Hi All,

I have tagged the second 3.6.1 release candidate.

I have merged a PR that removed so un-implemented functions in
osgParticle, this technically changes the ABI for osgParticle so I've
bumped the SO version for 3.6.1-rc2.  The rest of the changes are
fixes.

   
https://github.com/openscenegraph/OpenSceneGraph/tree/OpenSceneGraph-3.6.1-rc2

I'm ready to tag 3.6.1, all need from the community is testing and
feedback on whether things are working on all the main platforms.  Let
us know of success or failures here on this thread.

Cheers,
Robert.

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

Re: [osg-users] OpenSceneGraph-3.6.1 release candidate 2 tagged

[Daniel Emminizer, Code 5773]

Sorry, please disregard -- I had a local modification.  Thought I had a 
breakthrough instead. :)
 
There's something still off in my code, but I do not currently have enough to 
point to whether it's in osgText or our derived class.  I'll post if I discover 
the issue is in osgText.

 - Dan



-Original Message-----
From: Daniel Emminizer, Code 5773 
Sent: Thursday, May 03, 2018 11:42 AM
To: OpenSceneGraph Users
Subject: RE: [osg-users] OpenSceneGraph-3.6.1 release candidate 2 tagged

Hi Robert,

I'm trying to track down a problem now with osgText.  There's a behavior change 
that we're seeing that I'm trying to narrow down.  I have not yet attempted to 
replicate in the osgtext example (but that's coming up soon).

In this application, we basically are doing a 2D plotting display.  There's a 
good bit of text.  As we change the aspect ratio of the host window however, 
the text skews abnormally and gets out of proportion.  This is with 
SCREEN_COORDS and auto-rotate-to-screen enabled.

In OSG 3.4, I sometimes see this skewing for a single frame, then it jumps into 
place on the next frame.  In 3.6 I never see that "jump" back to correct.

I originally thought this was in our own code -- we have a derived version of 
osgText::Text we're using -- but I am now pretty confident that it's in 
"vanilla" osgText (not our derived class).

Once I can get a smaller example duplicating the problem, or resolving the 
problem, I will pass along.  I'm going to work on trying to reproduce now but 
wanted to pass along the bug report. 

Thanks,

 - Dan



-Original Message-
From: osg-users [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf 
Of Robert Osfield
Sent: Wednesday, May 02, 2018 4:23 AM
To: OpenSceneGraph Users
Subject: [osg-users] OpenSceneGraph-3.6.1 release candidate 2 tagged

Hi All,

I have tagged the second 3.6.1 release candidate.

I have merged a PR that removed so un-implemented functions in
osgParticle, this technically changes the ABI for osgParticle so I've
bumped the SO version for 3.6.1-rc2.  The rest of the changes are
fixes.

   
https://github.com/openscenegraph/OpenSceneGraph/tree/OpenSceneGraph-3.6.1-rc2

I'm ready to tag 3.6.1, all need from the community is testing and
feedback on whether things are working on all the main platforms.  Let
us know of success or failures here on this thread.

Cheers,
Robert.

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

Re: [osg-users] OpenSceneGraph-3.6.1 release candidate 2 tagged

[Daniel Emminizer, Code 5773]

Hi Robert,

Responding this time with a reproducible example.  Attached is a minimal 
osgtext.cpp that attempts to demonstrate a problem with text scaling.

There is 1 osgText::Text in screen coordinates.  I would expect the text to be 
the same size regardless of window dimensions.  For most larger and square-ish 
dimensions, this is mostly true.  But it breaks down with smaller window sizes.

If you run the attached "osgtext --size1" you'll see "normal" text.  "osgtext 
--size2" gives vastly different screen text size with a short window.  
Conversely, "osgtext --size3" gives a pretty similar text size with a 
tall/skinny window.

Is this intentional?

Note that the same behavior can be seen by observing the "text5" in osgtext, if 
you also make the host window resizeable (e.g. using WindowSizeHandler and 
hitting 'f' key)


I've tried a few different options to get a consistent size across the three 
window sizes (normal, skinny, short) to no avail.

Thanks for your help.

 - Dan



-Original Message-
From: osg-users [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf 
Of Robert Osfield
Sent: Wednesday, May 02, 2018 4:23 AM
To: OpenSceneGraph Users
Subject: [osg-users] OpenSceneGraph-3.6.1 release candidate 2 tagged

Hi All,

I have tagged the second 3.6.1 release candidate.

I have merged a PR that removed so un-implemented functions in
osgParticle, this technically changes the ABI for osgParticle so I've
bumped the SO version for 3.6.1-rc2.  The rest of the changes are
fixes.

   
https://github.com/openscenegraph/OpenSceneGraph/tree/OpenSceneGraph-3.6.1-rc2

I'm ready to tag 3.6.1, all need from the community is testing and
feedback on whether things are working on all the main platforms.  Let
us know of success or failures here on this thread.

Cheers,
Robert.


/* OpenSceneGraph example, osgtext.
*
*  Permission is hereby granted, free of charge, to any person obtaining a copy
*  of this software and associated documentation files (the "Software"), to deal
*  in the Software without restriction, including without limitation the rights
*  to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
*  copies of the Software, and to permit persons to whom the Software is
*  furnished to do so, subject to the following conditions:
*
*  THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
*  IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
*  FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
*  AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
*  LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
*  OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
*  THE SOFTWARE.
*/

#include 

#include 
#include 
#include 
#include 

#include 
#include 

#include 
#include 


// create text which sits in 3D space such as would be inserted into a normal 
model
osg::Group* create3DText(const osg::Vec3& center)
{
osg::Geode* geode  = new osg::Geode;

osgText::Text* text5 = new osgText::Text;
text5->setFont("fonts/times.ttf");
text5->setCharacterSize(32.0f); // medium
text5->setPosition(center - osg::Vec3(0.0, 0.0, 0.2));
text5->setAxisAlignment(osgText::Text::SCREEN);
text5->setCharacterSizeMode(osgText::Text::SCREEN_COORDS);
text5->setDrawMode(osgText::Text::TEXT | osgText::Text::BOUNDINGBOX);
text5->setText("Resize skinny vs tall and see font size difference");
geode->addDrawable(text5);

osg::Group* rootNode = new osg::Group;
rootNode->addChild(geode);

return rootNode;
}

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

// construct the viewer.
osgViewer::Viewer viewer(arguments);
viewer.setUpViewInWindow(100, 100, 800, 600);

// prepare scene.
osg::Vec3 center(0.0f, 0.0f, 0.0f);

// make sure the root node is group so we can add extra nodes to it.
osg::Group* group = new osg::Group;
group->addChild(create3DText(center));

// set the scene to render
viewer.setSceneData(group);

viewer.addEventHandler(new 
osgGA::StateSetManipulator(viewer.getCamera()->getOrCreateStateSet()));
viewer.addEventHandler(new osgViewer::StatsHandler());
viewer.addEventHandler(new osgViewer::WindowSizeHandler());

int width = 800;
int height = 600;
if (arguments.read("--size1"))
  ; // noop
else if (arguments.read("--size2"))
  height = 100;
else if (arguments.read("--size3"))
  width = 100;
viewer.setUpViewInWindow(100, 100, width, height);

viewer.run();

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

Re: [osg-users] OpenSceneGraph-3.6.1 release candidate 2 tagged

[Daniel Emminizer, Code 5773]

Hi Robert,

Thanks for the update.  I rebuilt today and retried.  It does fix the problem 
in the test app I sent.  It also fixed scaling problems in one of our primary 
applications.  But it does not fix the problem in my other full-scale 
application.  But two out of three apps isn't bad!

I will try to remodel parts of that application in osgtext again on Monday to 
see if I can reproduce the bad behavior.  I'm guessing it's due to something 
strange we're doing with the projection matrix that is unexpected.

Thanks for the support.  I will let you know on Monday if I can get a 
reproducible example or not.

 - Dan



-Original Message-
From: osg-users [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf 
Of Robert Osfield
Sent: Saturday, May 05, 2018 10:51 AM
To: OpenSceneGraph Users
Subject: Re: [osg-users] OpenSceneGraph-3.6.1 release candidate 2 tagged

Hi Dan,

Thanks for the test program.  I was able to reproduce the odd scaling
behaviour and have redone the scaling code so it now ties the scale to
the vertical axis and now handles the resizes consistently.  I have
checked the fix in the OpenSceneGraph-3.6 branch and master.

Could you test it out on your application and let me know how you get
on.  If this goes OK then I'll tag 3.6.1-rc3

Robert.


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

Re: [osg-users] OpenSceneGraph-3.6.1 release candidate 3 tagged

[Daniel Emminizer, Code 5773]

Hi Robert,

Attached is an osgtext.cpp that demonstrates the problem I'm seeing in our 
application with text in SCREEN_COORDS scaling improperly.

In this particular app, we're using a FIXED projection matrix mapping (-1,-1) 
to the lower-left corner, and (+1,+1) to the upper-right corner (ortho 2D).  We 
have a layout system in this application that uses matrix transforms to 
position items in the layout.

In this section, the text is nested in two matrix transforms.  These transforms 
update values as a result of window resizes.  I omitted this code because it 
did not seem particularly relevant, and it is not required to reproduce the 
behavior.  I got the current values for both matrices by saving the scene to an 
.osg file and extracting the subgraph.

What you're seeing in this app is 4 text labels that form the text part of a 2D 
"compass", serving as a set of labels for a plot's X-axis.  Obviously this is 
just a subset of the whole scene.


When you resize the window with 3.6.1-rc2, you'll notice that the text skews 
significantly.  If you run the same app in OSG 3.4.1, the text looks correct 
regardless of window size.

Side discovery -- setting the backdrop had a weird impact on text placement.  
Not entirely sure that I understand why.  It doesn't really impact us in our 
application, but I thought I'd mention it just in case it's important.

 - Dan

/* OpenSceneGraph example, osgtext.
*
*  Permission is hereby granted, free of charge, to any person obtaining a copy
*  of this software and associated documentation files (the "Software"), to deal
*  in the Software without restriction, including without limitation the rights
*  to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
*  copies of the Software, and to permit persons to whom the Software is
*  furnished to do so, subject to the following conditions:
*
*  THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
*  IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
*  FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
*  AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
*  LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
*  OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
*  THE SOFTWARE.
*/

#include 

#include 
#include 
#include 
#include 

#include 
#include 

#include 
#include 

osgText::Text* createText(const std::string& textString, float xPosition)
{
  osgText::Text* returnValue = new osgText::Text;
  returnValue->setDataVariance(osg::Object::DYNAMIC);
  returnValue->setFont("fonts/times.ttf");
  returnValue->setCharacterSize(32.f);
  returnValue->setCharacterSizeMode(osgText::Text::SCREEN_COORDS);
  returnValue->setPosition(osg::Vec3(xPosition, -0.05, 0.0));
  returnValue->setAlignment(osgText::TextBase::CENTER_CENTER);
  returnValue->setAutoRotateToScreen(true);
  returnValue->setText(textString);

  // Note that adding a drop shadow makes text's alignment pretty far off.  
This does
  // not seem to have a huge negative impact in my app, but was noticed during 
the copy
  // over to this demo.  Probably just an artifact of only having text in the 
scene?
  //returnValue->setBackdropType(osgText::Text::DROP_SHADOW_BOTTOM_RIGHT);
  return returnValue;
}

// create text which sits in 3D space such as would be inserted into a normal 
model
osg::Group* create3DText()
{
osg::MatrixTransform* topXform = new osg::MatrixTransform;
topXform->setName("Top Level Transform");
// Real application adjusts this matrix on the fly as window resizes
topXform->setMatrix(osg::Matrix(
0.854637, 0, 0, 0,
0, 1, 0, 0,
0, 0, 1, 0,
0.125313, 0, 0, 1
));

// In real app, there are nodes between these two transforms

osg::MatrixTransform* xformLayoutItem = new osg::MatrixTransform;
xformLayoutItem->setName("VerticalLayout LayoutItem");
// Real application adjusts this matrix on the fly as window resizes
xformLayoutItem->setMatrix(osg::Matrix(
1, 0, 0, 0,
0, 0.920716, 0, 0,
0, 0, 1, 0,
0, 0.774936, 0, 1
));

osgText::Text* text330 = createText("330", -0.17);
osgText::Text* text000 = createText("000", 0.0);
osgText::Text* text030 = createText("030", 0.17);
osgText::Text* text060 = createText("060", 0.34);

topXform->addChild(xformLayoutItem);
xformLayoutItem->addChild(text330);
xformLayoutItem->addChild(text000);
xformLayoutItem->addChild(text030);
xformLayoutItem->addChild(text060);

return topXform;
}

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

// construct the viewer.
osgViewer::Viewer viewer(arguments);

// make sure the root node is group so we can add extra nodes to it.
osg::Group* group = new osg::Group;
group->addChild(create3DText());

// set the scene to render
v

Re: [osg-users] OpenSceneGraph-3.6.1 release candidate 3 tagged

[Daniel Emminizer, Code 5773]

Hi Robert,

Thanks for trying the example.  I'm perplexed why it's OK for you but not me.  
In case you're curious, I'm attaching the screenshots of the output.

I should note again that I am running with OPENGL_PROFILE="GLCORE" / GL3 mode.  
Would that make a difference?


I will rebuild on Linux and test there; I have not done that yet.  This doesn't 
seem like the kind of thing that would matter Windows vs Linux, but who knows.  
I will update this thread once I can check Linux.

- Dan


-Original Message-
From: osg-users [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf 
Of Robert Osfield
Sent: Thursday, May 10, 2018 11:32 AM
To: OpenSceneGraph Users
Subject: Re: [osg-users] OpenSceneGraph-3.6.1 release candidate 3 tagged

Hi Dan,

I finally had a chance to look at the your example.  It works the same
under 3.6 branch and 3.4 branch for me, I don't ever see any issues
with the texture become skewed regardless of the size of the window.

Robert.

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

Re: [osg-users] OpenSceneGraph-3.6.1 release candidate 3 tagged

[Daniel Emminizer, Code 5773]

Hi Robert,

I got my build on Linux done.  I test both GLCORE configuration and non-GLCORE 
configuration on OpenSceneGraph-3.6.

I am seeing the error in all 3 configurations:

1) Linux Ubuntu 14.04; default OSG 3.6 branch build (GL compatibility mode); 
NVidia Quadro K1000M GL 4.5, 384.11 driver; Ubuntu 14.04

2) Linux Ubuntu 14.04; GLCORE OSG 3.6 branch build; NVidia Quadro K1000M GL 
3.3, 384.11 driver

3) Windows 10; GLCORE OSG 3.6 branch build; NVidia NVS 510, 388.19 driver


Can you just please reconfirm that when you run on OSG 3.6 branch build, and 
run "./osgtext --size2" (or resize the view to be short), that the text is all 
readable and you can clearly see "330  000  030  060" in the display with no 
significant overlap?

Thanks,

 - Dan


-Original Message-
From: Daniel Emminizer, Code 5773 
Sent: Thursday, May 10, 2018 11:42 AM
To: 'OpenSceneGraph Users'
Subject: RE: [osg-users] OpenSceneGraph-3.6.1 release candidate 3 tagged

Hi Robert,

Thanks for trying the example.  I'm perplexed why it's OK for you but not me.  
In case you're curious, I'm attaching the screenshots of the output.

I should note again that I am running with OPENGL_PROFILE="GLCORE" / GL3 mode.  
Would that make a difference?


I will rebuild on Linux and test there; I have not done that yet.  This doesn't 
seem like the kind of thing that would matter Windows vs Linux, but who knows.  
I will update this thread once I can check Linux.

- Dan


-Original Message-
From: osg-users [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf 
Of Robert Osfield
Sent: Thursday, May 10, 2018 11:32 AM
To: OpenSceneGraph Users
Subject: Re: [osg-users] OpenSceneGraph-3.6.1 release candidate 3 tagged

Hi Dan,

I finally had a chance to look at the your example.  It works the same under 
3.6 branch and 3.4 branch for me, I don't ever see any issues with the texture 
become skewed regardless of the size of the window.

Robert.

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

Re: [osg-users] Setting OpenGL and graphics card settings prgrammatically?

[Daniel Emminizer, Code 5773]

Hi Chris,

Not sure if this is what you’re looking for, but you can give a hint to the 
drivers by exporting variables in your code.  In my main.cpp I do something 
like:

#ifdef WIN32
extern "C" {

  /// Declare this variable in public to enable the NVidia side of Optimus - 
http://developer.download.nvidia.com/devzone/devcenter/gamegraphics/files/OptimusRenderingPolicies.pdf
  __declspec(dllexport) int NvOptimusEnablement = 1;

  /// Declare this variable in public to enable the AMD side of AMD Switchable 
Graphics (13.35 driver or newer needed) - http://devgurus.amd.com/thread/169965
  __declspec(dllexport) int AmdPowerXpressRequestHighPerformance = 1;

}
#endif /* WIN32 */


We have not had a problem since.

 - Dan



From: osg-users [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf 
Of Chris Hanson
Sent: Thursday, May 10, 2018 2:15 PM
To: OpenSceneGraph Users
Subject: [osg-users] Setting OpenGL and graphics card settings prgrammatically?

  As you are aware, drivers like the NVidia Windows driver have a variety of 
tuneable settings accessible through the vendor-specific setting application. 
Many times these accomplish things that can't be accessed through the standard 
OpenGL APIs or extensions.

  Is there any way to force settings (like use of dedicated GPU versus 
integrated GPU) from application code via an API?

  Basically, we're trying to avoid having to teach the untrained user how to 
mess with those settings when we know the preferred settings for the 
application.

  Interested in NVidia and optionally AMD, Windows primarily but cross-platform 
APIs are welcomed.

  I'm digging into this: 
https://docs.nvidia.com/gameworks/index.html#gameworkslibrary/coresdk/gsa_api.htm

  to see if it does what I want, but welcome input from others.



-- 
Chris 'Xenon' Hanson, omo sanza lettere. xe...@alphapixel.com 
http://www.alphapixel.com/
Training • Consulting • Contracting
3D • Scene Graphs (Open Scene Graph/OSG) • OpenGL 2 • OpenGL 3 • OpenGL 4 • 
GLSL • OpenGL ES 1 • OpenGL ES 2 • OpenCL
Legal/IP • Forensics • Imaging • UAVs • GIS • GPS • osgEarth • Terrain • 
Telemetry • Cryptography • LIDAR • Embedded • Mobile • iPhone/iPad/iOS • Android
@alphapixel facebook.com/alphapixel (775) 623-PIXL [7495]
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] OpenSceneGraph-3.6.1 release candidate 3 tagged

[Daniel Emminizer, Code 5773]

Hi Robert,

Tested out on my apps and everything regarding window resizing and text size is 
completely fixed now.  Thanks a lot.

I spent several hours yesterday going over the code and trying to understand 
the transforms and shortcuts that were being taken.  I was not able to come up 
with anything concrete.  Looking at the new version, the code is a lot easier 
to understand. I had gotten to a point where I had understood most everything 
that was going on in the old version, but I still could not spy the problem.

You've got top notch support and I appreciate your time on this and all the 
other text issues in the last month.  I'll be testing the RC next week but 
looking good so far.

 - Dan



  Dan Emminizer
  Code 5773.40
  Naval Research Laboratory
  https://simdis.nrl.navy.mil



> -Original Message-
> From: osg-users [mailto:osg-users-boun...@lists.openscenegraph.org] On
> Behalf Of Robert Osfield
> Sent: Saturday, May 12, 2018 6:50 AM
> To: OpenSceneGraph Users
> Subject: Re: [osg-users] OpenSceneGraph-3.6.1 release candidate 3 tagged
> 
> Hi Dan,
> 
> I have had another look at this bug and using your text example I do
> see some odd behaviour so I've rewritten TextBase::computeMatrix() so
> use higher level matrix maths that is easier to understand than the
> "fast" maths version that unrolled all the the matrix ops but was very
> hard to follow.  Hard to follow -> Hard to debug...
> 
> The new version of the scale maths now works better on your two text
> test programs, and osgtext looks to behaving itself too.
> 
> 
> https://github.com/openscenegraph/OpenSceneGraph/commit/362e355db
> 28582c839c88ddd6ede1d1ae1d74237
> 
> Now that this is fixed I will create another 3.6.1-rc, hopefully this
> next one will be the last and we can finally get 3.6.1 out the door.
> 
> Robert.
> 

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

[osg-users] Text Bounding Box Calculation

[Daniel Emminizer, Code 5773]

Hi Robert,

I hope you're not sick of hearing from me yet.  I have uncovered a difference 
of behavior between 3.4 and 3.6 in osgText::Text's bounding box calculation.  
The attached program attempts to demonstrate the difference.

In one place in our application, we are trying to determine the width of a text 
string in model coordinates.  This works well using getBoundingBox().  The 
problem we are seeing is if we change the text string, then call 
getBoundingBox() before drawImplementation() has a chance to run, the bounding 
box is vastly different than expected.  I believe this is because 
computePositions() passes in 0 for the osg::State to computeMatrix().

Because of this, it's unclear when we call getBoundingBox if we're getting 
model coordinates or screen coordinates. (sorry, I'm not sure if that's the 
correct terminology)


In OSG 3.4, if you run the attached program, you'll get the same value printout 
before and after change.  In OSG 3.6, you get a value that is vastly larger 
after.  You can see the relevant code in TextWidthPrinter::handle(), and on the 
console by pressing 't' at runtime.


This is not a blocker for us because we have access to the osg::State in our 
code and can multiply against the correct matrix to value we need.  We can #if 
OSG_VERSION_GREATER_THAN our code.  But this change looks unintentional, so I 
wanted to pass along this test program that demonstrates the issue.

I hope this is helpful.

 - Dan

/* OpenSceneGraph example, osgtext.
*
*  Permission is hereby granted, free of charge, to any person obtaining a copy
*  of this software and associated documentation files (the "Software"), to deal
*  in the Software without restriction, including without limitation the rights
*  to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
*  copies of the Software, and to permit persons to whom the Software is
*  furnished to do so, subject to the following conditions:
*
*  THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
*  IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
*  FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
*  AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
*  LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
*  OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
*  THE SOFTWARE.
*/

#include 
#include 

#include 
#include 
#include 
#include 

#include 
#include 

#include 
#include 

osgText::Text* createText(const std::string& textString, float xPosition)
{
osgText::Text* returnValue = new osgText::Text;
returnValue->setDataVariance(osg::Object::DYNAMIC);
returnValue->setFont("fonts/times.ttf");
returnValue->setCharacterSize(32.f);
returnValue->setCharacterSizeMode(osgText::Text::SCREEN_COORDS);
returnValue->setPosition(osg::Vec3(xPosition, -0.05, 0.0));
returnValue->setAlignment(osgText::TextBase::CENTER_CENTER);
returnValue->setAutoRotateToScreen(true);
returnValue->setText(textString);

// Note that adding a drop shadow makes text's alignment pretty far off.  
This does
// not seem to have a huge negative impact in my app, but was noticed 
during the copy
// over to this demo.  Probably just an artifact of only having text in the 
scene?
//returnValue->setBackdropType(osgText::Text::DROP_SHADOW_BOTTOM_RIGHT);
return returnValue;
}

class TextWidthPrinter : public osgGA::GUIEventHandler
{
public:
TextWidthPrinter(osgText::Text* text)
  : text_(text)
{
}

virtual bool handle(const osgGA::GUIEventAdapter& ea, 
osgGA::GUIActionAdapter& aa)
{
  if (ea.getEventType() == ea.KEYDOWN && ea.getKey() == 't')
  {
// Matrix has -1 as left side as window, +1 as right side of window.  
So one
// would expect that this would be approximately 0.44 (~1/4 of screen)
std::cout << "Text width before setText(): " << getTextWidth() << "\n";

// Change the text string, then change it back to old text
const osgText::String oldText = text_->getText();
text_->setText("Anything else");
text_->setText(oldText);

// Demonstrate that the bounding box units are drastically different.  
This appears
// to be the actual on-screen text width, not in the model coordinates.
std::cout << "Text width after setText(): " << getTextWidth() << "\n";
return true;
  }
  return false;
}

/** Returns the bounding box's size in X coordinates */
float getTextWidth() const
{
  const osg::BoundingBox bb = text_->getBoundingBox();
  return bb.xMax() - bb.xMin();
}

private:
osgText::Text* text_;
};

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

// construct the viewer.
osgViewer::Viewer viewer(arguments);

// make sure the root node is group so we can add extra nodes to it.
  

Re: [osg-users] Text Bounding Box Calculation

[Daniel Emminizer, Code 5773]

Hi Robert,

No problem.  I thought that might be the answer, but I figured it was worth 
passing along the example just in case.

Thanks for the fast response.

 - Dan


> -Original Message-
> From: osg-users [mailto:osg-users-boun...@lists.openscenegraph.org] On
> Behalf Of Robert Osfield
> Sent: Monday, May 14, 2018 11:18 AM
> To: OpenSceneGraph Users
> Subject: Re: [osg-users] Text Bounding Box Calculation
> 
> Hi Dan,
> 
> I haven't looked at the example code, currently don't have the time
> available for this right away, but will give a quick reply on the
> general topic.  With 3.6 osgText computes the view dependent matrices
> in a way that supports usage with multiple views, whereas 3.4 doesn't
> handle it well at all and can end up with wrong results going to the
> wrong views.  For view dependent text where the actual bounding box
> varies you are bit stuck on what value to use, so you have to cache
> the last valid matrix available.  This change can lead to differences
> between versions, but the actual bounding box isn't really determinate
> so I don't think there is one "correct" answer what can/should be be
> done here.
> 
> Robert.
> 

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

Re: [osg-users] Please test OpenSceneGraph-3.6

[Daniel Emminizer, Code 5773]

Hi Robert,

Getting a Windows build error on osgQt from the change on 
REGISTER_WINDOWINGSYSTEMINTERFACE() macro from last week.  Are you the right 
person to report the problem to?

osgQt's GraphicsWindowQt.cpp includes the line:

  #if 1
  REGISTER_WINDOWINGSYSTEMINTERFACE(Qt, QtWindowingSystem)
  ...

With the change to the macro, it expands to:
  extern "C" OSGVIEWER_EXPORT void graphicswindow_qt(void) {} 

where OSGVIEWER_EXPORT is defined as "__declspec(dllimport)" (because we're now 
in osgQt and not osgViewer)


One possible fix is to add a parameter to REGISTER_WINDOWINGSYSTEMINTERFACE to 
specify the export flavor, such as:

  #define REGISTER_WINDOWINGSYSTEMINTERFACE(export_type, ext, classname) \
extern "C export_type void ...

  REGISTER_WINDOWINGSYSTEMINTERFACE(OSGQT_EXPORT, Qt, QtWindowingSystem)

Of course the down-side is that it would change the interface to the macro; but 
that seems better than the alternative of breaking on Windows.  I'm happy to 
test if you need.

 - Dan


> -Original Message-
> From: osg-users [mailto:osg-users-boun...@lists.openscenegraph.org] On
> Behalf Of Robert Osfield
> Sent: Friday, May 18, 2018 10:49 AM
> To: OpenSceneGraph Users
> Subject: [osg-users] Please test OpenSceneGraph-3.6
> 
> Hi All,
> 
> I have checked in a few fixes today, one of them I'm not confident
> that it'll work across all platforms so I won't make 3.6.1-rc5 today,
> instead I'll wait for feedback from the community.
> 
> As usual please let us know via this thread about success or failures.
> 
> Thanks for the testing,
> Robert.
> 

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

Re: [osg-users] Please test OpenSceneGraph-3.6

[Daniel Emminizer, Code 5773]

Hi Robert,

Seems like a reasonable approach.  I'll rebuild on my side when you think you 
have something good.

 - Dan



> -Original Message-
> From: osg-users [mailto:osg-users-boun...@lists.openscenegraph.org] On
> Behalf Of Robert Osfield
> Sent: Monday, May 21, 2018 7:27 AM
> To: OpenSceneGraph Users
> Subject: Re: [osg-users] Please test OpenSceneGraph-3.6
> 
> Hi Dan,
> 
> 
> Two steps forward, one step back
> 
> For compatibility between various versions of the OSG and osgQt I am
> inclined to change the REGISTER_WINDOWINGSYSTEMINTERFACE
> implementation back to what it was and either introduce a new macro
> that adds the OSGVIEWER_EXPORT or  just have the
> GraphicsWindowWin32.cpp not use the this help marco at all, and just
> have it declare the extern and proxy objects directly in the code.
> 
> 
> Robert.
> 
> 
> On 21 May 2018 at 11:48, Daniel Emminizer, Code 5773
>  wrote:
> > Hi Robert,
> >
> > Getting a Windows build error on osgQt from the change on
> REGISTER_WINDOWINGSYSTEMINTERFACE() macro from last week.  Are you
> the right person to report the problem to?
> >
> > osgQt's GraphicsWindowQt.cpp includes the line:
> >
> >   #if 1
> >   REGISTER_WINDOWINGSYSTEMINTERFACE(Qt, QtWindowingSystem)
> >   ...
> >
> > With the change to the macro, it expands to:
> >   extern "C" OSGVIEWER_EXPORT void graphicswindow_qt(void) {} 
> >
> > where OSGVIEWER_EXPORT is defined as "__declspec(dllimport)"
> (because we're now in osgQt and not osgViewer)
> >
> >
> > One possible fix is to add a parameter to
> REGISTER_WINDOWINGSYSTEMINTERFACE to specify the export flavor, such
> as:
> >
> >   #define REGISTER_WINDOWINGSYSTEMINTERFACE(export_type, ext,
> classname) \
> > extern "C export_type void ...
> >
> >   REGISTER_WINDOWINGSYSTEMINTERFACE(OSGQT_EXPORT, Qt,
> QtWindowingSystem)
> >
> > Of course the down-side is that it would change the interface to the macro;
> but that seems better than the alternative of breaking on Windows.  I'm
> happy to test if you need.
> >
> >  - Dan
> >
> >
> >> -Original Message-
> >> From: osg-users [mailto:osg-users-boun...@lists.openscenegraph.org]
> On
> >> Behalf Of Robert Osfield
> >> Sent: Friday, May 18, 2018 10:49 AM
> >> To: OpenSceneGraph Users
> >> Subject: [osg-users] Please test OpenSceneGraph-3.6
> >>
> >> Hi All,
> >>
> >> I have checked in a few fixes today, one of them I'm not confident
> >> that it'll work across all platforms so I won't make 3.6.1-rc5 today,
> >> instead I'll wait for feedback from the community.
> >>
> >> As usual please let us know via this thread about success or failures.
> >>
> >> Thanks for the testing,
> >> 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
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Please test OpenSceneGraph-3.6

[Daniel Emminizer, Code 5773]

Hi Robert,

Looks good from my end for compiling on MSVC 2015.  Compiles and links without 
problem, same with osgQt.

 - Dan


> -Original Message-
> From: osg-users [mailto:osg-users-boun...@lists.openscenegraph.org] On
> Behalf Of Robert Osfield
> Sent: Monday, May 21, 2018 8:15 AM
> To: OpenSceneGraph Users
> Subject: Re: [osg-users] Please test OpenSceneGraph-3.6
> 
> Hi Dan,
> 
> On 21 May 2018 at 12:42, Daniel Emminizer, Code 5773
>  wrote:
> > Seems like a reasonable approach.  I'll rebuild on my side when you think
> you have something good.
> 
> I have checked in locally expanded version of the macro for
> GraphicsWindowWin32.cpp, and restored the macro to it's original
> location in the include/osg/GraphicsContext header:
> 
> 
> https://github.com/openscenegraph/OpenSceneGraph/commit/dce6684c59
> 698664771669ab7e21fbe4e26e5f42
> 
> I haven't tested under Windows thought so feedback would be very
> welcome.
> 
> 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] OpenSceneGraph-3.6.1 release candidate 5 is tagged

[Daniel Emminizer, Code 5773]

Hi Robert,

I'm using the latest OpenSceneGraph-3.6 with the scaling changes that just got 
pushed out.

I'm getting a bad scaling on a label that is rotated that used to work in OSG 
3.4, and used to work prior to 
https://github.com/openscenegraph/OpenSceneGraph/commit/76d1b85

Note that 76d1b85 DOES help with the osgEarth bug -- we're also using osgEarth 
and that makes the earth graticules a lot better.  But it's breaking this 
rotated text case.

Attached is a screenshot of the display on current OpenSceneGraph-3.6 
(BadScaleRotated.png).  I backed out 76d1b85 and re-ran and got 
BackedOut76d1b85.png, which looks correct.

I'm working on a minimal reproducible example now.  Once I get it I will 
respond to this email with a .cpp file.  Thanks,

 - Dan



> -Original Message-
> From: osg-users [mailto:osg-users-boun...@lists.openscenegraph.org] On
> Behalf Of Robert Osfield
> Sent: Sunday, May 20, 2018 8:48 AM
> To: OpenSceneGraph Users
> Subject: [osg-users] OpenSceneGraph-3.6.1 release candidate 5 is tagged
> 
> Hi All,
> 
> I have fixed an issue with text SCREEN_COORDS scaling so this means
> all the issues I'm aware of are now resolved.  To wrap this up I've
> tagged 3.6.1-rc5.
> 
> 
> https://github.com/openscenegraph/OpenSceneGraph/tree/OpenSceneGr
> aph-3.6.1-rc5
> 
> As before please test build or the platforms you have available and
> against your own applications. If you have success or issues please
> report them here so we get a feel of whether things have converged now
> and we are ready of tagging 3.6.1 itself.
> 
> Cheers,
> Robert.
> 

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

Re: [osg-users] OpenSceneGraph-3.6.1 release candidate 5 is tagged

[Daniel Emminizer, Code 5773]

Hi Robert,

Attached is an example based off the osgtext example, along with a screenshot 
of what I see when I run it.  Making the window taller will "fix" the scaling.

This is very similar to one of the issues reported a few weeks back; except 
this is only affecting rotated text.  I've found that this problem seems to 
occur most when a projection matrix is set to ortho2d, and the aspect ratio of 
the projection matrix does not match the viewport's aspect ratio.  My ortho 
matrix is set from 0,0 to 1,1 in this application, so it's always 1:1 aspect 
ratio.  Viewport aspect ratio varies as user resizes the window; the example 
starts at 800x300 (8:3).

The screenshot is against OpenSceneGraph-3.6, most recent push.

 - Dan


> -Original Message-----
> From: Daniel Emminizer, Code 5773
> Sent: Monday, May 21, 2018 11:09 AM
> To: OpenSceneGraph Users
> Subject: RE: [osg-users] OpenSceneGraph-3.6.1 release candidate 5 is tagged
> 
> Hi Robert,
> 
> I'm using the latest OpenSceneGraph-3.6 with the scaling changes that just
> got pushed out.
> 
> I'm getting a bad scaling on a label that is rotated that used to work in OSG
> 3.4, and used to work prior to
> https://github.com/openscenegraph/OpenSceneGraph/commit/76d1b85
> 
> Note that 76d1b85 DOES help with the osgEarth bug -- we're also using
> osgEarth and that makes the earth graticules a lot better.  But it's breaking
> this rotated text case.
> 
> Attached is a screenshot of the display on current OpenSceneGraph-3.6
> (BadScaleRotated.png).  I backed out 76d1b85 and re-ran and got
> BackedOut76d1b85.png, which looks correct.
> 
> I'm working on a minimal reproducible example now.  Once I get it I will
> respond to this email with a .cpp file.  Thanks,
> 
>  - Dan
> 
> 
> 
> > -Original Message-
> > From: osg-users [mailto:osg-users-boun...@lists.openscenegraph.org] On
> > Behalf Of Robert Osfield
> > Sent: Sunday, May 20, 2018 8:48 AM
> > To: OpenSceneGraph Users
> > Subject: [osg-users] OpenSceneGraph-3.6.1 release candidate 5 is
> > tagged
> >
> > Hi All,
> >
> > I have fixed an issue with text SCREEN_COORDS scaling so this means
> > all the issues I'm aware of are now resolved.  To wrap this up I've
> > tagged 3.6.1-rc5.
> >
> >
> >
> https://github.com/openscenegraph/OpenSceneGraph/tree/OpenSceneGr
> > aph-3.6.1-rc5
> >
> > As before please test build or the platforms you have available and
> > against your own applications. If you have success or issues please
> > report them here so we get a feel of whether things have converged now
> > and we are ready of tagging 3.6.1 itself.
> >
> > Cheers,
> > Robert.
> >

/* OpenSceneGraph example, osgtext.
*
*  Permission is hereby granted, free of charge, to any person obtaining a copy
*  of this software and associated documentation files (the "Software"), to deal
*  in the Software without restriction, including without limitation the rights
*  to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
*  copies of the Software, and to permit persons to whom the Software is
*  furnished to do so, subject to the following conditions:
*
*  THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
*  IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
*  FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
*  AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
*  LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
*  OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
*  THE SOFTWARE.
*/

#include 
#include 
#include 

#include 
#include 

#include 
#include 

osg::Group* createHUDText()
{
osg::Group* rootNode = new osg::Group;

osg::ref_ptr font = 
osgText::readRefFontFile("fonts/arial.ttf");
osg::Geode* geode  = new osg::Geode;
rootNode->addChild(geode);

osg::Vec4 layoutColor(1.0f,1.0f,0.0f,1.0f);
float layoutCharacterSize = 24.0f;

{
osgText::Text* text = new osgText::Text;
text->setFont(font);
text->setColor(layoutColor);
text->setCharacterSize(layoutCharacterSize);
text->setCharacterSizeMode(osgText::TextBase::SCREEN_COORDS);
text->setAxisAlignment(osgText::TextBase::SCREEN);
text->setPosition(osg::Vec3(0.125,0.1,0.0f));

text->setText("Horizontal Text");
geode->addDrawable(text);
}

{
osgText::Text* text = new osgText::Text;
text->setFont(font);
text->setColor(layoutColor);
text->setCharacterSize(layoutCharacterSize);
text-&g

Re: [osg-users] OpenSceneGraph-3.6.1 release candidate 5 is tagged

[Daniel Emminizer, Code 5773]

Hi Robert,

Looks good on my side.  I ran it through all of my applications and I do not 
spy any regressions from this change.  Phew!

Thanks for the support.  I'm actually getting pretty excited about the Text now 
with our update to OSG 3.6.


If it's helpful -- I am also seeing the problem with precision that Glenn 
reported a few minutes ago with PR #548.  I can also vouch that his PR fixes 
the problem, and does not introduce any other issues in my applications.

 - Dan


> -Original Message-
> From: osg-users [mailto:osg-users-boun...@lists.openscenegraph.org] On
> Behalf Of Robert Osfield
> Sent: Monday, May 21, 2018 1:16 PM
> To: OpenSceneGraph Users
> Subject: Re: [osg-users] OpenSceneGraph-3.6.1 release candidate 5 is tagged
> 
> Hi Dan,
> 
> I have checked in a fix to the OpenSceneGraph-3.6 branch:
> 
> 
> https://github.com/openscenegraph/OpenSceneGraph/commit/eae5f9b958
> 59e0dd4f6c580bfc9b6f5efc623aed
> 
> Fingers crossed this doesn't introduce any new regressions...
> 
> Robert.

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

Re: [osg-users] OpenSceneGraph-3.6.1 release candidate 5 is tagged

[Daniel Emminizer, Code 5773]

Robert, Glenn,

I am seeing this problem too in a different application than Glenn.

I have not yet reported it yet because I've moved forward to upgrading another 
part of my application, and only then started to see the problem.  I figured it 
was something on my own end and haven't investigated yet.

 - Dan



From: osg-users [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf 
Of Glenn Waldron
Sent: Tuesday, May 22, 2018 11:42 AM
To: osg-users@lists.openscenegraph.org
Subject: Re: [osg-users] OpenSceneGraph-3.6.1 release candidate 5 is tagged

Robert,
I am getting a message repeated on the console (OpenSceneGraph-3.6 branch).
Verbosity level, or user error?

Warning:createOrReuseRenderLeaf() skipping multiply referenced entry.


Glenn Waldron


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

Re: [osg-users] OpenSceneGraph-3.6.1 release candidate 5 is tagged

[Daniel Emminizer, Code 5773]

Hi Robert,

Latest changes from you on OpenSceneGraph-3.6 branch work good for me, my error 
gone on Render Leaf printout.  All display looks good.

Thanks,

 - Dan



> -Original Message-
> From: osg-users [mailto:osg-users-boun...@lists.openscenegraph.org] On
> Behalf Of Robert Osfield
> Sent: Wednesday, May 23, 2018 9:58 AM
> To: OpenSceneGraph Users
> Subject: Re: [osg-users] OpenSceneGraph-3.6.1 release candidate 5 is tagged
> 
> On 23 May 2018 at 14:02, Robert Osfield  wrote:
> > No problem.  Thankfully I had another user help out with producing the
> > issue.  I've resolved the issue and am about to check in the changes,
> > I just need to do a code review before checking in.
> 
> I have checked in to master and OpenSceneGraph-3.6 improvements that
> resolve the "Warning:createOrReuseRenderLeaf() skipping multiply
> referenced entry." issue.
> 
> 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] Updating VBO's during runtime

[Daniel Emminizer, Code 5773]

Hi Brad,

Check to make sure your Geometry has setDataVariance(osg::Object::DYNAMIC).  
That solved the problem for most of our similar cases.

- Dan


From: osg-users [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf 
Of Brad Colbert
Sent: Friday, June 01, 2018 10:20 AM
To: osg-users@lists.openscenegraph.org
Subject: [osg-users] Updating VBO's during runtime

I'm updating my vertices at runtime.  I've found a few posts that discuss this:

(a couple are:)
http://forum.openscenegraph.org/viewtopic.php?t=14826
http://forum.openscenegraph.org/viewtopic.php?t=15782

Let me first mention that I've compiled OSG with GL3 support, so no display 
lists.  That said, I'm still calling:

  pointsGeom->setUseDisplayList(false);
  pointsGeom->setUseVertexBufferObjects(true);

Here is a snippet of my call to update the vertices (v_ = vertices, c_ = 
colors, n_ = normals, da_ = DrawArrays, g_ = Geometry):

for (int i = 0; i < numVertices; i++) {
  // Verticies
  v_.at(i)[0] = 500.f * (0.0f + (3.0f * float(rand() % 1000) / 1000.f) - 
1.5f);
  v_.at(i)[1] = 500.f * (0.0f + (4.0f * float(rand() % 1000) / 1000.f) - 
2.f);
  v_.at(i)[2] = 500.f * (1.5f + (0.1f * float(rand() % 1000) / 1000.f) - 
0.05f);

  // Colors
  c_.at(i)[0] = 1.f;
  c_.at(i)[1] = 1.f;
  c_.at(i)[2] = 1.f;
  c_.at(i)[3] = 1.f;

  // Normals
  n_.at(i)[0] = 0.f;
  n_.at(i)[1] = 1.f;
  n_.at(i)[2] = 0.f;
}

v_.dirty();
c_.dirty();
n_.dirty();

da_.setCount(numVertices);
da_.dirty();

// *** The dirty() calls above are supposed to tell OSG to update the 
VBO's.  For
// some reason this isn't happening.  We are going to force it here.  Not 
sure of the
// performance implications but hopefully this is temporary.
g_.setVertexArray(&v_);
g_.setColorArray(&c_);
g_.setNormalArray(&n_);

g_.dirtyBound();

The update just doesn't happen unless I call the setVertexArray, setColorArray, 
setNormalArray methods which doesn't match what the previous posts about this 
topic.

Is this because of GL3 or something else?

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

[osg-users] VBO Bug with 3.6.1 and Normal Arrays

[Daniel Emminizer, Code 5773]

Hi Robert,

Oops -- I sent this earlier today but apparently to the bounces list; that 
explains the confusion on GitHub -- my mistake.  This was supposedly sent right 
before I posted the PR.  Here's the original text:


I think I found a bug in 3.6.1.  I am loading a FLT model and it's causing a 
crash in my application to draw it.  The same model does not crash in OSG 3.4.  
I think I've finally tracked down the cause and have a candidate solution too.

A few weeks back I saw a similar crash in my own code, and figured it was due 
to incorrect usage of the binding flags on osg::Array.  Much of our code was 
using osg::Geometry::setNormalBinding() (and related methods).  During 
debugging, I was able to determine my normals were crashing in 3.6, and the 
problem went away when I used the osg::Array(osg::Array::Binding) signature -- 
i.e. assigning a binding on construction.  At the time I thought it was 
something I was doing wrong and moved on.

The problem showed up again earlier this week but not in my code, and not 
manifesting in exactly the same way.  Here's the run-down of what's going on:

- Loading FLT model
- FLT model loads a face, which has vertices, textures, and normals
- FLT uses getOrCreateNormalArray(), which allocates an array (BIND_UNDEFINED) 
and sets it on the geometry
- Geometry::addVertexBufferObjectIfRequired() is called on the normals, but 
nothing done due to BIND_UNDEFINED
- FLT later sets normals to BIND_PER_VERTEX appropriately, which is a direct 
set and does not do anything to the Geometry's VBOs
- First frame starts to render
- Geometry::drawVAImpl calls vas->setNormalArray()
- VertexArrayState::setArray() calls new_array->getOrCreateGLBufferObject(), 
which returns 0.  This is the first major problem.
- Because vbo is NULL, unbindindVertexBufferObject() is called, leading to 
GL_ARRAY_BUFFER to go to 0
- vad->enable_and_dispatch() gets called and does glVertexAttribPointer() with 
a non-NULL data ptr, which is a GL error because array buffer is 0

Unwinding the error:
- enable_and_dispatch() shouldn't be called if ptr is non-NULL and no 
GL_ARRAY_BUFFER is 0
- GL_ARRAY_BUFFER is set to 0 because there is no VBO set up for the normal 
array
- There is no normal array because the only place it seems to be created is in 
setNormalArray(), which fails because at that time, it is BIND_UNDEFINED
- Binding gets swapped from BIND_UNDEFINED to BIND_PER_VERTEX after 
setNormalArray(), leading to the error

There are several possible solutions I can see.  You can probably see more:
1) Change FLT plugin to assign array binding per vertex on construction of 
array.  Seems poor because invariably this bug is crashing other code -- maybe 
it's the cause of the DXF that Brian Hutchison reported earlier this week?
2) Update Array::setBinding() to create the VBO if needed.  I do not know if 
this is possible nor how to do it.
3) "Lazily" detect this issue somewhere in the rendering calls and create VBO 
there if necessary



PR 554 was an attempt at approach #3 but I agree with your assessment on 
GitHub.  It does not solve the problem in all cases.

Attached is a demo of the problem that generates a console warning.  More 
complex scenes can cause crashes.  The red triangle has the problem, but the 
green one does not.

 - Dan

cmake_minimum_required(VERSION 2.6)

SET(PROJECT_NAME arraybug)

PROJECT(${PROJECT_NAME})

FIND_PACKAGE(OpenThreads)
FIND_PACKAGE(osg)
FIND_PACKAGE(osgDB)
FIND_PACKAGE(osgUtil)
FIND_PACKAGE(osgGA)
FIND_PACKAGE(osgViewer)
FIND_PACKAGE(osgText)

SET(SOURCES
main.cpp
)

INCLUDE_DIRECTORIES(${OPENTHREADS_INCLUDE_DIR} ${OSG_INCLUDE_DIR})

LINK_DIRECTORIES(${OSG_LIB_DIR})

ADD_EXECUTABLE(${PROJECT_NAME} ${SOURCES})

TARGET_LINK_LIBRARIES(${PROJECT_NAME} ${OSG_LIBRARIES} ${OSGVIEWER_LIBRARIES} 
${OSGUTIL_LIBRARIES} ${OSGDB_LIBRARIES} ${OSGGA_LIBRARIES} ${OSGTEXT_LIBRARIES} 
${OPENTHREADS_LIBRARIES})
#include 
#include 
#include 
#include 

osg::Node* createTriangle(float x, bool earlyBinding, const osg::Vec4f& color)
{
osg::Geode* geode = new osg::Geode;
osg::Geometry* geom = new osg::Geometry;
geom->setUseVertexArrayObject(true);
geom->setUseVertexBufferObjects(true);

osg::Vec3Array* vertices = new osg::Vec3Array();
vertices->push_back(osg::Vec3(x - 100, 0, -100));
vertices->push_back(osg::Vec3(x, 0, 100));
vertices->push_back(osg::Vec3(x, 0, -100));

osg::Vec3Array* normals = new osg::Vec3Array;
normals->push_back(osg::Vec3(0, -1, 0));
normals->push_back(osg::Vec3(0, -1, 0));
normals->push_back(osg::Vec3(0, -1, 0));
if (earlyBinding)
normals->setBinding(osg::Array::BIND_PER_VERTEX);

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

geom->addPrimitiveSet(new osg::DrawArrays(GL_TRIANGLES, 0, 3));
geom->setVertexArray(vertices);
geom->setNormalArray(normals);
geom->setColorArray(colors);
geode->addDrawable(geom);

// Warning gets

Re: [osg-users] VBO Bug with 3.6.1 and Normal Arrays

[Daniel Emminizer, Code 5773]

Hi Robert,

The file you sent is identical to the one I sent.  Was that intentional?  You 
also mention Cessna; do you have the examples mixed up perhaps?

The bug will manifest if the geometry's normal array (and presumably fog, 
colors, etc) are set before the array binding type is set.  It's entirely 
possible to have correctly loaded models.  I only ran across this because the 
OpenFlight loader sets the binding late.


This bug prints on console:

Warning: detected OpenGL error 'invalid operation' at after 
drawable.compileGLObjects() call in GLObjectsVisitor::apply(osg::Drawable& 
drawable)


No change in error message with with OSG_GL_ERROR_CHECKING=on.  No change in 
error message with --ro, with --reset, or with --ro --reset.

I am building OSG 3.6.1 (and tried OpenSceneGraph-3.6) in core profile on 
Windows 10.  Video card data is:

Vendor = NVIDIA Corporation
Renderer = NVS 510/PCIe/SSE2
Version = 3.3.0 NVIDIA 388.19
GLSL Version = 330


Responses from me will be slow this week; my email access will be spotty.

Hope this helps.  Thanks,

 - Dan

 

> -Original Message-
> From: osg-users [mailto:osg-users-boun...@lists.openscenegraph.org] On
> Behalf Of Robert Osfield
> Sent: Sunday, June 03, 2018 6:11 AM
> To: OpenSceneGraph Users
> Subject: Re: [osg-users] VBO Bug with 3.6.1 and Normal Arrays
> 
> Hi Dan,
> 
> On 1 June 2018 at 16:01, Daniel Emminizer, Code 5773
>  wrote:
> > Attached is a demo of the problem that generates a console warning.
> More complex scenes can cause crashes.  The red triangle has the problem,
> but the green one does not.
> 
> I have built the example, and to help with test have changed the #ifdef
> blocks to ones that check arguments.read("--ro") for the RealizerOperation
> usage and "--reset" for the
> resetVertexAttributeAlias.   Attached is the modified file.
> 
> If you run the test with --ro and have it use the custom RealizerOperation I
> see a completely red cessna.  If I used --ro and --reset I see multi-colour
> (blue, red etc) one, if I run without any options I see the multi-colour one.
> 
> I don't see any command line warnings though.  I'm testing under Kubuntu
> with OSG-3.6 branch, my drive info is:
> 
> OpenGL vendor string: NVIDIA Corporation OpenGL renderer string: GeForce
> GTX 760/PCIe/SSE2 OpenGL core profile version string: 4.5.0 NVIDIA 384.111
> OpenGL core profile shading language version string: 4.50 NVIDIA
> 
> I don't yet have any idea what is going wrong, it's obviously very odd that 
> the
> custom RealizeOperation is having an effect when it does nothing itself.
> 
> Before I start diving deeper I'd like to know what others are seeing with
> these different combinations and if any errors are being printed in the
> console, if so what are they.  Also let us know the OSG version and driver/OS
> details.
> 
> Robert.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] VBO Bug with 3.6.1 and Normal Arrays

[Daniel Emminizer, Code 5773]

Hi Robert,

I am back from travel and looking at this again.  Didn't get a response on last 
set of questions about this crash.  Sorry to distract from the Vulkan work -- 
it sounds interesting, and I'm watching your progress there excitedly.


Core problem seems to be that Array::setBinding() can change after 
Geometry::set*Array().  Geometry::set*Array() is responsible for calling 
addVertexBufferObjectIfRequired(), and doesn't have enough information to 
correctly do so.

During the draw traversal, as a result, the Array::getBinding() flag does not 
match the VBO state in Geometry.

One solution is to create the VBO as needed (using 
addVertexBufferObjectIfRequired) sometime between the start of cull phase and 
before the Geometry::drawImplementation().  But drawImplementation() is const, 
and not a place where this can happen.


Another possible solution that might help is to modify 
Geometry::setPrimitiveSet() and addPrimitiveSet() to call 
addVertexBufferObjectIfRequired() on the various arrays.  I prototyped this 
solution locally and it resolved the issue in the FLT loader.  I know it's not 
perfect, but most places I've seen that would trigger this bug have defined an 
array binding by the time a primitive set is added.

Should I submit a PR for this approach?  It keeps binary compatibility and is 
fairly straightforward, and helps my immediate crash out of FLT and most of the 
other use cases I've encountered.

Thanks,

 - Dan



> -----Original Message-
> From: Daniel Emminizer, Code 5773
> Sent: Monday, June 04, 2018 8:45 AM
> To: OpenSceneGraph Users
> Subject: RE: [osg-users] VBO Bug with 3.6.1 and Normal Arrays
> 
> Hi Robert,
> 
> The file you sent is identical to the one I sent.  Was that intentional?  You 
> also
> mention Cessna; do you have the examples mixed up perhaps?
> 
> The bug will manifest if the geometry's normal array (and presumably fog,
> colors, etc) are set before the array binding type is set.  It's entirely 
> possible
> to have correctly loaded models.  I only ran across this because the
> OpenFlight loader sets the binding late.
> 
> 
> This bug prints on console:
> 
> Warning: detected OpenGL error 'invalid operation' at after
> drawable.compileGLObjects() call in GLObjectsVisitor::apply(osg::Drawable&
> drawable)
> 
> 
> No change in error message with with OSG_GL_ERROR_CHECKING=on.  No
> change in error message with --ro, with --reset, or with --ro --reset.
> 
> I am building OSG 3.6.1 (and tried OpenSceneGraph-3.6) in core profile on
> Windows 10.  Video card data is:
> 
> Vendor = NVIDIA Corporation
> Renderer = NVS 510/PCIe/SSE2
> Version = 3.3.0 NVIDIA 388.19
> GLSL Version = 330
> 
> 
> Responses from me will be slow this week; my email access will be spotty.
> 
> Hope this helps.  Thanks,
> 
>  - Dan
> 
> 
> 
> > -Original Message-
> > From: osg-users [mailto:osg-users-boun...@lists.openscenegraph.org] On
> > Behalf Of Robert Osfield
> > Sent: Sunday, June 03, 2018 6:11 AM
> > To: OpenSceneGraph Users
> > Subject: Re: [osg-users] VBO Bug with 3.6.1 and Normal Arrays
> >
> > Hi Dan,
> >
> > On 1 June 2018 at 16:01, Daniel Emminizer, Code 5773
> >  wrote:
> > > Attached is a demo of the problem that generates a console warning.
> > More complex scenes can cause crashes.  The red triangle has the problem,
> > but the green one does not.
> >
> > I have built the example, and to help with test have changed the #ifdef
> > blocks to ones that check arguments.read("--ro") for the RealizerOperation
> > usage and "--reset" for the
> > resetVertexAttributeAlias.   Attached is the modified file.
> >
> > If you run the test with --ro and have it use the custom RealizerOperation I
> > see a completely red cessna.  If I used --ro and --reset I see multi-colour
> > (blue, red etc) one, if I run without any options I see the multi-colour 
> > one.
> >
> > I don't see any command line warnings though.  I'm testing under Kubuntu
> > with OSG-3.6 branch, my drive info is:
> >
> > OpenGL vendor string: NVIDIA Corporation OpenGL renderer string:
> GeForce
> > GTX 760/PCIe/SSE2 OpenGL core profile version string: 4.5.0 NVIDIA
> 384.111
> > OpenGL core profile shading language version string: 4.50 NVIDIA
> >
> > I don't yet have any idea what is going wrong, it's obviously very odd that
> the
> > custom RealizeOperation is having an effect when it does nothing itself.
> >
> > Before I start diving deeper I'd like to know what others are seeing with
> > these different combinations and if any errors are being printed in the
> > console, if so what are they.  Also let us know the OSG version and
> driver/OS
> > details.
> >
> > Robert.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] VBO Bug with 3.6.1 and Normal Arrays

[Daniel Emminizer, Code 5773]

Hi Laurens,

Thanks for the response.

I’m not super familiar with the back-end of OSG.  I tried to tackle the problem 
by looking for possible insertion points for the 
addVertexBufferObjectIfRequired(), in a way that won’t break binary 
compatibility.  This attempt did fix the crash for me in the dozen files I 
attempted to load.

I debugged a bit more at your prodding.  It’s working for me because the models 
that I am loading are reusing arrays in multiple primitive sets.  As I load the 
models, each of them has thousands of calls to setBinding(), but tens of 
thousands of primitive sets, most occurring well after the setBinding() calls.  
This implies array reuse to me.


Yes, the problem can definitely be avoided by editing the FLT plugin.  However, 
this problem occurred in lots of our own user code (unrelated to FLT), and in 
osgEarth too.  My first naïve approach was to fix all locations that set up 
arrays to configure binding before setting the array.  But there are so many, 
and any missed one will cause a crash.  I’ve been months into my OSG 3.6 (and 
GL3 core profile) upgrade before encountering this bug; how many more are 
waiting?

This used to be valid usage in the sense that it used to work in 3.4, and 
presumably is still valid because setBinding() is still public, not deprecated, 
and there’s no warnings in the code to avoid this condition.  That’s part of 
the reason for my original email – if this is not a valid use case, then 
someone’s going to have to find and fix all the violations in OSG code like 
FLT.  I don’t mind taking a crack at it since it impacts me, but I’d rather fix 
the source of the problem than every symptom.

What you’ve posted below is definitely my fallback if the problem can’t be 
solved by changing osg::Array/Geometry.

- Dan



  Dan Emminizer
  Code 5773.40
  Naval Research Laboratory
  https://simdis.nrl.navy.mil<https://simdis.nrl.navy.mil/>


From: osg-users [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf 
Of Voerman, L.
Sent: Monday, June 11, 2018 10:26 AM
To: OpenSceneGraph Users
Subject: Re: [osg-users] VBO Bug with 3.6.1 and Normal Arrays

Hi Daniel,
I don't understand why your modification to addPrimitiveSet() resolves your 
issue with the openflight plugin, as it's called before the proper array 
bindings have been set (src\osgPlugins\OpenFlight\GeometryRecords.cpp line 601)
Can your problem be avoided by changing
if (geometry->getColorArray()) 
geometry->getColorArray()->setBinding(osg::Array::BIND_PER_VERTEX);
to
if (geometry->getColorArray()) geometry->setColorArray( 
geometry->getColorArray(), osg::Array::BIND_PER_VERTEX);
and
if (geometry->getNormalArray()) 
geometry->getNormalArray()->setBinding(osg::Array::BIND_PER_VERTEX);
by
if (geometry->getNormalArray()) geometry->setNormalArray( 
geometry->getNormalArray(), osg::Array::BIND_PER_VERTEX);

(both changes appear two times in  
src\osgPlugins\OpenFlight\GeometryRecords.cpp )
Regards, Laurens.

On Mon, Jun 11, 2018 at 3:37 PM, Daniel Emminizer, Code 5773 
mailto:dan.emmini...@nrl.navy.mil>> wrote:
Hi Robert,

I am back from travel and looking at this again.  Didn't get a response on last 
set of questions about this crash.  Sorry to distract from the Vulkan work -- 
it sounds interesting, and I'm watching your progress there excitedly.


Core problem seems to be that Array::setBinding() can change after 
Geometry::set*Array().  Geometry::set*Array() is responsible for calling 
addVertexBufferObjectIfRequired(), and doesn't have enough information to 
correctly do so.

During the draw traversal, as a result, the Array::getBinding() flag does not 
match the VBO state in Geometry.

One solution is to create the VBO as needed (using 
addVertexBufferObjectIfRequired) sometime between the start of cull phase and 
before the Geometry::drawImplementation().  But drawImplementation() is const, 
and not a place where this can happen.


Another possible solution that might help is to modify 
Geometry::setPrimitiveSet() and addPrimitiveSet() to call 
addVertexBufferObjectIfRequired() on the various arrays.  I prototyped this 
solution locally and it resolved the issue in the FLT loader.  I know it's not 
perfect, but most places I've seen that would trigger this bug have defined an 
array binding by the time a primitive set is added.

Should I submit a PR for this approach?  It keeps binary compatibility and is 
fairly straightforward, and helps my immediate crash out of FLT and most of the 
other use cases I've encountered.

Thanks,

 - Dan



> -Original Message-
> From: Daniel Emminizer, Code 5773
> Sent: Monday, June 04, 2018 8:45 AM
> To: OpenSceneGraph Users
> Subject: RE: [osg-users] VBO Bug with 3.6.1 and Normal Arrays
>
> Hi Robert,
>
> The file you sent is identical to the one I sent.  Was that intentional?  You 
> also
>

Re: [osg-users] VBO Bug with 3.6.1 and Normal Arrays

[Daniel Emminizer, Code 5773]

Hi Robert,

I have committed and pushed my solution at 
https://github.com/emminizer/OpenSceneGraph/commit/4d2601e05e96aa

It's on my branch 
https://github.com/emminizer/OpenSceneGraph/tree/crash-vbo-array-bindings

As Laurens pointed out earlier, it may not catch all use cases, including some 
important ones.  I'm (mildly) confident that the solution is to detect the 
change in array bindings and call addVertexBuffObjectIfRequired() -- but I just 
don't know the right insertion point in the code to do this.

I hope this helps in some way.

 - Dan


> -Original Message-
> From: osg-users [mailto:osg-users-boun...@lists.openscenegraph.org] On
> Behalf Of Robert Osfield
> Sent: Monday, June 11, 2018 10:48 AM
> To: OpenSceneGraph Users
> Subject: Re: [osg-users] VBO Bug with 3.6.1 and Normal Arrays
> 
> Hi Daniel,
> 
> Thanks for looking further into this.  I did some investigation
> originally but didn't get to the bottom of the issue.  FYI, the
> support for Vertex Array Objects is what instigated these changes to
> way that VBO's had to be managed.  Essentially all osg::Array with per
> vertex bindings now need have a a VertexBufferObject assigned.
> 
> If you have made a commit for this fix against your own git clone of
> the OSG just pointing me at this commit should help me understand what
> is going on better.
> 
> Cheers,
> Robert.
> On Mon, 11 Jun 2018 at 14:44, Daniel Emminizer, Code 5773
>  wrote:
> >
> > Hi Robert,
> >
> > I am back from travel and looking at this again.  Didn't get a response on 
> > last
> set of questions about this crash.  Sorry to distract from the Vulkan work -- 
> it
> sounds interesting, and I'm watching your progress there excitedly.
> >
> >
> > Core problem seems to be that Array::setBinding() can change after
> Geometry::set*Array().  Geometry::set*Array() is responsible for calling
> addVertexBufferObjectIfRequired(), and doesn't have enough information
> to correctly do so.
> >
> > During the draw traversal, as a result, the Array::getBinding() flag does 
> > not
> match the VBO state in Geometry.
> >
> > One solution is to create the VBO as needed (using
> addVertexBufferObjectIfRequired) sometime between the start of cull
> phase and before the Geometry::drawImplementation().  But
> drawImplementation() is const, and not a place where this can happen.
> >
> >
> > Another possible solution that might help is to modify
> Geometry::setPrimitiveSet() and addPrimitiveSet() to call
> addVertexBufferObjectIfRequired() on the various arrays.  I prototyped this
> solution locally and it resolved the issue in the FLT loader.  I know it's not
> perfect, but most places I've seen that would trigger this bug have defined
> an array binding by the time a primitive set is added.
> >
> > Should I submit a PR for this approach?  It keeps binary compatibility and 
> > is
> fairly straightforward, and helps my immediate crash out of FLT and most of
> the other use cases I've encountered.
> >
> > Thanks,
> >
> >  - Dan
> >
> >
> >
> > > -Original Message-
> > > From: Daniel Emminizer, Code 5773
> > > Sent: Monday, June 04, 2018 8:45 AM
> > > To: OpenSceneGraph Users
> > > Subject: RE: [osg-users] VBO Bug with 3.6.1 and Normal Arrays
> > >
> > > Hi Robert,
> > >
> > > The file you sent is identical to the one I sent.  Was that intentional?  
> > > You
> also
> > > mention Cessna; do you have the examples mixed up perhaps?
> > >
> > > The bug will manifest if the geometry's normal array (and presumably
> fog,
> > > colors, etc) are set before the array binding type is set.  It's entirely
> possible
> > > to have correctly loaded models.  I only ran across this because the
> > > OpenFlight loader sets the binding late.
> > >
> > >
> > > This bug prints on console:
> > >
> > > Warning: detected OpenGL error 'invalid operation' at after
> > > drawable.compileGLObjects() call in
> GLObjectsVisitor::apply(osg::Drawable&
> > > drawable)
> > >
> > >
> > > No change in error message with with OSG_GL_ERROR_CHECKING=on.
> No
> > > change in error message with --ro, with --reset, or with --ro --reset.
> > >
> > > I am building OSG 3.6.1 (and tried OpenSceneGraph-3.6) in core profile on
> > > Windows 10.  Video card data is:
> > >
> > > Vendor = NVIDIA Corporation
> > > Renderer = NVS 510/PCIe/SSE2
> > > Version = 3.3

Re: [osg-users] VBO Bug with 3.6.1 and Normal Arrays

[Daniel Emminizer, Code 5773]

Hi Robert,

Thanks for this change.  Unfortunately it does not look like it fixes my issue.

I'm building GL3 core profile mode against OpenSceneGraph-3.6.  I use the 
main.cpp and CMakeLists.txt from my 6/1/18 email.  I'm using NVidia card with 
NVS 510, driver 388.19, OpenGL version 3.3.0 (due to core profile flag).  It is 
Windows 10.

I still see the error:
Warning: detected OpenGL error `invalid operation` at after 
drawable.compileGLObjects() call in GLObjectsVisitor::apply(osg::Drawable& 
drawable)

I have no modifications to OSG.  I did a full rebuild from scratch on OSG.


> What I believe is the problem is that the the VertexArrayState object
> gets initialized by the realizer operation and uses the
> State::getUseVertexAttributeAliasing() that was current at the time of
> the realizer operation, then code then calls
> State::setUseVertexAttributeAliasing() afterwards to a different
> value, so the rest of the OSG assumes that is now the current value
> but the global VertexArrayState is still set up against the original
> value so is passing using GL vertex array settings that are
> inconsistent with the shaders.

This is the second email you've mentioned the realizer operation.  I do not 
understand what you're referring to; this is very likely my inexperience with 
the depth of OSG.  Do you mean the code that eventually calls and includes 
Geometry::drawVertexArraysImplementation()?

I do not see any code that calls State::setUseVertexAttributeAliasing() in 
osg/src/*/*, or in osg/include/*/*.  I don't call it in main.cpp either (and if 
I did, I would only call it at startup, not on each geometry creation).

Are we running the same main.cpp?  I'm attaching my original just in case.

Thanks,

 - Dan



> -Original Message-
> From: osg-users [mailto:osg-users-boun...@lists.openscenegraph.org] On
> Behalf Of Robert Osfield
> Sent: Wednesday, June 13, 2018 7:45 AM
> To: OpenSceneGraph Users
> Subject: Re: [osg-users] VBO Bug with 3.6.1 and Normal Arrays
> 
> Hi Dan et. al,
> 
> I have had another look into this issue, looked at Dan's workaround
> and used Dan's test example to see investigate what might be going on.
> I have checked in a fix:
> 
> 
> https://github.com/openscenegraph/OpenSceneGraph/commit/673292b995
> 115c6ca9a3cc82c26e05023f504774
> 
> This allows the test example to work correctly in all different
> combinations with the realizer operation on/off etc.
> 
> What I believe is the problem is that the the VertexArrayState object
> gets initialized by the realizer operation and uses the
> State::getUseVertexAttributeAliasing() that was current at the time of
> the realizer operation, then code then calls
> State::setUseVertexAttributeAliasing() afterwards to a different
> value, so the rest of the OSG assumes that is now the current value
> but the global VertexArrayState is still set up against the original
> value so is passing using GL vertex array settings that are
> inconsistent with the shaders.
> 
> The solution is simple reassign the VertexArrayState for each call to
> State::setUseVertexAttributeAliasing().
> 
> I have only tested with Dan's test program, there is chance that other
> usage cases might tease out the issue in a different way, fingers
> crossed the just solves all these issue.
> 
> Could users who've seen issues with the arrays being used correctly
> update to the head of the OpenSceneGraph-3.6 branch and let me know
> how you get on.
> 
> If this all works fine then we can start looking at a release of 3.6.2
> this month.
> 
> Cheers,
> Robert.
> ___
> osg-users mailing list
> osg-users@lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
#include 
#include 
#include 
#include 

osg::Node* createTriangle(float x, bool earlyBinding, const osg::Vec4f& color)
{
osg::Geode* geode = new osg::Geode;
osg::Geometry* geom = new osg::Geometry;
geom->setUseVertexArrayObject(true);
geom->setUseVertexBufferObjects(true);

osg::Vec3Array* vertices = new osg::Vec3Array();
vertices->push_back(osg::Vec3(x - 100, 0, -100));
vertices->push_back(osg::Vec3(x, 0, 100));
vertices->push_back(osg::Vec3(x, 0, -100));

osg::Vec3Array* normals = new osg::Vec3Array;
normals->push_back(osg::Vec3(0, -1, 0));
normals->push_back(osg::Vec3(0, -1, 0));
normals->push_back(osg::Vec3(0, -1, 0));
if (earlyBinding)
normals->setBinding(osg::Array::BIND_PER_VERTEX);

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

geom->addPrimitiveSet(new osg::DrawArrays(GL_TRIANGLES, 0, 3));
geom->setVertexArray(vertices);
geom->setNormalArray(normals);
geom->setColorArray(colors);
geode->addDrawable(geom);

// Warning gets generated due to this line not causing (eventually) a VBO 
creation
if (!earlyBinding)
normals->setBinding(osg::Array::BIND_PER_VERTEX);
ret

Re: [osg-users] VBO Bug with 3.6.1 and Normal Arrays

[Daniel Emminizer, Code 5773]

Hi Robert,

I agree with your analysis on all points.  I did not see a quick solution that 
was "proper" either.

I agree that creating temporary VBOs doesn't seem like a wise solution.

I don't know enough about the inner workings to know if this is a dumb idea -- 
but could you perhaps detect the problem during cull (VBO attachment is NULL 
but array exists and is non-empty), then call addVertexBufferObjectIfRequired() 
on the geometry between the cull and the draw phases?  Given my brief exposure 
to Renderer.cpp, I think that is easier to say than do...


Just got your new email -- right, the VBO=0 occurs because the array never gets 
a VBO from array->setVertexBufferObject().  Because of this, 
VertexArrayState::setArray() gets 0 when it calls getOrCreateGLBufferObject().

Yes, in GL3 VAO is required, and VAO requires VBO.  We do require VAO and VBO 
in our application, because due to customer requirements we need to be 
targeting (or start targeting) the core profile.

 - Dan


> -Original Message-
> From: osg-users [mailto:osg-users-boun...@lists.openscenegraph.org] On
> Behalf Of Robert Osfield
> Sent: Wednesday, June 13, 2018 1:06 PM
> To: OpenSceneGraph Users
> Subject: Re: [osg-users] VBO Bug with 3.6.1 and Normal Arrays
> 
> Hi Dan, et. al,
> 
> I haven't yet got to bottom of this issue, but so far it looks like
> doing the Array::setBinding(Array::BIND_PER_VERTEX) call later than
> the array itself is assigned to the geometry bypasses the mechanism
> that osg::Geometry uses to make sure all the arrays that need a VBO
> have one assigned.
> 
> To clarify this issue further I've made the
> Geometry::addVertexBufferObjectIfRequired() public so I can see if
> calling this after the late Array::setBinding().  This isn't a
> solution, just another workaround, but for me mainly a means of
> testing a hypothos, to the problem late binding code I added the
> geom->addVertexBufferObjectIfRequired(normals); call:
> 
> if (!earlyBinding)
> {
> normals->setBinding(osg::Array::BIND_PER_VERTEX);
> geom->addVertexBufferObjectIfRequired(normals);
> }
> 
> This enables the test program to run properly without crash or
> warnings, both triangles now behave the same regardless of the early
> or late setBinding.  However, this isn't a proper solution, it won't
> fix problem without amending late setBinding() codes in the OSG or in
> client applications.  For these cases they really should be calling
> setBinding prior to the Geometry:set*Array() methods.
> 
> As things stand I can't see easy solution as the Array doesn't know
> about the osg::Geometry that it's attached to so can't jump in a do
> the addVertexBufferObjectIfRequired(), we could automatically assigned
> a local VBO when the Binding is set to BIND_PER_VERTEX but this would
> then lead to lots of separate VBO's being created all over the place
> where they aren't needed, and would blow up memory and performance.
> 
> Another avenue is perhaps to try and make the code a bit more
> resilient to a VBO being assigned or not.  I don't know exactly why we
> are getting crash in the draw code so I'll look into this next.
> 
> 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] VBO Bug with 3.6.1 and Normal Arrays

[Daniel Emminizer, Code 5773]

Hi Robert,

That would cover our primary use cases.  We've already done the same in all of 
our application code.

Catching the failure instead of crashing is very much preferred, even if it 
leads to a bad display.

I'm on board with this solution and can help test my end.

 - Dan


> -Original Message-
> From: osg-users [mailto:osg-users-boun...@lists.openscenegraph.org] On
> Behalf Of Robert Osfield
> Sent: Wednesday, June 13, 2018 3:28 PM
> To: OpenSceneGraph Users
> Subject: Re: [osg-users] VBO Bug with 3.6.1 and Normal Arrays
> 
> I am moving towards the idea that we may only be able to catch on the
> fly bad usage and disable the arrays that don't have a VBO assigned
> when trying to render with VAO, and emit a warning. this will be
> better than having an application crash.
> 
> I'm going to re-factor the existing places in the OSG where the later
> Array::setBinding() is being used so that doesn't cause problems, this
> will at least make the above problem case less likely. This won't fix
> application code that needs to be amended though.
> 
> 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] VBO Bug with 3.6.1 and Normal Arrays

[Daniel Emminizer, Code 5773]

Hi Robert,

I agree that your solution here seems to cover the common failure case 
(assigning by-vertex too late).  I think given the system constraints and time 
constraints, that is the best solution.

Your solution does work in all my testing.

Regarding a 3.6.2 release, that sounds great.  At this point we've upgraded 
almost all of our applications and this was the last major issue we had.  We've 
still got one minor text output annoyance, and I'll start a new thread on that 
once I track it down if it's a change in OSG causing it.  I'll do that in the 
next couple of days here.

Thanks,

 - Dan



> -Original Message-
> From: osg-users [mailto:osg-users-boun...@lists.openscenegraph.org] On
> Behalf Of Robert Osfield
> Sent: Thursday, June 14, 2018 4:10 AM
> To: OpenSceneGraph Users
> Subject: Re: [osg-users] VBO Bug with 3.6.1 and Normal Arrays
> 
> H Dan et. al,
> 
> On Thu, 14 Jun 2018 at 08:25, Robert Osfield 
> wrote:
> > Perhaps another approach would be to just warn the user that the
> > Binding hasn't been set prior to the Geometry::set*Array() call, or do
> > a belt and braces of treat an BIND_UNDEFINED binding as a
> > BIND_PER_VERTEX to force a VertexBufferObject to be assign
> > automatically even though it might not be needed.  This might waste a
> > byte or two but would probably be safe.
> 
> This is the approach I have taken, it fixes the test program when
> VAO's are used and the array::setBinding(..) is called after the
> Geometry::set*Array() call.
> 
> 
> https://github.com/openscenegraph/OpenSceneGraph/commit/4665a2f033
> 68be95f4773463f733dbdd88f63c5f
> 
> I think it's the safest and least intrusive way to catch late calls to
> setBinding(..).
> 
> Could you all test the OpenSceneGraph-3.6 head and if this works fine
> we can start thinking about going for 3.6.2.
> 
> 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] OpenSceneGraph-3.6.2-rc1 tagged, please test

[Daniel Emminizer, Code 5773]

Hi Robert,

I’ve built and have been running OSG 3.6.2-rc1 on several MSVC versions and g++ 
4.4 without problems since Wednesday.  Success all around so far.

- Dan



From: osg-users [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf 
Of Robert Osfield
Sent: Wednesday, June 20, 2018 9:09 AM
To: OpenSceneGraph Users
Subject: [osg-users] OpenSceneGraph-3.6.2-rc1 tagged, please test

Hi All,

Since the 3.6.1 stable release went out there have a several bugs picked up and 
fixed, so I've begun the process of getting a 3.6.2 maintenance release out to 
wrap these improvements up. There is always a chance that these fixes have 
introduced regressions, or simply that there are still bugs left to uncover so 
further community testing of required.  As it hasn't been long since 3.6.1 I'm 
optimistic that it won't take much to get 3.6.2 ready to go out, I'm hoping to 
tag the 3.6.2 before the end of next week as I'll be heading off for 10 days 
holiday right after :-)

First step towards 3.6.2 is our first release candidate:

  https://github.com/openscenegraph/OpenSceneGraph/tree/OpenSceneGraph-3.6.2-rc1

Please test across as many build combinations and end user applications as you 
can.  Could you report success or failures here on this thread so we have an 
idea of how well things are converging towards the final 3.6.2.

Thanks for you help testing,
Robert.

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

Re: [osg-users] OpenSceneGraph-3.6.2-rc1 tagged, please test

[Daniel Emminizer, Code 5773]

Hi Robert,

I think this issue was about the text bounding box.  I've got a small use case 
where we create a text block with a bounding box behind it.  There's a GUI to 
edit the text string shown.  If the text string is changed after the 
osgText::Text is shown, sometimes the bounding box behind it grows unexpectedly 
(e.g. adding a space character at the end will make the bounding box taller and 
wider than you might expect).

We also have a minor issue where the bounding box isn't drawn if the text 
backdrop is not NONE.  That might be by design however, and I can understand 
why if so.

Both of these issues are very trivial to us currently and I did not have time 
to come up with a reproducible example for either issue.  No need to hold up 
3.6.2 at this point on my account.

 - Dan



> -Original Message-
> From: osg-users [mailto:osg-users-boun...@lists.openscenegraph.org] On
> Behalf Of Robert Osfield
> Sent: Monday, June 25, 2018 5:46 AM
> To: OpenSceneGraph Users
> Subject: Re: [osg-users] OpenSceneGraph-3.6.2-rc1 tagged, please test
> 
> Hi Dan,
> 
> On Mon, 25 Jun 2018 at 10:37, Daniel Emminizer, Code 5773
>  wrote:
> > I’ve built and have been running OSG 3.6.2-rc1 on several MSVC versions
> and g++ 4.4 without problems since Wednesday.  Success all around so far.
> 
> Thanks for the testing and feedback, good to hear it's working OK.
> 
> Prior to the 3.6.2-rc1 you mentioned that you were seeing an issue
> with text and were going to try to create a test that reproduces the
> issue.  What is the status with this issue now?
> 
> 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] OpenSceneGraph-3.6.2-rc1 tagged, please test

[Daniel Emminizer, Code 5773]

Hi Robert,

Just a heads up that I found a bug in osg::PointSprite().  The 
GL_POINT_SPRITE_ARB mode is invalid starting in GL3, and core profile will 
complain about it on console.  The fix is straightforward, I’m preparing a pull 
request now.  It does not impact any APIs and should be easy to fit in the 
release if desired.

- Dan



From: Daniel Emminizer, Code 5773
Sent: Monday, June 25, 2018 5:37 AM
To: OpenSceneGraph Users
Subject: RE: [osg-users] OpenSceneGraph-3.6.2-rc1 tagged, please test

Hi Robert,

I’ve built and have been running OSG 3.6.2-rc1 on several MSVC versions and g++ 
4.4 without problems since Wednesday.  Success all around so far.

- Dan



From: osg-users [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf 
Of Robert Osfield
Sent: Wednesday, June 20, 2018 9:09 AM
To: OpenSceneGraph Users
Subject: [osg-users] OpenSceneGraph-3.6.2-rc1 tagged, please test

Hi All,

Since the 3.6.1 stable release went out there have a several bugs picked up and 
fixed, so I've begun the process of getting a 3.6.2 maintenance release out to 
wrap these improvements up. There is always a chance that these fixes have 
introduced regressions, or simply that there are still bugs left to uncover so 
further community testing of required.  As it hasn't been long since 3.6.1 I'm 
optimistic that it won't take much to get 3.6.2 ready to go out, I'm hoping to 
tag the 3.6.2 before the end of next week as I'll be heading off for 10 days 
holiday right after :-)

First step towards 3.6.2 is our first release candidate:

  https://github.com/openscenegraph/OpenSceneGraph/tree/OpenSceneGraph-3.6.2-rc1

Please test across as many build combinations and end user applications as you 
can.  Could you report success or failures here on this thread so we have an 
idea of how well things are converging towards the final 3.6.2.

Thanks for you help testing,
Robert.

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

Re: [osg-users] GL3 Profile

[Daniel Emminizer, Code 5773]

Hi Maxim / Robert,

I am using GL3 on Windows.  I had to download and slightly modify the Khronos 
glcorearb.h file, to get it working right with the declspec or dllimport or 
whatever it was.  It was not trivial or obvious by any means.  But it works 
now, after supplying that file.

I understand where you're coming from Maxim, but one thing I don't get:


>> So the fix I can make is change the CMake script to use the modern default 
>> windows GL headers which will enable people to use the GL3 profile option, 
>> and configure cmake to disable everything that needs to be turned off in 
>> that case.

What and where is the "modern default windows GL headers" ?  I have the Windows 
Kit 8.1 installed currently.  That's where my implementation is finding 
gl/GL.h.  It has no glcorearb.h that I can find, and its GL.h is only defined 
up to OpenGL 1.1.  Can you explain where the headers are that you're referring 
to?

I too would like it if Windows just worked better.  But without the OS having a 
reasonable way to update the headers, I thought we were pretty much stuck with 
manually configuring OSG on the command line.

 - Dan



> -Original Message-
> From: osg-users [mailto:osg-users-boun...@lists.openscenegraph.org] On
> Behalf Of Robert Osfield
> Sent: Tuesday, June 26, 2018 11:42 AM
> To: OpenSceneGraph Users
> Subject: Re: [osg-users] GL3 Profile
> 
> Hi Maxim,
> 
> On Tue, 26 Jun 2018 at 14:59, Maxim Stere  wrote:
> > We don't want to do anything like GL3_WINDOWS since most likely that will
> have to have a new external dependency.
> 
> ?? So you don't want to install the official glcorearb.h for some
> reason, and me suggesition of just relying upon gl.h and have the OSG
> add the extra's still isn't enough for you and think that you still
> need an extra dependency.
> 
> > But if we make the GL3 profile fall back on what already is there, it might 
> > be
> missing a few functions that the user will have to link to manually in the
> windows environment, but at least the context version will be correct, and
> the deprecated functions will be gone.
> 
> ?? What missing functions?
> 
> > Right now GL3 selection and auto configuration does not work on windows
> at all...
> 
> It might not be working for YOU, with you particular preference
> for/against certain things, but I'm pretty sure that there are other
> Windows users using GL3 without any issues.
> 
> I'm not a Window users myself so I'll defer to others to help you work
> out what you need to do.
> 
> 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

[osg-users] Scaled Images with GL_RG Format

[Daniel Emminizer, Code 5773]

Hi Robert,

I have found a minor bug with image scaling.  I have a texture that is 1024x768 
that is being resized to 1024x1024 for a Texture2D.  
Texture::applyTexImage2D_load() detects the need to resize and tries to do so 
through gluScaleImage(), which is implemented in src/osg/glu/libutil/mipmap.cpp.

All that works great for most of my images, but this image is greyscale with 
alpha.  GL spec deprecates GL_LUMINANCE_ALPHA and requires use of GL_RG for 
these images types.  But the code in gluScaleImage() does not respect GL_RG 
(though it supports many other formats).

This patch treats GL_RG identically to GL_LUMINANCE; a simple 2 element format.

After this patch, my image shows up fine.  Mipmap.cpp supports many other 
similar types, like GL_RED.  Risk of this change seems pretty low.

PR is up at https://github.com/openscenegraph/OpenSceneGraph/pull/566

Thanks,

 - Dan

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

Re: [osg-users] Build error under Windows? Need feedback from Windows users to understand issue

[Daniel Emminizer, Code 5773]

Hi Robert,

I can vouch that it compiles on MSVC 2015, MSVC 2010, and g++ 4.4.  I did not 
test 2012 or 2013, since I figured 2010 and 2015 ought to cover (2015 is 
_MSC_VER 1900).  I only tested 64 bit variants.  I do not have MSVC 2017 to 
test against.

I am also not familiar with the code in question, and we don't directly use the 
osga plugin  in our software so I'm not sure how to test beyond ensuring that 
it compiles.  So it does compile and doesn't break my system, that I can tell.

Hope this helps some.

 - Dan


> -Original Message-
> From: osg-users [mailto:osg-users-boun...@lists.openscenegraph.org] On
> Behalf Of Robert Osfield
> Sent: Wednesday, June 27, 2018 7:11 AM
> To: OpenSceneGraph Users
> Subject: [osg-users] Build error under Windows? Need feedback from
> Windows users to understand issue
> 
> Hi All,
> 
> A PR has just been placed on the openscenegraph github repository:
> 
> https://github.com/openscenegraph/OpenSceneGraph/pull/567
> 
> I am bit surprised by the need for this PR as I had assumed that the
> code base was being rested pretty well under Windows with all the
> recent stable release work.
> 
> I have asked for the author of the PR for clarification.
> 
> I would like to know form the Windows experts in the community about
> whether this PR is perfectly fine, or there is some simpler resolution
> for this users build combination.
> 
> As I'm about to make a 3.6.2 I obviously want the code base to be in
> place where it's compiling well for a broad range of users, I'm also
> keenly aware that a build fix for one user could be a build break for
> many others so am super cautious at this point in time.
> 
> 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

[osg-users] Exporting OpenFlight Models

[Daniel Emminizer, Code 5773]

Hi Robert,

Tl;dr: I think I found a bug in OpenFlight's FltExportVisitor::isTextured() 
when FFP is disabled.  This email explains PR 568 more thoroughly.



I am having problems saving out OpenFlight models and was hoping someone could 
point out what I'm doing wrong.  I think I might have identified a bug but 
would like another set of eyes.

I have an open source FLT that is textured that I'm trying to load, make a 
minor edit to, and save out.  My code is simple:

osg::ref_ptr opts = new osgDB::Options;
opts->setOptionString("keepExternalReferences");
osg::ref_ptr node = osgDB::readRefNodeFile(argv[1], opts.get());

opts = new osgDB::Options;
bool succeeded = osgDB::writeNodeFile(*node, argv[2], opts.get());

It writes out the geometry, but never writes out the textures.  I've spent the 
last couple of hours tracking down why and I think I understand.  I'm using GL3 
/ GLCORE mode in OSG 3.6.2-rc2.  I think it's important to note this because I 
believe the bug is related to a FFP change with StateSet.

The OpenFlight loader reads the image and the textures just fine, and displays 
them.  TexturePalette::readTexture() correctly calls 
setTextureAttributeAndModes() with a valid texture.  This ends up calling 
osg::Texture::getModeUsage(), which is responsible for turning on GL_TEXTURE_2D.

Later on, the FltExportVisitor only respects a texture if GL_TEXTURE_2D is 
enabled, via FltExportVisitor::isTextured().

But when OSG_GL_FIXED_FUNCTION_AVAILABLE is disabled due to GLCORE profile, 
osg::Texture::getModeUsage() is not defined, so setTextureAttributeandModes() 
never sets the mode on GL_TEXTURE_2D.


I think the fix is to update isTextured() to check for presence of a texture 
when OSG_GL_FIXED_FUNCTION_AVAILABLE is not set.  Does this seem reasonable?

I have put up a PR to inspect at: 
https://github.com/openscenegraph/OpenSceneGraph/pull/568

I do have workarounds on my side, so this isn't super critical.  But I think it 
will impact anyone who uses OSG with GLCORE mode who is trying to export FLT 
files.

Thanks,

 - Dan

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

Re: [osg-users] Exporting OpenFlight Models

[Daniel Emminizer, Code 5773]

Hi Robert,

Thanks for the merge!  It helps.


A little explanation, if you have any interest.  It's a little long, but I hope 
to explain why we're looking at Core Profile.  I'd like to think it's for good 
reason.

I'm with you on the OSX issues.  I think it's a shame about what's going on 
over there.  I've seen your comments on the mailing list about their direction 
of development and I do agree with it.

However, core profile isn't a requirement only on OSX.  We have a lot of users 
that run our software on a variety of hardware and platforms, supporting 
primarily Windows and RedHat systems, but also other Linux variants, on both 
real and virtual hardware.  In a perfect world, everyone is using a reasonable 
graphics card (better than an etch-a-sketch) with good drivers.  But what we've 
found is far from that.

Requirements wise, we're using osgEarth on top of OSG.  They're invested pretty 
heavily in Interface Blocks ( 
https://www.khronos.org/opengl/wiki/Interface_Block_(GLSL) ), which require 
OpenGL 3.1 (GLSL 1.4), but there are also several shaders that start to push 
into GLSL 3.3 territory (GLSL 3.3).  Ultimately we have a required minimum 
version of OpenGL in the 3.3 territory. That is no problem on most systems.

But we've run into more issues on three system configurations in particular:

* VMware systems running Windows using hardware acceleration
* Linux systems running Intel drivers (open source)
* Linux systems running Nvidia cards with open source drivers

In all three of these systems, we're seeing Mesa-based accelerated systems 
where core profile is supported somewhere between version GL 3.3 and GL 4.2.  
But compatibility profile support is extremely lacking.  Some of these systems 
report "high" OpenGL versions of 2.0, with GLSL shader versions of 1.4 or 1.5 
(note the official mismatch between OpenGL version and GLSL version).  Others 
support only OpenGL 1.x, with GLSL versions as low as 1.2 in compatibility 
profile.

But they have full core profile support.

We're stuck with these systems because we don't get to configure the hardware 
on our users' systems.  The third bullet in particular can be frustrating 
because the users have good hardware, but are unable (for a variety of reasons) 
to install the proprietary drivers that address these issues.


As I understand, some of the newer Mesa drivers are pushing towards better 
compatibility profile support.  While that's great, we've seen a drastic 
difference in correctness of compatibility profile features across Nvidia to 
ATI to Intel drivers.  Now there's Mesa drivers to consider too, and the 
various related variants.  We've noticed fewer differences (bugs) as we migrate 
towards a more shader-heavy infrastructure and away from relying on 
compatibility profile, er, hacks.

However, even if Mesa were to support better compatibility mode drivers, that 
does not help us now, where we are stuck supporting RedHat 6 and RedHat 7 
machines with the much older Mesa implementations.

Simply telling our users they must upgrade their hardware and drivers isn't a 
reasonable path forward; in many cases they cannot.  We could try to back up to 
OpenGL 1.x and GLSL 1.2 to hit lowest common denominator, but that is extremely 
limiting, and would take a great deal of effort.  Vulkan isn't an option for 
hopefully obvious reasons.  Our remaining option to run on these systems is 
Core Profile.

Core Profile is supported on far more systems past 3.3 since Compatibility 
Profile is optional.  It's messy comparatively and although I don't like it, I 
understand why Compatibility Profile support is more dicey for drivers to 
implement correctly (or at all in some cases)

I also understand your desire to want to support and push primarily 
Compatibility Profile.  Mixing and matching the two is messy, and requiring a 
full new build of OpenSceneGraph to run on systems that only support Core 
Profile can be painful, at least on the Windows side, due to long build times 
(thanks MSVC) and poor system support for modern GL (e.g. glcorearb.h 
discussion in the last week).  But that's our problem to deal with, not 
necessarily yours, and that's OK.

Anyways, I just wanted to point out that it's more than just OSX that needs 
Core Profile.  If you're doing anything with more modern GLSL you'll also need 
to be looking at Core Profile, or you'll lock yourself away from a reasonable 
segment of a potential user base.  And unlike Vulkan, support for Core Profile 
seems to be pretty reasonable across drivers for hardware that's been deployed 
in the last 8 years, at least in our particular user base.

I appreciate your receptiveness to patches that help with Core Profile support. 
 The work you did on VAO and Text in particular have been invaluable.  Thanks 
for your work on OpenSceneGraph.  Sorry for the long message.

 - Dan

 

> -Original Message-
> From: osg-users [mailto:osg-users-boun...@lists.openscenegraph.org] On
> Behalf Of Robert

[osg-users] Unbounded growth in OpenFlight ReaderWriter

[Daniel Emminizer, Code 5773]

Hello All,

I've found what appears to be unbounded growth in the OpenFlight loader.  I 
have a work-around but wanted to run it past the community since there are many 
here who are more familiar with the format and the loader than me.

I'm seeing uncontrolled memory growth when using the std::istream version of 
readNode.  It appears to populate the local cache with new images, but never 
clears out the local cache.  The filename-based version of readNode() does 
clear out the cache before it returns.

Does it make sense to add in:

flt::Registry::instance()->clearLocalCache();

... before the return of the ReadResult at the bottom of this method at 
https://github.com/openscenegraph/OpenSceneGraph/blob/master/src/osgPlugins/OpenFlight/ReaderWriterFLT.cpp#L533
 ?


If that's not a good path forward, do you have any suggestions on how to clear 
the cache on demand?

Thanks,

 - Dan

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

Re: [osg-users] Unbounded growth in OpenFlight ReaderWriter

[Daniel Emminizer, Code 5773]

Hi Chris,

I think that would be good.  I have some modifications following Robert’s 
advice and after more testing I will be posting a PR.  Yes, all of the object 
caching in OpenFlight plugin is the original code from Brede.  It all dates 
back to 2006.

I was able to swap to use osgDB::Registry’s object cache with no complications 
on my end.  I also got to learn more about the object caching system and how it 
clears out old values.  Thanks Robert for the suggestion to look in this 
direction.

I ended up posting a PR at 
https://github.com/openscenegraph/OpenSceneGraph/pull/583 -  It’s low priority 
since it’s a 12 year old issue, and because it takes a lot of work to get large 
enough images to crash an app from the problem on modern systems.

Thanks,

- Dan



From: osg-users [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf 
Of Chris Hanson
Sent: Tuesday, July 31, 2018 10:40 AM
To: OpenSceneGraph Users
Subject: Re: [osg-users] Unbounded growth in OpenFlight ReaderWriter

I think Brede Johansson wrote that loader once upon a time. I'm hoping to 
connect with him in Oslo this week. Maybe I'll ask him about this if I do.

On Tue, Jul 31, 2018 at 11:54 AM Daniel Emminizer, Code 5773 
mailto:dan.emmini...@nrl.navy.mil>> wrote:
Hello All,

I've found what appears to be unbounded growth in the OpenFlight loader.  I 
have a work-around but wanted to run it past the community since there are many 
here who are more familiar with the format and the loader than me.

I'm seeing uncontrolled memory growth when using the std::istream version of 
readNode.  It appears to populate the local cache with new images, but never 
clears out the local cache.  The filename-based version of readNode() does 
clear out the cache before it returns.

Does it make sense to add in:

flt::Registry::instance()->clearLocalCache();

... before the return of the ReadResult at the bottom of this method at 
https://github.com/openscenegraph/OpenSceneGraph/blob/master/src/osgPlugins/OpenFlight/ReaderWriterFLT.cpp#L533
 ?


If that's not a good path forward, do you have any suggestions on how to clear 
the cache on demand?

Thanks,

 - Dan

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


--
Chris 'Xenon' Hanson, omo sanza lettere. xe...@alphapixel.com 
http://www.alphapixel.com/
Training • Consulting • Contracting
3D • Scene Graphs (Open Scene Graph/OSG) • OpenGL 2 • OpenGL 3 • OpenGL 4 • 
GLSL • OpenGL ES 1 • OpenGL ES 2 • OpenCL
Legal/IP • Forensics • Imaging • UAVs • GIS • GPS • osgEarth • Terrain • 
Telemetry • Cryptography • LIDAR • Embedded • Mobile • iPhone/iPad/iOS • Android
@alphapixel<https://twitter.com/alphapixel> 
facebook.com/alphapixel<http://facebook.com/alphapixel> (775) 623-PIXL [7495]
___
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

[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());

OSG_NOTICE << "Point Sprite Mode Validity Tester\n";
OSG_NOTICE << "Arguments:\n";
OSG_NOTICE << "  --cameraApply osg::PointSprite to Camera's state set

[osg-users] VAO Resource Leak in OSG 3.6.2

[Daniel Emminizer, Code 5773]

Hi Robert,

I think I've found a resource leak in OSG 3.6.2.  Attached is a contrived 
sample application that demonstrates the behavior.

What appears to be happening is that the VAO is being created with 
glGenVertexArrays(), but does not get deleted with glDeleteVertexArrays().  
Using the open source API Trace, I can see that on exit it does destroy some 
VAO, but not (nearly) all of them.

I'm investigating now for a solution, but I'm not very familiar with this part 
of OSG.  I'm passing this along now in case you see an obvious solution.  
Thanks,

 - Dan


#include 
#include 
#include 
#include 
#include 

static const float RADIUS = 55.f;
static const osg::Vec4f DOT_COLORS(1.f, 0.f, 1.f, 1.f);

// Creates a Geode with 120 points in a circle at a given scale (radius), 
rotation angle, and color
osg::Geode* createCircle(const osg::Vec4f& color, float radius, float 
extraRotateDeg)
{
osg::Geode* geode = new osg::Geode;
osg::Geometry* geom = new osg::Geometry;
geom->setUseVertexArrayObject(true);
geom->setUseVertexBufferObjects(true);

// 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 + extraRotateDeg);
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;
}

// Creates the top level group for the scene
osg::Group* createScene()
{
osg::Group* group = new osg::Group;
osgText::Text* text = new osgText::Text;
text->setText("Demo of missing glDeleteVertexArrays.");
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;
}

// On every frame, this handler removes the circle geode and recreates it.  I 
know this is not efficient,
// but this test application is only intended to demonstrate the problem found 
in a real app.
struct NewGeodeOnFrame : public osgGA::GUIEventHandler
{
explicit NewGeodeOnFrame(osg::Group* group)
: group_(group)
{
}

virtual bool handle(const osgGA::GUIEventAdapter& ea, 
osgGA::GUIActionAdapter& aa, osg::Object* obj, osg::NodeVisitor* nv)
{
if (ea.getEventType() == ea.FRAME)
{
group_->removeChildren(0, group_->getNumChildren());
group_->addChild(createCircle(DOT_COLORS, RADIUS, 3.0 * 
ea.getTime()));
}
return GUIEventHandler::handle(ea, aa, obj, nv);
}

osg::ref_ptr group_;
};

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

// construct the viewer.
osgViewer::Viewer viewer(arguments);
osg::Group* scene = createScene();

// Add a holder for our rotating circle
osg::Group* geodeHolder = new osg::Group;
scene->addChild(geodeHolder);

viewer.setSceneData(scene);
viewer.setUpViewInWindow(100, 100, 800, 600);
viewer.addEventHandler(new osgViewer::StatsHandler());
// Recreate the circle on every FRAME event
viewer.addEventHandler(new NewGeodeOnFrame(geodeHolder));

return viewer.run();
}
cmake_minimum_required(VERSION 2.6)

SET(PROJECT_NAME leaking_vao)

PROJECT(${PROJECT_NAME})

FIND_PACKAGE(OpenThreads)
FIND_PACKAGE(osg)
FIND_PACKAGE(osgDB)
FIND_PACKAGE(osgUtil)
FIND_PACKAGE(osgGA)
FIND_PACKAGE(osgViewer)
FIND_PACKAGE(osgText)

SET(SOURCES
LeakingVao.cpp
)

INCLUDE_DIRECTORIES(${OPENTHREADS_INCLUDE_DIR} ${OSG_INCLUDE_DIR})

LINK_DIRECTORIES(${OSG_LIB_DIR})

ADD_EXECUTABLE(${PROJECT_NAME} ${SOURCES})

TARGET_LINK_LIBRARIES(${PROJECT_NAME} ${OSG_LIBRARIES} ${OSGVIEWER_LIBRARIES} 
${OSGUTIL_LIBRARIES} ${OSGDB_LIBRARIES} ${OSGGA_LIBRARIES} ${OSGTEXT_LIBRARIES} 
${OPENTHREADS_LIBRARIES})
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] VAO Resource Leak in OSG 3.6.2

[Daniel Emminizer, Code 5773]

Hi Robert,

No problem.  I'm out of "panic" mode since I found a work-around with the PR, 
so next week is just fine.

Thanks for the PR feedback.  Unfortunately I'm unavailable all next week.  I'm 
happy to retest any fix you have once I'm back.

I hope Vulkan work is going well.  I'm watching the mailing list with 
anticipation.

 - Dan 


> -Original Message-
> From: osg-users [mailto:osg-users-boun...@lists.openscenegraph.org] On
> Behalf Of Robert Osfield
> Sent: Friday, August 03, 2018 4:11 AM
> To: OpenSceneGraph Users
> Subject: Re: [osg-users] VAO Resource Leak in OSG 3.6.2
> 
> Hi Dan,
> 
> I'll be focusing on Vulkan work today so won't look into this right
> away.  Next week I'll set aside a day for OSG maintenance and
> hopefully will be able to look at this then.
> 
> Robert.
> On Thu, 2 Aug 2018 at 15:49, Daniel Emminizer, Code 5773
>  wrote:
> >
> > Hi Robert,
> >
> > I think I've found a resource leak in OSG 3.6.2.  Attached is a contrived
> sample application that demonstrates the behavior.
> >
> > What appears to be happening is that the VAO is being created with
> glGenVertexArrays(), but does not get deleted with glDeleteVertexArrays().
> Using the open source API Trace, I can see that on exit it does destroy some
> VAO, but not (nearly) all of them.
> >
> > I'm investigating now for a solution, but I'm not very familiar with this 
> > part
> of OSG.  I'm passing this along now in case you see an obvious solution.
> Thanks,
> >
> >  - Dan
> >
> >
> > ___
> > 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
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] VAO Resource Leak in OSG 3.6.2

[Daniel Emminizer, Code 5773]

Hi Guy,

I attached to the original issue a use case that reproduces the problem.  
glDeleteVertexArrays() is never called on many of the arrays, although the 
associated geometry is destroyed.  This goes until exit.  The VAOs leak.  This 
can be verified by running a profiler on GL and examining the OpenGL commands 
executed.  The example does not use osgDB and wouldn't have CACHE_NODES 
enabled; please let me know if you think otherwise, I'd like to learn more.

Earlier someone mentioned not having a memory leak with this; but I am seeing 
on Windows and Linux associated and significant growth (over time) with these 
lost VAOs in Task Manager (Windows) and in top (Linux).  So although it's 
technically a resource leak, that resource has (at least on my system) real 
memory associated with the running application.

I'm seeing this because real apps out there are encountering SIGKILL conditions 
under Linux due to running into the out-of-memory (OOM) handler.  The code in 
the PR prevents this.  Though as Julien points out, the PR could have issues 
with shared arrays amongst multiple geometries, but I don't have that use case 
in my apps and I do not see any examples in OSG that demonstrate this 
capability.  We patched locally to prevent this SIGKILL in live code and have 
had no further reported issues in the last week and a half about it.

Hope this helps explain.  Thanks,

 - Dan



> -Original Message-
> From: osg-users [mailto:osg-users-boun...@lists.openscenegraph.org] On
> Behalf Of Guy Volckaert
> Sent: Monday, August 13, 2018 12:14 PM
> To: osg-users@lists.openscenegraph.org
> Subject: Re: [osg-users] VAO Resource Leak in OSG 3.6.2
> 
> Julien,
> 
> Yo may want to verify if you have CACHE_NODES enabled. If so, then you
> may think there's a resource leak but in fact the scene graph leading to your
> Geometry may be cached by OSG.
> 
> --
> Read this topic online here:
> http://forum.openscenegraph.org/viewtopic.php?p=74511#74511
> 
> 
> 
> 
> 
> ___
> 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] VAO Resource Leak in OSG 3.6.2

[Daniel Emminizer, Code 5773]

Hi Robert, thanks for the update.  I'm happy to test my side against whatever 
you decide, once I'm in the office.

Thanks,

 - Dan


> -Original Message-
> From: osg-users [mailto:osg-users-boun...@lists.openscenegraph.org] On
> Behalf Of Robert Osfield
> Sent: Thursday, August 16, 2018 1:33 PM
> To: OpenSceneGraph Users
> Subject: Re: [osg-users] VAO Resource Leak in OSG 3.6.2
> 
> Hi Dan et al.
> 
> A quick update.  I am now looking into this issue, sill too early to
> provide a solution, it shouldn't take too much longer though.
> 
> 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] VAO Resource Leak in OSG 3.6.2

[Daniel Emminizer, Code 5773]

Hi Robert,

Just got finished testing on my side.  In the full application I'm seeing no 
problems, looks good all around.  I agree all closed out.  Thanks for your help.

 - Dan


> -Original Message-
> From: osg-users [mailto:osg-users-boun...@lists.openscenegraph.org] On
> Behalf Of Robert Osfield
> Sent: Friday, August 17, 2018 4:03 AM
> To: OpenSceneGraph Users
> Subject: Re: [osg-users] VAO Resource Leak in OSG 3.6.2
> 
> Hi Dan,
> 
> On Fri, 17 Aug 2018 at 07:04, Daniel Emminizer, Code 5773
>  wrote:
> > Hi Robert, thanks for the update.  I'm happy to test my side against
> whatever you decide, once I'm in the office.
> 
> I'm happy with what I've checked in, so now it's just a matter of wider
> testing.
> 
> 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

[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

[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

[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

[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] Textured PointSprites broken when upgrading from 3.5.6 to 3.6.2

[Daniel Emminizer, Code 5773]

Hi Brian,

This might be fixed by:

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

It's documented on the mailing list thread:

http://lists.openscenegraph.org/pipermail/osg-users-openscenegraph.org/2018-August/008829.html

- Dan



> -Original Message-
> From: osg-users [mailto:osg-users-boun...@lists.openscenegraph.org] On
> Behalf Of Brian Hutchison
> Sent: Wednesday, September 05, 2018 12:29 PM
> To: osg-users@lists.openscenegraph.org
> Subject: [osg-users] Textured PointSprites broken when upgrading from
> 3.5.6 to 3.6.2
> 
> Hi,
> 
> We recently upgraded OSG from 3.5.6 to 3.6.2 and our textured PointSprites
> stopped working.
> 
> In a debug build they work fine but in a release build they do not display 
> or, if
> they do, they display using a translucent version of the non-textured points
> which flash on and off as we navigate the scene.
> 
> The code is based on the osgpointsprite example - which we cannot get to
> fail.
> 
> The code is used by several features all of which have the bug.  If we strip 
> it
> down to just one feature using this code then it still has the bug.  If we 
> strip
> out the textures then default Points work fine on all features.
> 
> Using hard-coded textures instead of loading them from files does not help.
> 
> We have tried just about everything we can think of and are about to switch
> to a combination of non-textured points, billboards & simple geometries as a
> workaround.
> 
> 
> Code:
> 
> addPointSprite(mModel.base().dataPaths.resourcesPath(),
>PointSpriteShapes::Diamond,
>NodePointSizeLarge,
>NodePointSizeSmall,
>NodePointSizeLarge,
>mNodesGeometry);
> 
> const std::map PointSpriteFileNames =
> {
> {PointSpriteShapes::Circle, "Circle.png"},
> {PointSpriteShapes::Diamond, "Diamond.png"},
> {PointSpriteShapes::Square, "Square.png"},
> {PointSpriteShapes::MarkerRouteStart, "MarkerRouteStart.png"},
> {PointSpriteShapes::MarkerRouteBroken, "MarkerRouteBroken.png"},
> {PointSpriteShapes::MarkerRouteEnd, "MarkerRouteEnd.png"},
> };
> 
> void
> addPointSprite(const std::string & aResourcesPath,
>PointSpriteShapes   aSpriteShape,
>float   aStartingSize,
>float   aMinSize,
>float   aMaxSize,
>osg::Node * aNode)
> {
> Expects(PointSpriteFileNames.find(aSpriteShape) !=
> PointSpriteFileNames.end());
> 
> auto stateset = aNode->getOrCreateStateSet();
> 
> osg::ref_ptr sprite = new osg::PointSprite();
> sprite->setCoordOriginMode(osg::PointSprite::LOWER_LEFT);
> stateset->setTextureAttributeAndModes(0, sprite,
> osg::StateAttribute::ON);
> 
> auto texture = createTexture(aResourcesPath,
> PointSpriteFileNames.at(aSpriteShape));
> stateset->setTextureAttributeAndModes(0, texture,
> osg::StateAttribute::ON);
> 
> osg::ref_ptr point = new osg::Point();
> point->setSize(aStartingSize);
> point->setMinSize(aMinSize);
> point->setMaxSize(aMaxSize);
> if (aMaxSize > aMinSize)
> {
> point->setDistanceAttenuation(osg::Vec3{1.0f, 0.001f, 0.0f});
> }
> stateset->setAttribute(point);
> }
> 
> inline osg::ref_ptr
> createTexture(const std::string & aResourcesPath, const std::string &
> aImageName)
> {
> const auto imagePath = aResourcesPath + "/images/" + aImageName;
> return new osg::Texture2D(osgDB::readRefImageFile(imagePath));
> }
> 
> 
> 
> 
> Are you aware of any issues with textures point sprites in 3.5.6, or can you
> see what we are doing wrong?
> 
> Thanks,
> 
> Brian[/code]
> 
> --
> Read this topic online here:
> http://forum.openscenegraph.org/viewtopic.php?p=74665#74665
> 
> 
> 
> 
> 
> ___
> 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] OpenSceneGraph-3.6.3 release candidate 2 tagged

[Daniel Emminizer, Code 5773]

Hi Robert,

So far so good here with initial testing.  I had been concerned about Laurens's 
update on text, but it looks like it turned out without problems.  I was able 
to adjust back one of the text scaling options so now we're back to consistent 
between 3.4.1, 3.6.2, and 3.6.3-rc2, with 3.4.1 and 3.6.3-rc2 having identical 
scaling factors.

The mutex change from Glenn appears to have solved an edge case crash we 
independently discovered a couple days ago also.

So far so good.

 - Dan



> -Original Message-
> From: osg-users [mailto:osg-users-boun...@lists.openscenegraph.org] On
> Behalf Of Robert Osfield
> Sent: Tuesday, September 11, 2018 7:36 AM
> To: OpenSceneGraph Users
> Subject: [osg-users] OpenSceneGraph-3.6.3 release candidate 2 tagged
> 
> Hi All,
> 
> I have just tagged the 3.6.3 release candidate 2:
> 
> 
> https://github.com/openscenegraph/OpenSceneGraph/tree/OpenSceneGr
> aph-3.6.3-rc2
> 
> My aim is to tag the 3.6.3 at the end of this week. Please test and
> provide positive/negative feedback via this thread.  :-)
> 
> Cheers,
> Robert.
> 
> -- Changes since 3.6.3-rc1
> 
> Tue, 11 Sep 2018 11:56:04 +0100
> Author : Robert Osfield
> Updated rc number 2 for 3.6.3-rc2
> 
> Tue, 11 Sep 2018 11:29:36 +0100
> Author : OpenSceneGraph git repository
> Merge pull request #620 from LaurensVoerman/txt_SCREEN_COORDSfix
> scale
> problem for osgText with characterSizeMode SCREEN_COORDS and
> _position
> set.
> 
> Tue, 11 Sep 2018 11:23:34 +0100
> Author : Robert Osfield
> Fixed hang using a ReentrantMutex
> 
> Tue, 11 Sep 2018 10:13:49 +0100
> Author : Robert Osfield
> Fixed build
> 
> Tue, 11 Sep 2018 09:31:35 +0100
> Author : Robert Osfield
> Fixed build
> 
> Tue, 11 Sep 2018 09:03:01 +0100
> Author : Robert Osfield
> Cleaned up code
> 
> Mon, 10 Sep 2018 08:00:41 -0400
> Author : gwaldron
> osgText: fixed thread-safety issues in Glyph and Font
> 
> Sat, 8 Sep 2018 18:18:33 +0200
> Author : mp3butcher
> fix examples context creation for X11 (when display not :0.0)
> 
> Tue, 11 Sep 2018 08:34:20 +0100
> Author : OpenSceneGraph git repository
> Merge pull request #619 from mathieu/topic/SaveInlinedImagesAdded
> saving of inline Images without having the physical image file.
> 
> Tue, 11 Sep 2018 08:11:27 +0100
> Author : Robert Osfield
> Added greater control of how cubemap is set up and controlled
> 
> Fri, 7 Sep 2018 15:09:15 +0200
> Author : Laurens Voerman
> fix scale problem for osgText with characterSizeMode SCREEN_COORDS and
> _position set.
> 
> Fri, 7 Sep 2018 14:04:41 +0200
> Author : Mathieu MARACHE
> Added saving of inline Images without having the physical image
> file.The can be read from and inlined image file
> 
> 
> Thu, 6 Sep 2018 12:30:18 +0100
> Author : Robert Osfield
> Merge branch 'OpenSceneGraph-3.6' of
> https://github.com/openscenegraph/OpenSceneGraph into
> OpenSceneGraph-3.6
> 
> Thu, 6 Sep 2018 12:29:44 +0100
> Author : Robert Osfield
> Updated for 3.6.3-rc1
> 
> Thu, 6 Sep 2018 11:50:21 +0100
> Author : Robert Osfield
> Fixed memory leak with assignment of default value to ObjectSerializer
> 
> Wed, 5 Sep 2018 18:06:25 +0100
> Author : OpenSceneGraph git repository
> Merge pull request #616 from
> eligovision/OpenSceneGraph-3.6_particlesParticleSystem: Added support
> for GLES2 and upper (GL_QUADS -> GL_TRI…
> 
> Wed, 5 Sep 2018 18:01:33 +0100
> Author : Robert Osfield
> Fixed copy constructor
> 
> Wed, 5 Sep 2018 19:00:29 +0300
> Author : Konstantin S. Matveyev
> ParticleSystem: Using of GL_TRIANGLES for GLES2 and upper; GL_QUADS
> otherwise
> 
> Wed, 5 Sep 2018 14:04:57 +0100
> Author : OpenSceneGraph git repository
> Merge pull request #617 from aluaces/Image_scaleImage_typoFix typo in
> the initial check of Image::scaleImage().
> 
> Wed, 5 Sep 2018 13:27:35 +0200
> Author : Alberto Luaces
> Fix typo in the initial check of Image::scaleImage().
> 
> Wed, 5 Sep 2018 14:00:09 +0300
> Author : Konstantin S. Matveyev
> ParticleSystem: Added support for GLES2 and upper (GL_QUADS ->
> GL_TRIANGLES)
> 
> Tue, 4 Sep 2018 10:35:38 -0400
> Author : Jason Beverage
> Protect the _programSet in Shader with a mutex. This prevents thread
> safety issues when Shader objects are used in multiple programs.
> 
> Wed, 5 Sep 2018 09:33:24 +0100
> Author : Robert Osfield
> Updated ChangeLog
> 
> Tue, 4 Sep 2018 15:26:30 +0100
> Author : Robert Osfield
> Changed the ShapeDrawable::build() methpd so that it does run when the
> ShadpwDrawabe is a KdTree.
> 
> Tue, 4 Sep 2018 14:13:32 +0100
> Author : Robert Osfield
> Updated SO version as XmlNode::Input changes change the ABI
> 
> Tue, 4 Sep 2018 12:19:14 +0100
> Author : Robert Osfield
> Added support for reading UTF-8 encoded of xml files
> 
> Mon, 3 Sep 2018 12:30:02 +0100
> Author : Robert Osfield
> Changed the logic for whether to call setUpThreading() in
> setThreadingModel() to make it possible to changed threadings even if
> the threading model starts of as SingleThreaded
> ___

Re: [osg-users] Deep cloning an active root scene node

[Daniel Emminizer, Code 5773]

Hi Rob,

Be sure that if you’re using cloning that everything in the scene supports 
cloning.  If you have custom (non-OSG) nodekit elements in the scene, cloning 
may only be partially supported.  That can certainly cause issues with that 
approach.  Though OSG nodes supports cloning, not all custom nodekits 
necessarily implement the copy constructors properly.

- Dan



From: osg-users [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf 
Of Robert Lockyer
Sent: Friday, March 1, 2019 7:56 AM
To: OpenSceneGraph Users 
Subject: Re: [osg-users] Deep cloning an active root scene node

Thanks Robert, that's good advise for a more efficient approach in the long 
term. I just figure it might be a simple proof of concept to just blindly clone 
the whole graph. Sounds like there's no fundamental reason I can't do that, so 
probably just some silly thing I'm getting wrong.

Robert Lockyer
Software Developer
[Image removed by sender.]
Office: 1-709-701-0281
Email: 
robert.lock...@avalonholographics.com


On Fri, Mar 1, 2019 at 8:36 AM Robert Osfield 
mailto:robert.osfi...@gmail.com>> wrote:
Hi Rob,

There is a limit to how well you'll be able to get things to scale given the 
hardware limits you have to work around.  If you don't want the main rendering 
loop to wait for the rendering of all these extra views then you'll need to use 
a separate viewer(or compositeviewer) with it's own threading.  You'll need to 
manage your own frame loops in the secondary viewer.

The only reason to copy data is if it the data is being modified by the 
different threads, I wouldn't recommend avoiding any modifications of the scene 
graph so you can simply share it all without copying.  If there are 
modifications you currently need I would suggest looking at ways to move this 
work elsewhere - often you can move to the GPU and just pass a Uniform per View 
to select the settings that are approriate so the shaders can do the right 
thing.

Cheers,
Robert.


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

This email and any attachments are confidential and may be privileged. Any 
unauthorized use, disclosure, copying or distribution of the information 
received is prohibited. If you are not the intended recipient please contact 
the sender immediately by return email confirming that you have and will delete 
all communications related to the email and any attachments sent to you in 
error.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org