Difference between revisions of "Rendering Infrastructure"

From VTKM
Jump to navigation Jump to search
Line 56: Line 56:
  
 
There are others as well: VR for volume rendering, and a SimpleRT for unoptimized ray tracing, both of which keep their own internal pixel buffer.
 
There are others as well: VR for volume rendering, and a SimpleRT for unoptimized ray tracing, both of which keep their own internal pixel buffer.
 +
 +
'''''Window'''''
 +
 +
# eavl1DWindow, eavl2DWindow, and eavl3DWindow are all similar.  They initialize viewports and can render any window-specific annotations.  These also handle legends. Right now, the 2D and 3D windows will make a colortable annotation from the first plot.  The 1D window will create a solid block color table suitable for a plot with lots of curves (e.g. labeling red as "A" and green as "B").
 +
 +
'''''Scene'''''
 +
 +
# Base class only.
 +
 +
'''''Plot'''''
 +
 +
# eavlPlot is the base class and gets things set up for rendering, like finding the right field pointers and extracting data and spatial extents.  It also handles transforms like polar.
 +
 +
# eavl1DPlot is the only specialization; instead of mapping all coordinates fields to spatial coordinates, it treats the first coordinate as X and one of the FIELD values as Y.  It can also handle e.g. "bar" plots.

Revision as of 13:30, 8 December 2015

Under Construction

This will be a design document which describes the major features (and likely the non-features or anti-features) of a rendering infrastructure which allows VTK-m to function as a standalone library which can output images. Given that algorithms like ray casting and volume rendering can be highly data-parallel and are being implemented using VTK-m algorithms, it makes sense to hook these up to a basic infrastructure which can output these results.

(Note that this will start as a description of the EAVL rendering infrastructure, but will evolve to a VTK-m specific design, which can then be implemented as a modification of EAVL's.)

Goals

Implementation Considerations

Compilation

Anything potentially OpenGL- or Mesa-dependent must be defined in header files only. We do not want to deal with mangling, or multiple-linkage issues in or required by our library.

Fonts

No explicit third-party dependencies means any annotation must be self-contained. Initially, this means bitmap fonts. For EAVL, I used Liberation 2.0 fonts. These are licensed under the SIL Open Font License. The former 1.x series Liberation fonts have licensing problems. In particular, EAVL contains Liberation 2 Mono, Sans, and Serif as bitmap fonts along with spacing metrics. For the ASCII character set, these files take 500KB each as source, and 160KB each as object files. (I.e., multiply these sizes by 3x if you want to include all three fonts, so about half a megabyte in final binary form for all three.)

Design and Usage

Main Classes

Render Surface: This is the output target like an OpenGL context or a PostScript file. It also handles any image-space annotations, like colorbars or 2D axis bars/text and chart titles, and it knows how to configure the target transformations for image- or screen-space. It can also save itself (and all of its contents) to an image or raster file, depending on its type.

World Annotator: This handles annotations in "world" or "scene" space, like pick point letters, 3D axes/text, or other callouts pointing to or relative to scene geometry.

Scene Renderer: This handles the mapping of scene geometry into something the render surface understands (like pixels or postscript commands). It has a default implementation which can turn datasets into ONLY points, line segments, triangles, and tetrahedrons. Derived classes can override at one of two points: drawing a whole 1D/2D/3D data set, or handling individual primitives as decomposed by the base class. It also has default implementation for primitive drawings to map all primitives down to a single type, e.g. it will map any triangle (whether it has node/cell/no normals and node/cell/no scalars) into a triangle with node normals and node scalars.

Window: This handles setting up the viewport and annotations specific to a type of window (like 2D, 3D, 1D, Polar).

Scene: This is essentially the list of plots to render.

Plot: A plot contains the data set to render, the name of an optional field, cellset, and normal array from the data set to render, and some rendering attributes like log scaling and color table.

Concrete Subtypes

Render Surface

  1. eavlRenderSurfaceGL is the base class for dealing with OpenGL rendering contexts. It does not create or activate any contexts itself, so it is used for on-screen rendering e.g. within a QGLWidget.
  1. eavlRenderSurfaceOSMesa derives from eavlRenderSurfaceGL but includes context creation for an OSMesa pixel and depth buffer.

World Annotator

  1. eavlWorldAnnotatorGL draws screen-space lines and text using OpenGL commands.
  1. eavlWorldAnnotatorPS is currently unimplemented as attempting to do world-space vector annotations in postscript is a little lacking (would have to ignore depth buffer), but could be implemented.

Scene Renderer

  1. eavlSceneRendererSimpleGL is the base OpenGL implementation that implements the minimum necessary (namely a single triangle/edge/point with node normals and node scalars) and allows the base class to decompose a data set.
  1. eavlSceneRendererGL is a more optimized implementation derived from eavlSceneRendererSimpleGL that maps a whole dataset to OpenGL more efficiently (and keeping quads as quads).
  1. eavlSceneRendererRT is the data-parallel ray tracing renderer. It keeps its own internal pixel buffer.

There are others as well: VR for volume rendering, and a SimpleRT for unoptimized ray tracing, both of which keep their own internal pixel buffer.

Window

  1. eavl1DWindow, eavl2DWindow, and eavl3DWindow are all similar. They initialize viewports and can render any window-specific annotations. These also handle legends. Right now, the 2D and 3D windows will make a colortable annotation from the first plot. The 1D window will create a solid block color table suitable for a plot with lots of curves (e.g. labeling red as "A" and green as "B").

Scene

  1. Base class only.

Plot

  1. eavlPlot is the base class and gets things set up for rendering, like finding the right field pointers and extracting data and spatial extents. It also handles transforms like polar.
  1. eavl1DPlot is the only specialization; instead of mapping all coordinates fields to spatial coordinates, it treats the first coordinate as X and one of the FIELD values as Y. It can also handle e.g. "bar" plots.