?While working with the OpenSceneGraph rendering engine I needed to test the possibility of using “true transparency” via Depth Peeling algorithm (here’s the PDF document for more details). Unfortunately it uses several non-common OpenGL extensions that may be unavailable on some graphic cards. Trying to perform DP on those cards causes application to crash and to turn DP off on unsupported hardware some checks need to be done. So how to make it more stable and enable Depth Peeling only on supported hardware?

Following extensions need to be supported by your graphic adapter:

  • GL_ARB_depth_texture or OpenGL>=1.4
  • GL_ARB_shadow or OpenGL>=1.4
  • GL_EXT_shadow_funcs or OpenGL>=1.5
  • GL_ARB_vertex_shader or OpenGL>=2.0
  • GL_ARB_fragment_shader or OpenGL>=2.0
  • GL_ARB_shader_objects or OpenGL>=2.0
  • GL_ARB_occlusion_query or OpenGL>=1.5
  • GL_ARB_multitexture or OpenGL>=1.3
  • GL_ARB_texture_rectangle
  • GL_SGIS_texture_edge_clamp orĀ GL_EXT_texture_edge_clamp or OpenGL>=1.2

When using OSG it is not necessary to perform direct OpenGL calls as far as OSG has own wrappers. To check GL extensions you can use the following function:

bool osg::isGLExtensionSupported(contextID, extensionName);

You will probably want to check all those things on application startup or something like that, but using the GL context of your OSG viewer instance. Beware: the context is not valid outside the OSG frame loop. However guys from OSG users mailing list suggest to avoid doing OpenGL calls directly in the frame loop, and instead use a Camera initial/pre/post/final draw callback to do extra OpenGL calls. This approach works for all threading models and viewer configurations. It works indeed, but in my case we need to perform the checks only once on startup, so while this solution is working it has some overhead. I wonder if we will have to create another GL context just to perform this operation without using OSG? Uh, what a bother…