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 <[email protected]> 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 > [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
