Installing AVS/Express
 |
 |
 |
 |
Installing AVS/Express |
|
This chapter defines the renderers that are supported on the various platforms. It also describes the functionality each renderer supports and provides some renderer-specific notes.
The following table shows the hardware renderers that are supported on each platform. All platforms support the software and print renderers.
The following sections consist of tables that specify the rendering features that are supported by the various renderers. Each section shows the rendering features of a specific AVS/Express editor.
The following annotated table shows the rendering features available in the software renderer, the print renderer, and the various hardware renderers. The following sections consists of tables that specify the rendering features that are supported by the various renderers. Each section shows the rendering features of a specific AVS/Express editor.
1SGI only. Full screen stereo is used for all adapters except where quad buffering is available. For example, in Impact, Infinite Reality, and Reality Engines.
|
|
||
|
||
|
||
1The highlight colors are used for "outline" modes. The first highlight color is used for the first outline (for example, lines on a surface or points on lines). The second highlight color is used for the second outline (for example, points on lines and surfaces).
2Glyph size controls the dir_pt_size subobject which affects the length of normal lines in Directed Points mode, and can affect the length and radius of tubes, cones, and arrows in special modes within the OpenGL renderer.
4The software renderer rasterizes spheres directly, so there is no subdivision level for intermediate tessellation.
5In addition to spheres, OpenGL uses subdivision for the tessellation of cylinders and cones used in special Points and Lines modes.
|
|
3OpenGL implements back-to-front volume rendering using 3D alpha texture on SGI Reality Engine, Reality Engine 2, Impact, Infinite Reality, and VTX. On all other platforms, 2D texture is used.
|
13D texture mapping is only available on the SGI Reality Engine, Reality Engine 2, Impact, Infinite Reality, and VTX.
|
1All OpenGL renderers use sphere primitives, but the implementations can vary between platforms and graphics hardware. Most OpenGL libraries tessellate the sphere as a preprocessing step before caching and rendering.
|
If you want or need to run AVS/Express without any dependencies on the graphics runtime environment, you can disable the OpenGL renderer and/or the hardware renderers using one of the methods outlined below. The method you use depends on whether you are already running AVS/Express.
In some cases, you may need to disable a renderers in order to start AVS/Express. For example, your system may not have one of the renderers, or you may not have one of the necessary shared libraries. If you want or need to disable the renderer on startup, you have two options, each of which is outlined below.
You can disable all renderers using the -nohw option of the express start-up command.
You can disable renderers by editing the <install-dir>/express/include/<machine type>/gd_ren.h file. Recall that <install-dir> is the directory in which you installed AVS/Express, and <machine type> is the string that corresponds to the platform on which you are running. Refer to the table on page 1-2 for a listing of machine types.
Follow the steps below to disable one or more renderers.
A number of features are common to OpenGL renderers regardless of platform. However, there are also several differences, which are determined by the windowing system: X Windows, Windows NT, or Windows 95.
On Windows-based platforms, WinGL is the OpenGL extension. Display properties are fixed for all windows at boot time, and window information is held in a pixel format descriptor. One descriptor is associated with each Windows display, and its value cannot be set after the Windows server starts. AVS/Express OpenGL renderers do not get a choice of window properties.
On UNIX platforms (X Windows), GLX is the OpenGL extension. It embodies a programming interface and a protocol for client-server communication. GLX provides a mechanism for OpenGL to allocate and control display resources on the X server. It binds an OpenGL rendering context to a specific X visual that is selected from the list of visuals supported by the X server.
Only displays that use an RGB pixel format with a Z-buffer support the OpenGL renderer.
To double buffer the view window under GLX, OpenGL must be supported in a double-buffered TrueColor or DirectColor X visual with an associated Z-buffer. The GLX specification requires that at least one such visual is supported.
Several UNIX tools enumerate the available X visuals and their support for OpenGL via the GLX extension. A standard X Window program, called xdpyinfo, lists X server parameters and all supported visuals with their X Window characteristics. A GLX inquiry utility, called xglinfo, is usually supplied with OpenGL examples. xglinfo lists general GLX parameters as well as each X visual and its support for OpenGL. OpenGL installations can repeat X visuals, which differ only in the configuration of additional (non-X) buffers used by OpenGL (for example, alpha, depth, stencil).
On both UNIX and Windows-based platforms, RGB visual formats can be 8-bit (3-3-2), 12-bit (4-4-4), 24-bit (8-8-8), or 36-bit (12-12-12). The OpenGL renderer does not use blending modes that require the framebuffer to store alpha values.
When AVS/Express instances a viewer, a set of inquiries is performed when the OpenGL renderer is first instanced. The values returned from the inquiries contain information about the platform that is used as the OpenGL server (perhaps remotely), configuration of the OpenGL implementation, supported extensions, and characteristics of the view window. This information is used to configure the behavior of the renderer, and it is written to the command terminal if the environment variable XP_OGL_INFO is set before running AVS/Express.
To set XP_OGL_INFO from a UNIX C-shell environment, type the following command:
To set XP_OGL_INFO on the Windows platforms, type the following command:
The following information is displayed when XP_OGL_INFO is set:
The example output shown below is from a Digital AlphaStation 400 4/233 with an 8-bit entry level graphics option.
The OpenGL renderer uses GL_EXT_texture3D and GL_SGI_texture_color_table extensions if they are available.
The OpenGL extensions must be available on both the client and server for a remote connection. You list all the extensions supported by the server using XP_OGL_INFO. If either of these extensions is supported by the server but not by the client, a warning is issued with the diagnostic information stating that the extension is disabled.
Following is a description of the extensions:
The OpenGL renderer can render volume data using alpha texture mapping. The volume must be a 3D uniform scalar field with byte data. The datamap is used for color and opacity look-up. The volume does not have to be a cube.
Dimensions do not have to be a power of 2, but the OpenGL renderer scales the data to the next larger power of 2 to create OpenGL textures. Each dimension must be within the system limit for 2D texture size. The OpenGL specification requires that this limit is at least 256. (Refer to the Common Features for OpenGL Renderers section for information on how to determine the maximum 2D texture image dimension on your system).
The 2D texture method constructs a stack of 2D textured slices through the volume and then renders the stack slices back-to-front with alpha blending enabled. The slices in the stack are perpendicular to the axis that most closely aligns with the view direction, so the textures are view-dependent. When the view angle moves through 90o, the method rebuilds the stack by resampling the volume in the new slice planes and then downloading the new textures to texture memory.
If your platform supports the 3D texture extension, the renderer attempts to load the whole volume as a single 3D texture map. If the whole volume does not fit in texture memory, the renderer drops to a 2D texture method. When the data is loaded in texture memory, the volume is rendered back-to-front by drawing a stack of planar slices perpendicular to the axis that most closely aligns with the view direction.
If your platform supports the indexed texture extension, byte node data is loaded directly as texture and a colormap derived from the datamap is loaded as the texture color table. Otherwise, the system explicitly looks up the node data in the datamap and constructs ARGB texture. This is true for both 3D and 2D texture methods.
The OpenGL renderer has additional points and lines modes. These are detailed in the sections that follow.
The OpenGL renderer has three extra Points modes: Directed Arrow, Directed Cone, and Tangent Cross. These are in addition to the Directed Line mode. All directed modes and Tangent Cross require normal data. If none is available, they default to Pixel.
Directed Arrow and Directed Cone are extensions to Directed Points. If normal node data is available, they represent normal direction with solid arrows or cones instead of the standard line segments. Arrows and cones are always rendered with Gouraud Surface mode.
Tangent Cross is made up of two line primitives crossed at right angles in a plane that is perpendicular to the normal direction. You can use the Tangent Cross for any data, but they usually do not contribute more spatial information than a Lines mode rendering. The Tangent Cross is designed for rendering implicit surfaces using point cellsets that do not have explicit connectivity, and hence cannot be rendered in Lines or Surface modes.
A point cellset can imply a surface by specifying a normal direction at scattered locations in 3D space. By rendering a cross in the plane of this implied surface, you can see the general surface topology.
For example, imagine sampling a 3D scalar field to locate the same data value, then generating normal vectors from the field gradient at those locations. You can render this data using tangent crosses without constructing an explicit surface. To create an impression of a surface, the crosses are lit; in other words, their color is modulated according to the angle of directional light incident on the plane of the cross, and therefore, the plane of the implied surface. By having directional light incident along the line of sight, lowering the ambient light intensity, and using a black background, back-facing crosses are invisible. This suggests hidden-line/hidden-surface removal as if the implied surface were present. You can use this representation as the alternate object for a complex volume rendering.
You can consider the generic line, arrow, cone, and cross representations as a glyph.
An order of precedence determines the color of the glyph:
In Points modes, the width of the glyph is uniform. Directed Lines have width in screen space (pixels) determined by the Line width property. Arrows and cones have a uniform world coordinate width specified as a fixed fraction of the Glyph size property. Crosses are drawn with solid lines, and line width and anti-aliasing are taken from the Line Attribute properties.
There is an order of precedence for the length of the glyph in directed modes and the length of lines in a tangent cross:
Point cellsets that have radius and normal node data are a special case. If they have a Surface mode enabled, they are rendered as spheres; if there is no Surface mode, they are rendered in a Directed Points mode and the radius maps to the length of the glyph.
The subdivision property affects the arrow and cone surface glyph. If the subdivision is n, each cylindrical, circular, annular, or conical component has n facets, each composed of two triangles. Therefore, the arrow has 8n triangles and the cone has 4n triangles.
The OpenGL renderer has three extra Lines modes: Tube, Arrow, and Ribbon. Tube and Arrow replace line segment (from polylines or disjoint lines) with the corresponding glyph.
For polyline data, Tube mode can have color interpolation along the length of the tube if the data has vertex color. It uses radius data as the tube width to vary the diameter giving the appearance of a rubber tube. Without radius node data, the world coordinate tube width is a fixed fraction of the Glyph size property. The polyline Tube has spheres at each "joint" and at the ends to completely close the tube.
For disjoint lines, Tube mode creates a single cylinder at each segment, with flat caps at the ends. It always has constant color for each cylinder, although this can vary from segment to segment if there is color node data. It uses radius for tube width and defaults to a fraction of Glyph size.
Polyline Arrow does not allow color interpolation. It selects the color of the first vertex on a segment to color the entire arrow. It does not use radius node data. The arrows always have uniform width derived from the Glyph size property.
Ribbon mode stretches a single tristrip between each vertex on a polyline. When there is normal data, the ribbon orientation is perpendicular to the normal and the tangent vector at each vertex. Without normal data, the principle normal is derived from the local geometry (for example, a ribbon for a helix appears as a strip around a face of a cylinder).
The first and last segments of a ribbon do not have well-defined central-difference curvature, so they default to the appropriate forward or backward difference scheme.The ribbon is linearly interpolated between successive polyline vertices, giving a folded appearance when the normal vector changes direction rapidly along the length of the polyline. The algorithm does not interpolate angles in the plane perpendicular to the line segment, which is slower to generate.
All these surface glyphs use the subdivision property. For subdivision n, each cylinder, cap, and ribbon segment has 2n triangles; each sphere "joint" has 2n x n triangles. So, a polyline with p vertices has the following number of polygons:
The total number of triangles increases for complex models, which can be time consuming when building and rendering large collections of cylinders and spheres.
OpenGL allows wide and anti-aliased dots, but there are no Points properties in AVS/Express. The OpenGL renderer uses the Line width and Line anti-aliasing property values when rendering Points in Pixel mode.
OpenGL can render tessellated spheres as points or lines. If a points cellset with radius node data is rendered as Pixel, the OpenGL renderer draws a dot surface, with a dot at each vertex of the tessellation. If Regular lines mode is enabled, it draws lines of longitude and latitude on the sphere. The Subdivision property that controls the tessellation affects the density of the dot surface and the spacing of the latitude-longitude grid.
This renderer is only available on SunOS 5. It can accelerate the display of images depending on the image type and graphics adapter. You may find improved performance over the software renderer when using it on the SX ("cgfourteen") and UltraSPARC frame buffers. In addition, it supports the bicubic interpolation of images, currently not available in the software renderer.
|
|
|
|