Re: [osg-users] OpenFlight, subsurfaces and PolygonOffset settings
Hi Robert, I have seen this problem (in my case manifested by having the road draw on top of buildings (!) next to the road) in OSG 2.6 so I am glad to know it is a bug in the OpenFlight loader. In my application, I have had success with osg::PolygonOffset(1.0f, 4.0f) to push the terrain below the roads (rather than the roads above the terrain; I thought I read somewhere that negative values in glPolygonOffset are not allowed but I guess I was mistaken). I presume that osg::PolygonOffset(-1.0f, -4.0f) applied to the roads would produce the same effect. I also have the roads in a separate render bin that renders after the terrain and set the depth test function on roads to be LEQUAL instead of LESS to ensure that z buffer ties are broken in the favor of the road surface. - Peter Robert Osfield wrote: 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_ptrosg::PolygonOffset polygonOffset = new osg::PolygonOffset(-10.0f, -40.0f); 387 stateset-setAttributeAndModes(polygonOffset.get(), osg::StateAttribute::ON); 388 389 static osg::ref_ptrosg::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 osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OpenFlight, subsurfaces and PolygonOffset settings
Hi, On Thursday 23 April 2009 14:16, Robert Osfield wrote: 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. Hmm, I remember that thing. There were some subtle problems with a ATI card where this scaling factors were introduced. My personal feeling at that point in time was that this was a singular bug in the fglrx driver at that time. Solving that a temporary driver problem with a persistent scaling factor is IMO something we should rethink. I personally have resetted *all* these factors explicitly to 1 in *every* application I have some revision control access for - including flightgear. Also note that I do work on ATI gpu's on a regular basis without any problems with these factors equal to one and with huge z buffer problems with the defaults. Greetings Mathias -- Dr. Mathias Fröhlich, science + computing ag, Software Solutions Hagellocher Weg 71-75, D-72070 Tuebingen, Germany Phone: +49 7071 9457-268, Fax: +49 7071 9457-511 -- Vorstand/Board of Management: Dr. Bernd Finkbeiner, Dr. Roland Niemeier, Dr. Arno Steitz, Dr. Ingrid Zech Vorsitzender des Aufsichtsrats/ Chairman of the Supervisory Board: Michel Lepert Sitz/Registered Office: Tuebingen Registergericht/Registration Court: Stuttgart Registernummer/Commercial Register No.: HRB 382196 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OpenFlight, subsurfaces and PolygonOffset settings
-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: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] 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_ptrosg::PolygonOffset polygonOffset = new osg::PolygonOffset(-10.0f, -40.0f); 387 stateset-setAttributeAndModes(polygonOffset.get(), osg::StateAttribute::ON); 388 389 static osg::ref_ptrosg::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 osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OpenFlight, subsurfaces and PolygonOffset settings
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 pma...@skew-matrix.com 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: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] 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_ptrosg::PolygonOffset polygonOffset = new osg::PolygonOffset(-10.0f, -40.0f); 387 stateset-setAttributeAndModes(polygonOffset.get(), osg::StateAttribute::ON); 388 389 static osg::ref_ptrosg::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 osg-users@lists.openscenegraph.org http
