[osg-users] Regression caused by OSG_PROVIDE_READFILE change

James Turner zakalawe at mac.com
Sat Mar 26 04:24:24 PDT 2016


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:


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,

More information about the osg-users mailing list