Hi Paul, I do wonder if the right way to solve subsurfaces is modify the underlying geometry so it shares the same vertices as the subsurface, and then insert any vertices of the underlying geometry into the subsurface geometry, then render with the depth test to pass when fragments are less than or equal to the existing fragment. Or perhaps even better just automatically cut out the underlying geometry. This obviously requires more work from the loader, but it would be far more robust in terms of handling large/small models.
Robert. On Thu, Apr 23, 2009 at 2:55 PM, Paul Martz <[email protected]> wrote: > -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 > _______________________________________________ osg-users mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
