Hi Bastian, On 19 September 2012 10:06, Bastian Rieck <bastian.ri...@iwr.uni-heidelberg.de> wrote: >> It's likely to be a driver bug, or perhaps a sensitivity in the driver >> to the GLSL shaders that are used - sometimes some drivers can be more >> picky than others. > > We also thought about this possibility. Is it possible to obtain debug > information about the way the card processes the shaders?
The OSG is limited to what information it get back from OpenGL to just what the driver provides in the standard OpenGL error/status mechanism, if you set the OSG_NOTIFY_LEVEL env var to DEBUG you'll get the OSG to output the shaders it passing to OpenGL and the errors/status of the compilation and linking, but this is as much as you get. >> I previously worked with an ATI card under Linux >> with osgVolume and didn't have problems so perhaps there has been a >> regression on the driver front. >> >> To investigate further you'll need to see if there are any OpenGL >> errors reported - have a look on the console to see if the OSG has >> picked up on any OpenGL errors. > > Unfortunately, there aren't any errors. Is there anything else we can do > to debug this? We will first check with a modified OSG_NOTIFY_LEVEL, but > what could we do if the drivers turn out to be defective? If using the DEBUG notification doesn't provide any clues then only other tools you have left are 3rd party OpenGL debug tools. Unfortunately AMD have swallowed up glDEbugger so I you options are now a bit more limited. Perhaps others can suggest options. Another route you could possible look at is using a software renderer to see if that reports any errors with the shaders. Robert. _______________________________________________ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
