<div dir="ltr"><div><div>Hi James,<br><br></div>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.<br><br><br></div><div>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.<br><br></div><div>Robert.<br></div><div><br><br><br><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On 26 March 2016 at 11:24, James Turner <span dir="ltr"><<a href="mailto:zakalawe@mac.com" target="_blank">zakalawe@mac.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hello,<br>
<br>
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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
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:<br>
<br>
<a href="https://sourceforge.net/p/flightgear/simgear/ci/next/tree/simgear/canvas/elements/CanvasImage.cxx#l112" rel="noreferrer" target="_blank">https://sourceforge.net/p/flightgear/simgear/ci/next/tree/simgear/canvas/elements/CanvasImage.cxx#l112</a><br>
<a href="https://sourceforge.net/p/flightgear/simgear/ci/next/tree/simgear/canvas/elements/CanvasImage.cxx#l466" rel="noreferrer" target="_blank">https://sourceforge.net/p/flightgear/simgear/ci/next/tree/simgear/canvas/elements/CanvasImage.cxx#l466</a><br>
<br>
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.<br>
<br>
Any help or debugging suggestions gratefully received!<br>
<br>
Kind regards,<br>
James<br>
<br>
_______________________________________________<br>
osg-users mailing list<br>
<a href="mailto:osg-users@lists.openscenegraph.org">osg-users@lists.openscenegraph.org</a><br>
<a href="http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org" rel="noreferrer" target="_blank">http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org</a><br>
</blockquote></div><br></div>