Faster atom sphere rendering with OpenGL impostors

[Tom Goddard]

We could get much higher performance and higher quality at the same time in atom sphere rendering by using graphics "impostors". Basically just a square is rendered for each sphere and a special shader computes the z height to make a sphere and tosses out the pixels outside a circle and computes normal vectors. Currently for large models (more than 500,000 atoms) we use poor quality 20 triangle icosahedron approximation to a sphere, for fewer atoms we use 80 or 320 triangle subdivisions for each sphere. By comparison an impostor uses only 2 triangles per sphere and gets pixel level quality. Using impostors would eliminate the need for level of detail changes when zooming (as done in Chimera 1) for spheres. Cylinders can also be done with impostors but the code is more complex and the number of triangles used for non-impostor rendering is not nearly so large as with spheres.

A serious limitation to consider is that an impostor won't handle perspective projection correctly. An impostor always shows a half sphere rendered on a square facing the camera. But with perspective projection of a close sphere less than half a sphere is visible (the part in a view cone from camera to sphere edge), and the perspective sphere is wider (in view angle) than what is shown by an impostor (hemisphere equator). These effects may be negligible in most cases, but certain cases like immersive rendering with Oculus Rift stereo goggles where close spheres are common may work poorly.

[Tom Goddard]

It appears not too complex to handle perspective rendering of sphere impostors, perhaps doubling the code complexity and number of shader program lines.

[Tom Goddard]

It is not clear without testing how much faster impostor rendering of spheres will be. A substantial drawback is that early fragment rejection optimization using depth test will not be done if the compiled fragment shader modifies fragment depths. Often complex scenes of tens or hundreds of layers that can be rejected by early depth test. Without that, the lighting and textures lookups (e.g. shadows,...) may all be done on all the hidden atom spheres. I say "may" because the graphics driver shader language compiler may be able to analyze the fragment shader and immediately after the depth is set to an early depth test before lighting and texture calculations are done, avoiding those calculations for the occluded fragments which are the vast majority. Even without that optimization my shader code can possibly do an explicit depth test and discard the fragment as soon as the depth as set. I say "possibly" because I don't know whether an OpenGL fragment shader can access the current depth buffer value. Further research and testing would be needed to understand the performance implications.