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

Please test OpenSceneGraph-3.6 branch in prep for 3.6.1

Goto page 1, 2  Next
 
Post new topic   Reply to topic    OpenSceneGraph Forum Forum Index -> General
View previous topic :: View next topic  
Author Message
robertosfield
OSG Project Lead


Joined: 18 Mar 2009
Posts: 12024

PostPosted: Fri Apr 20, 2018 2:58 pm    Post subject:
Please test OpenSceneGraph-3.6 branch in prep for 3.6.1
Reply with quote

Hi All,

I have made several bug fixes and other improvements to the 3.6 branch
since the 3.6.0 stable release a couple of weeks ago and now feel that
they are worthwhile rolling into a 3.6.1 stable release so that all
users get to benefit from them.

The key changes I have made are:

1) Fix a bug where the OSG was creating VBO's within Display Lists
(caused a crash on a particular driver.)

2) Fix a bug in osg::Geometry::set*Binding() where it wasn't
assigning a BufferObject when it should have (this caused a
performance regression and crash with VAO usage.)

3) Replaced all remaining IntersectVisitor (which has been
deprecated for many years) usage with the modern IntersectionVisitor
and made the deprecated messages clearer in
include/osgUtil/IntersectVisitor. (In OSG master I've removed this
old class completely.)

4) Changed places that invoked the old osgUtil::TriStripVisitor so
that they use the
osgUtil::MeshOptimizers instead as these work far better when using
VBO/VAO's. (In OSG master I also completely removed TriStripVisitor.)

I don't expect my changes to break the build, but it's still not safe
enough for me to tag 3.6.1 straight without getting some community
feedback, so here I am again asking members of the community to check
out the OpenSceneGraph-3.6 branch from github and tests the build and
runtime on your build tools.

If you are using OSG master then there is chance that your build will
break if you use the old IntersectVisitor and TriStripVisitor classes,
but then that's good, you should have rewritten you code long ago so
now you have a reason to make the required improvements :-)

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

Cheers,
Robert.

ChangeLog since 3.6.0

Fri, 20 Apr 2018 14:32:34 +0100
Author : Robert Osfield
Replaced osgUtil::IntersectVisitor usage with osgUtil::InteresectionVisitor

Fri, 20 Apr 2018 10:24:17 +0100
Author : Robert Osfield
Removed TriStripVisitor for default set of Optimizer passes as it
doesn't generate efficient scene graphs

Fri, 20 Apr 2018 09:57:04 +0100
Author : Robert Osfield
Added osgUtil::optimizeMesh(osg::Node* node) convinience method

Fri, 20 Apr 2018 11:42:31 +0100
Author : Robert Osfield
Removed usage of the osgUtil::TriStripVisitor is it generates
osg::Geometry that perform very poorly when using VBO and VAO's vs GL
DisplayLists. With DisplayLists being deprecated in GL and VBO and VAO
becoming standard it's best to standardize on using the
osgUtil::MeshOptimizers instead of TripStrupVisitor

Thu, 19 Apr 2018 19:43:14 +0100
Author : Robert Osfield
Fixed the set*Binding() methods so that they assign BufferObjects when required

Thu, 19 Apr 2018 19:42:51 +0100
Author : Robert Osfield
Fixed messages

Thu, 19 Apr 2018 19:41:51 +0100
Author : Robert Osfield
Fixed the GLBufferObject size computation so that it takes into account padding.

Thu, 19 Apr 2018 19:36:19 +0100
Author : Robert Osfield
Replaced the use of osgUtil::TriStripVisitor with
ogUtil::MeshOptimizer usage to improve performance. Fixed set
setColorArray assignement to pass in the color binding

Wed, 18 Apr 2018 10:02:43 +0100
Author : Robert Osfield
Fixed the handle of boundary equalization

Wed, 18 Apr 2018 09:33:12 +0100
Author : Robert Osfield
Added --equalize-boundaries -e command line option to call
terrain->setEqualizeBoundaries(true)

Mon, 16 Apr 2018 17:53:38 +0100
Author : Robert Osfield
Updated version number in prep for future 3.6.1 release.

Mon, 16 Apr 2018 15:08:24 +0100
Author : Robert Osfield
Fixed inline Drawable::draw(..) method

Mon, 16 Apr 2018 15:05:11 +0100
Author : Robert Osfield
Fixed Geometry::drawImplmentation() handling of VBO's to prevent them
from being used when display lists are used.

Sun, 15 Apr 2018 08:25:57 +0100
Author : Robert Osfield
Replaced osgViewer::GraphicsWindow dynamic_cast as it's not neccessary.


------------------
Post generated by Mail2Forum
Back to top
View user's profile Send private message
Daniel Emminizer, Code...
Guest





PostPosted: Mon Apr 23, 2018 2:26 pm    Post subject:
Please test OpenSceneGraph-3.6 branch in prep for 3.6.1
Reply with quote

Hi Robert,

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

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




------------------
Post generated by Mail2Forum
Back to top
Terry Welsh
Guest





PostPosted: Mon Apr 23, 2018 3:12 pm    Post subject:
Please test OpenSceneGraph-3.6 branch in prep for 3.6.1
Reply with quote

Quote:

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


Robert,
Using the 3.6.0 tag I have crashes whenever an osgText::Text appears
on screen in my application. The osgtext example just doesn't show
anything at all and crashes when I press Esc. No problems with
osgText::Text3D or anything else so far. These problems occur when
compiling with Visual Studio Community 2017 on Win7. I have not had
any problems compiling with MS Build Tools on Win10 or any problems on
Fedora or Ubuntu. Last night while I was sleeping I compiled a debug
build of 3.6.0, and I'll try to look at it tonight. Do you think any
of the bug fixes you already made would affect this?

By the way, the new shaderized Text outlines are very pretty.
- Terry


------------------
Post generated by Mail2Forum
Back to top
robertosfield
OSG Project Lead


Joined: 18 Mar 2009
Posts: 12024

PostPosted: Mon Apr 23, 2018 3:26 pm    Post subject:
Please test OpenSceneGraph-3.6 branch in prep for 3.6.1
Reply with quote

Hi Terry,

On 23 April 2018 at 16:12, Terry Welsh <> wrote:
Quote:
Using the 3.6.0 tag I have crashes whenever an osgText::Text appears
on screen in my application. The osgtext example just doesn't show
anything at all and crashes when I press Esc. No problems with
osgText::Text3D or anything else so far. These problems occur when
compiling with Visual Studio Community 2017 on Win7. I have not had
any problems compiling with MS Build Tools on Win10 or any problems on
Fedora or Ubuntu. Last night while I was sleeping I compiled a debug
build of 3.6.0, and I'll try to look at it tonight. Do you think any
of the bug fixes you already made would affect this?

You are the first to report a crash with osgText, so what you find
with your debug version of the OSG will be invaluable.

What graphics hardware are you working with?

I don't think the fixes I made to the OpenSceneGraph branch will fix
anything related to your crash, but you never know we might get lucky
:-)

FYI. the new osgText::Text implementation uses shaders to it's work,
in theory it shouldn't do anything radical without checking the
available functionality, but perhaps your driver/hardware aren't
handled well.

Quote:
By the way, the new shaderized Text outlines are very pretty.

That was key deliverable for this work so it's good to hear that you
are seeing an improvement.

Robert.


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


Joined: 18 Mar 2009
Posts: 12024

PostPosted: Mon Apr 23, 2018 6:59 pm    Post subject:
Please test OpenSceneGraph-3.6 branch in prep for 3.6.1
Reply with quote

HI Daniel,

On 23 April 2018 at 15:25, Daniel Emminizer, Code 5773
<> wrote:
Quote:
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.

I am not at my dev system right now so can't do a review of the
possible consequences but as a first pass your suggestion sounds
reasonable.


Quote:
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.

The alpha blending is done in the shader now, all done in the shader
to improve the visual quality of outline and drop shadows. I
developed it across a range of fonts and sizes. If there are
particular fonts and sizes that aren't working well then the shaders
may need to be revised.

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.


Quote:
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.

Away from my dev machine I can't provide a answer as I'll need to look
at the C++ code to provide a definitive answer. Perhaps a recent bug
fix to handle issue with text bounding boxes more robustly has changed
things for your particular usage case. Essentially I had to decouple
of the Drawable bounding box from the inner text bounding box so that
outlines and drop shadows didn't causes growth in the overall bounding
box when updating text repeatedly.

Quote:
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).

The crosshair is really just a debug reference added by a contributor
in the early days of osgText. It isn't a proper feature that I would
expect to be used in a live application. Given it's just a debug
feature it only using the inner text bounding box is OK with me.

Robert.


------------------
Post generated by Mail2Forum
Back to top
View user's profile Send private message
Daniel Emminizer, Code...
Guest





PostPosted: Mon Apr 23, 2018 7:46 pm    Post subject:
Please test OpenSceneGraph-3.6 branch in prep for 3.6.1
Reply with quote

Hi Robert,

Quote:
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.


Quote:
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.


Quote:
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




------------------
Post generated by Mail2Forum
Back to top
robertosfield
OSG Project Lead


Joined: 18 Mar 2009
Posts: 12024

PostPosted: Tue Apr 24, 2018 11:22 am    Post subject:
Please test OpenSceneGraph-3.6 branch in prep for 3.6.1
Reply with quote

Hi Daniel,

On 23 April 2018 at 20:46, Daniel Emminizer, Code 5773
<> wrote:
Quote:
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.



------------------
Post generated by Mail2Forum
Back to top
View user's profile Send private message
Daniel Emminizer, Code...
Guest





PostPosted: Tue Apr 24, 2018 11:42 am    Post subject:
Please test OpenSceneGraph-3.6 branch in prep for 3.6.1
Reply with quote

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:] On Behalf Of Robert Osfield
Sent: Tuesday, April 24, 2018 7:22 AM
To: OpenSceneGraph Users
Subject: Re: 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:
Quote:
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.


------------------
Post generated by Mail2Forum
Back to top
robertosfield
OSG Project Lead


Joined: 18 Mar 2009
Posts: 12024

PostPosted: Tue Apr 24, 2018 3:28 pm    Post subject:
Please test OpenSceneGraph-3.6 branch in prep for 3.6.1
Reply with quote

Hi Dan et. al,

Quote:
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.

After merging your change I had a further think about the issue and
decided that using CMake would be better so have checked in the
commit:

https://github.com/openscenegraph/OpenSceneGraph/commit/1aa0a80de7f0afeb044098637216a80752e4ab07

I have done a few tests and things look to be working OK, would
appreciate others to test and make sure it's working fine.

Cheers,
Robert.


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


Joined: 18 Mar 2009
Posts: 12024

PostPosted: Tue Apr 24, 2018 3:54 pm    Post subject:
Please test OpenSceneGraph-3.6 branch in prep for 3.6.1
Reply with quote

Hi Dan,

On 23 April 2018 at 20:46, Daniel Emminizer, Code 5773
<> wrote:
Quote:
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 tracked this down to the bounding box computation using the average
glyph width into account when accounting for the shadow size, as the
average size changes when you change the text the size of the bb
changed a bit. The left hand position was also affected by the glyphs
which was also contributing to this issue.

I have checked in changes to address these two issues.

--

I believe that the changes to osgText for bounding box and shaders,
and the CMakeLists.txt support for setting the glContexVersion should
address the issues you've reported. Could you test out OSG 3.6 branch
and let me know how you get on.

Thanks,
Robert.


------------------
Post generated by Mail2Forum
Back to top
View user's profile Send private message
Terry Welsh
Guest





PostPosted: Wed Apr 25, 2018 3:10 pm    Post subject:
Please test OpenSceneGraph-3.6 branch in prep for 3.6.1
Reply with quote

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 Razz Sorry for the false alarm.
- Terry

P.S. Buy NVidia graphics.

Quote:

Hi Terry,

On 23 April 2018 at 16:12, Terry Welsh <> wrote:
Quote:
Using the 3.6.0 tag I have crashes whenever an osgText::Text appears
on screen in my application. The osgtext example just doesn't show
anything at all and crashes when I press Esc. No problems with
osgText::Text3D or anything else so far. These problems occur when
compiling with Visual Studio Community 2017 on Win7. I have not had
any problems compiling with MS Build Tools on Win10 or any problems on
Fedora or Ubuntu. Last night while I was sleeping I compiled a debug
build of 3.6.0, and I'll try to look at it tonight. Do you think any
of the bug fixes you already made would affect this?

You are the first to report a crash with osgText, so what you find
with your debug version of the OSG will be invaluable.

What graphics hardware are you working with?

I don't think the fixes I made to the OpenSceneGraph branch will fix
anything related to your crash, but you never know we might get lucky
:-)

FYI. the new osgText::Text implementation uses shaders to it's work,
in theory it shouldn't do anything radical without checking the
available functionality, but perhaps your driver/hardware aren't
handled well.

Quote:
By the way, the new shaderized Text outlines are very pretty.

That was key deliverable for this work so it's good to hear that you
are seeing an improvement.

Robert.


------------------
Post generated by Mail2Forum
Back to top
Daniel Emminizer, Code...
Guest





PostPosted: Wed Apr 25, 2018 3:23 pm    Post subject:
Please test OpenSceneGraph-3.6 branch in prep for 3.6.1
Reply with quote

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:] On Behalf Of Terry Welsh
Sent: Wednesday, April 25, 2018 11:10 AM
To:
Subject: Re: 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 Razz Sorry for the false alarm.
- Terry

P.S. Buy NVidia graphics.



------------------
Post generated by Mail2Forum
Back to top
robertosfield
OSG Project Lead


Joined: 18 Mar 2009
Posts: 12024

PostPosted: Wed Apr 25, 2018 4:41 pm    Post subject:
Please test OpenSceneGraph-3.6 branch in prep for 3.6.1
Reply with quote

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.



On 25 April 2018 at 16:23, Daniel Emminizer, Code 5773
<> wrote:
Quote:
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:] On Behalf Of Terry Welsh
Sent: Wednesday, April 25, 2018 11:10 AM
To:
Subject: Re: 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 Razz Sorry for the false alarm.
- Terry

P.S. Buy NVidia graphics.




------------------
Post generated by Mail2Forum
Back to top
View user's profile Send private message
Daniel Emminizer, Code...
Guest





PostPosted: Wed Apr 25, 2018 4:59 pm    Post subject:
Please test OpenSceneGraph-3.6 branch in prep for 3.6.1
Reply with quote

Hi Robert,

Quote:
Head in hands moment...

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

Quote:
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:] On Behalf Of Robert Osfield
Sent: Wednesday, April 25, 2018 12:41 PM
To: OpenSceneGraph Users
Subject: Re: 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.




------------------
Post generated by Mail2Forum
Back to top
robertosfield
OSG Project Lead


Joined: 18 Mar 2009
Posts: 12024

PostPosted: Wed Apr 25, 2018 6:55 pm    Post subject:
Please test OpenSceneGraph-3.6 branch in prep for 3.6.1
Reply with quote

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

On 25 April 2018 at 17:59, Daniel Emminizer, Code 5773
<> wrote:
Quote:
Hi Robert,

Quote:
Head in hands moment...

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

Quote:
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:] On Behalf Of Robert Osfield
Sent: Wednesday, April 25, 2018 12:41 PM
To: OpenSceneGraph Users
Subject: Re: 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.





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

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

Similar Topics
Topic Author Forum Replies Posted
No new posts OpenSceneGraph BOF, Siggraph 2018 is ... robertosfield General 1 Tue Aug 14, 2018 3:00 pm View latest post
No new posts How I build OpenSceneGraph manually f... kornerr General 0 Tue Aug 14, 2018 11:51 am View latest post
No new posts OpenSceneGraph-3.6.2 released! robertosfield General 0 Fri Jun 29, 2018 10:28 am View latest post
No new posts OpenSceneGraph-3.6.2 release candidate 3 robertosfield General 1 Thu Jun 28, 2018 6:35 am View latest post
No new posts OpenSceneGraph-3.6.2 release candidat... robertosfield General 0 Wed Jun 27, 2018 8:24 am View latest post


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