-1,-1 has always worked for me in the typical case, and the OpenFlight setting is excessive for the typical case. In the typical case, your geometry is near the origin.
In an atypical case, imagine two coplanar polygons with an arbitrary (non-axis aligned) orientation and a heterogeneous set of vertices, and located so far from the origin that single-precision IEEE float becomes an issue (xyz coords are in the 5-digit range, for example). In this case, you'd need a much larger <scale,bias> pair to resolve the coplanarity. If the magnitude of the xyz vertices is even larger, PolygonOffset becomes pretty much unusable. I saw the excessive values in the OpenFlight loader a long time ago, and I remember some discussion regarding this atypical case, which is actually quite common in OpenFlight terrain databases modeled in UTM coordinates. As a solution, I'd suggest adding an Option to control whether the importer handles subfaces using PolygonOffset (with -1,-1) or stencil. Maybe another Option to toggle use of the backwards-compatible -10,-40 setting? Or, more forward-looking, is there an elegant way to draw coplanar polys using a shader? Regarding the exporter, it currently writes subfaces if it detects use of PolygonOffset, so it would require some work to also look for stencil. Paul Martz Skew Matrix Software LLC http://www.skew-matrix.com +1 303 859 9466 -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Robert Osfield Sent: Thursday, April 23, 2009 6:17 AM To: OpenSceneGraph Users Subject: [osg-users] OpenFlight, subsurfaces and PolygonOffset settings Hi OpenFlight users, I had a support email this morning that led me to investigate problems with the way the OSG's present OpenFlight plugin handles subsurfaces. The particular problem observed was that a road that had been modelled in creator was clipping out vehicles on top of the road. I investigated and found out that the OpenFlight loaded was created used code from src/osgPlugins/OpenFlight/GeometryRecords.cpp: 386 static osg::ref_ptr<osg::PolygonOffset> polygonOffset = new osg::PolygonOffset(-10.0f, -40.0f); 387 stateset->setAttributeAndModes(polygonOffset.get(), osg::StateAttribute::ON); 388 389 static osg::ref_ptr<osg::Depth> depth = new osg::Depth(osg::Depth::LESS, 0.0, 1.0,false); 390 stateset->setAttribute(depth.get()); The use of static vars was a bit dodgy so I replaced these with variables stored in Document, but this is really just an side show to the real problem - the excessive PolygonOffset settings, a factor of -10, and units -40 is very aggressive a setting pushing out the subsurfaces way further than is either necessary or safe. Scaling these values back to -1, -1 resulted in my better results on the models I have without causing problems with the subsurfaces having z fighting. -1, -1 may be too conservative though. I'd like to get feedback from the community on what works for your OpenFlight models. I've checked in my changes into svn/trunk and the OSG-2.8 branch. It'd be useful to import OpenFlight models and convert to .osg or .ive and then update the OSG version + compile it, then redo the conversion, then compare the before and after results. As an another little aside, in testing on my ATI card I found that the original hack that was introduced into osg::PolygonOffset, to try and cope with implementations differences of glPolygonOffset between ATI and NVidia, now is doing more harm than good. Commenting out this hack so that glPolygonOffset values are passed identically produces the best results for me. I never got to try out the hack first hand before I got this ATI card, and I never got really definitive feedback on how the previous settings were working. It does seem appropriate to now revert this old hack though, looks like ATI cards/drivers are behaving much more similar to NVidia now which is a good thing. On all these counts I really like feedback. Was sub surfaces working OK for you prior to my changes today, or do todays changes improve things? Robert. _______________________________________________ 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
