3D Graphics Master Ticket

[Tom Goddard]

3d graphics includes Python objects for shaders, variable bindings, vertex buffers, vertex arrray objects, textures, framebuffers, lights. Basically this is an object oriented wrapping of OpenGL. The current implementation is in hydra/draw/drawing.py. No Chimera 2 directly accesses OpenGL except these objects, so the entire OpenGL use is behind this API. The implementation includes vertex and fragment shaders including many capabilities: 2 lights, depth cue, 2d texturing, instancing with 4x4 matrices, instancing with shift and scale (for spheres), vertex colors, radial warping (oculus rift), texture masking (selection outlines). Additional capabilities for silhouette edges and shadows will be needed. The current code is about 200 lines of shader programs and 1000 lines for OpenGL objects.

Another part of the graphics, as currently implemented in hydra, is a Surface object. All rendering (molecules, maps, volumetric display, surfaces) uses Surface to draw the graphics. It is very similar to the Chimera 1 C++ Surface class, but it is implemented in Python (hydra/surface/surface.py, 600 lines) on top of the OpenGL objects described above. It supports multiple surface pieces. I plan to rename it to something more generic like Drawing and instead of having two levels (Surface and Surface_Piece children), it will allow an arbitrary tree of child nodes. This will support multi-level hierarchical models that we have discussed in Chimera 2 planning meetings. Eventually Drawing will also support drawing text labels. Drawing is basically the scene graph, while the OpenGL objects are lower level and used to render the scene graph.

In addition to the Surface/Drawing there are routines to make basic shapes (spheres, cylinders, splined tubes) and more specialized code to compute molecular surfaces and accessible surface area. These are implemented in hydra/surface. I think they should be part of separate surface project, not part the 3d graphics project. I'll make a separate ticket for that.

[Tom Goddard]

Here's a status update on graphics developments. Since this is an entirely new design of the Chimera graphics we won't really know how adequately it meets our needs until a year or few years pass, and it evolves. It seems unwise to freeze such speculative APIs. So I think the right approach for an initial Chimera 2 release is to consider all graphics APIs private. In other words, extension writers will not be able to develop new rendering styles unless they use private APIs. This does not seem like much of a restrictions as I've never known an outside Chimera 1 developer to implement new rendering code. It is common for developers to need a Surface model API, and unfortunately the Surface API is likely to be essentially the Drawing API from the graphics module. This should be discussed further in the Surface API ticket.

I added a Drawing object which can have Drawing children. A Drawing is a tree structure that can have any depth. This is for support of hierarchical models.

I've added the ability of Drawing to render an outline of a selected subpart. Also added support to pick subobjects, for instance, an atom in a molecule drawing. I've made colors 8-bit red,green,blue,alpha. Not sure if that is best, saves memory, but future graphics may use deeper color bit-depths. The instancing capability to replicated subdrawings at new positions with possibly different colors may or may not be adequate for future needs.

Almost all use of graphics in Hydra is through the Drawing class. It hides all details of rendering (OpenGL buffers and shaders). The graphics that is not part of Drawing that is directly used by Hydra controls what frame buffers to draw to. For instance, in image saving it a request is made to render to an off-screen buffer and then extract the image contents of that buffer.

So almost all the public graphics APIs are methods of the Drawing class. These are in rough shape, lacking a systematic approach for when to use attributes and when to use methods (for example, for vertex colors, or arrays of triangles).

[Tom Goddard]

No longer using "master" tickets. Instead use individual tickets for specific features.