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 <[email protected]> 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 > [email protected] > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org > _______________________________________________ osg-users mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
