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

[Robert Osfield]

HI Daniel,

On 23 April 2018 at 15:25, Daniel Emminizer, Code 5773
<dan.emminizer at nrl.navy.mil> wrote:
> 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.


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


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

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