Recent changes to how VisIt utilizes OpenGL have prompted concerns over how we initialize GL contexts. Further, overhauling how our mappers end up accessing OpenGL is highly desired for performance reasons. Finally, creating a new plot seems unnecessarily difficult for some cases.
Summary of 8/13 phone call
Our phone call was organized by Tom and held on Thursday, 8/13. The call started with a summarization of GLEW issues/mangled mesa issues and then opened up to a discussion of wish list rendering overhauls.
Summary of GLEW/mangled mesa issues
- We decided that we want to have -nowin always do SR saves. This opens up the possibility of having different behavior between on-screen and off-screen saves (because the viewer's rendering path may be different than the engine's), but this simplifies our rendering environment.
- The problem of initialization was discussed but not necessarily resolved. There is consensus that the current location for initialization (the mappers) is a hack and generally undesirable. The desire is to use something similar to Qt's
initializeGLfunction, but there is doubt whether VTK has an analogous function.
- In the past, we've had numerous problems making a non-screen-capture based save (e.g. SR mode) to match what is being seen on the screen. Getting aspect ratio right is one of those problems. There maybe others, particularly with annotations as I don't think we do any annotation rendering on the engine (e.g. in SR). If we do away with screen capture based save's, we need to ensure all these issues are resolved.
- Current plans are to inherit from VTK's render window and force our GLEW initialization in at the proper time.
- The eventual plan is to get GLEW changes merged upstream. Progress of this is tracked on the Parallel OpenGL
Summary of rendering wish list discussions
Please list the topic you represented is this section.
There was interest expressed in moving to more modern ways of rendering with OpenGL. Specifically, the use of vertex arrays and similar OpenGL features was touted as a way to improve rendering times on modern architectures.
It seems as if this interest will be served by upgrading to a later VTK release.
Uniformity in GUI
Hank (and Sean and presumably others) would like for each plot window to have a tab that deals with rendering basics. For example, line widths, point glyphs, etc. Brad mentioned that Mark was working on inheriting state objects and that sounds like it fits well into this. This would also be useful for integration with ray tracing when it is ready.
Promote Custom Renderer
Abstract code necessary to create custom renderers into a base class where it can be reused for future custom renderers.
[MCM] I'll take a stab at paraphrasing what I thought Jeremy was meaning when he said the only time you should have to create a new plot type is when indeed you do need a new renderer. What I think this means is that we should decouple the acts of producing geometric primitives to render (points, lines, polygons, splats, etc.) and the acts of attributing those primitives with visual properties things like color, color-by-variable, transparency, texture, glyph-type/orientation/scaling, etc. and provide GUI/CLI means to control both, independently. That is the user both selects the mechanism (specifically avoiding operator or plot to avoid confusion) by which one obtains primivites from the input database (e.g. external surface -- used for PC plot, iso-surface, stream-tube, slice, clip) and then makes a separate selection by which those primitives are attributed with visual properties for rendering.
We color materials using different colors in the Boundary plots. VisIt's metadata permits each material to have an associated material color. It would be nice if we could extend this to be a set of material properties (colors, shininess, refractiveness, etc.). We could then enhance various mappers to take advantage of material properties to influence how we draw each material's geometry. For example, this could allow for:
- plastic-looking parts and metallic-looking parts in the same plot.
- The ray tracer could use material properties to render plots more physically correct.
- Mappers could use material properties to draw procedural textures onto geometry in plots like FilledBoundary.
VisIt provides a very simple coordinate system. It would be nice if we could support more coordinate systems such as map projections or lat/lon coordinates. This might all be implemented with vertex programs that apply coordinate transforms on the fly as the data are rendered. This approach could probably be used to implement a 3D fullframe mode where all relevant coordinate arrays remain unchanged in VisIt, leaving the axes with the right values, but are transformed into a cube shape for rendering. This would improve rendering for objects with high aspect ratios.
Direct Rendering of CSG
Currently, VisIt handles Constructive Solid Geometry (CSG) by discretizing to UCDmesh in transform manager. It would be really nice if we could pass CSG direct to GPU and have it rendered automaagically there. I think there are gl libraries that do this so maybe all this is is a custom renderer.