[osg-users] Text Bounding Box Calculation

[Robert Osfield]

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.

On 14 May 2018 at 16:02, Daniel Emminizer, Code 5773
<dan.emminizer at nrl.navy.mil> wrote:
> 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
>
>
> _______________________________________________
> osg-users mailing list
> osg-users at lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>