[osg-users] Regression caused by OSG_PROVIDE_READFILE change

[Robert Osfield]

Hi James,

Sorry to hear there is a regression.  I've looked at your explanation and
the code you linked to, and the relevant osg::StateSet::set*() methods and
can't spot anything obvious wrong.


One debug test would be to write out the subgraph that the CanvasImage
class creates to a .osgt file and then have a look at the results to see if
it makes sense.  You could compare the subgraph generated by the OSG before
OSG_PROVIDE_READFILE change.  If there are differences then it points to an
issue with one of set methods, and potentially even the exact method that
is a problem.

Robert.





On 26 March 2016 at 11:24, James Turner <zakalawe at mac.com> wrote:

> Hello,
>
> I’m seeing a bug with both master
> (c202e4c37276e56caf650684b92a2d83f5dd5a74) and the tip of the 3.4.0 branch
> (f33c58b2f1899b1328b25956ae49e97e6b85097b), where a particular textured
> quad fails to display its texture since the OSG_PROVIDE_READFILE change was
> made.
>
> I’ve done a history bisect to prove to my satisfaction that this change
> caused the problem, and I see there’s been a couple of follow up fixes:
> especially the fix in commit b07cbc2ca8bbb13fa568eb11623aa6fe22479183 from
> Jannik Heller about StateSet setAttributeAndModes.
>
> However even with those fixes applied, I’m still see a white rectangle
> where previously there was a textured rectangle. I’ve verified the
> osg::Image is loaded correctly, and adjusted my code to use ref-ptrs /
> osgDB::readRefImageFile in case this made any difference, but nothing has
> helped so far. The issue is reproducible on at least Windows, Mac and Linux.
>
> I’ve also reviewed the large OSG_PROVIDE_READFILE change, and I don’t see
> any functional changes, especially since I’m using the default value of
> OSG_PROVIDE_READFILE.
>
> My guess is one of the templates added, is causing some alternative code
> path to be taken that’s upsetting something in the image -> texture ->
> stateset logic.
>
> Any debugging / investigation suggestions to figure this out would be most
> appreciated. Unfortunately I don’t have a minimal test case, the code is
> deeply embedded inside FlightGear’s support library, SimGear. You can see
> what I guess are the most relevant part here:
>
>
> https://sourceforge.net/p/flightgear/simgear/ci/next/tree/simgear/canvas/elements/CanvasImage.cxx#l112
>
> https://sourceforge.net/p/flightgear/simgear/ci/next/tree/simgear/canvas/elements/CanvasImage.cxx#l466
>
> Nothing in this file has changed in nearly a year, and works fine with OSG
> 3.2 / prior to the problem commit on the on 3.4.0 branch.
>
> Any help or debugging suggestions gratefully received!
>
> Kind regards,
> James
>
> _______________________________________________
> osg-users mailing list
> osg-users at lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openscenegraph.org/pipermail/osg-users-openscenegraph.org/attachments/20160326/58233209/attachment-0003.htm>