| |
|
|
|
B Hardware and Software Renderers
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.
- Section B.1, Support for Hardware and Software Rendering
- Section B.2, Rendering Features Across Platforms
- Section B.3, Disabling the Renderers
- Section B.4, Common Features for OpenGL Renderers
- Section B.5, Common Features for Other Renderers
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.
Table B-1
Table B-2
Table B-4
- highlight color 11
- Glyph size4
- Subdivision5
4Glyph 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.
6The software renderer rasterizes spheres directly, so there is no subdivision level for intermediate tessellation.
7In addition to spheres, OpenGL uses subdivision for the tessellation of cylinders and cones used in special Points and Lines modes.
Table B-5
Table B-6
33D texture mapping is only available on the SGI Reality Engine, Reality Engine 2, Impact, Infinite Reality, and VTX.
Table B-7
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.
1. Select Project -> Configure from the AVS/Express menu bar. A dialog box that contains a list of renderers and kits that may be disabled is displayed.
- A message is displayed informing you to recompile your project and restart the express executable.
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-vi for a listing of machine types.
Follow the steps below to disable one or more renderers.
1. Edit the gd_ren.h file and remove the lines associated with the renderers that you want to disable.
- The lines that you need to remove look similar to the lines shown below.
- On UNIX platforms:
cd $XP_ROOT
mv .proj_lock .proj_lock.orig
bin/$MACHINE/base -gen_proc express -exit
make -f express.mk relink
mv .proj_lock.orig .proj_lock
- On Windows platforms:
- This builds an executable that is not linked to the hardware renderer driver libraries (libgdogl.lib, libgdogl.a, libgdpex.a, or libgdxgl.a) and does not depend on finding a graphics environment (that is, the system shared libraries for OpenGL, PEX, or XGL) at runtime.
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 (Windows 95 and Windows NT), 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:
- For UNIX (GLX) platforms:
- Confirmation that GLX is running on the server and the GLX version number are output.
- The OpenGL version number, vendor name, hardware name, and a list of supported extensions.
- OpenGL parameters are displayed. These are ARGB color buffer depths, Z-buffer depth, maximum number of lights, and maximum 2D texture image dimension.
- The type of connection to the X server (Direct or Indirect), X visual id, and X visual class (TrueColor or DirectColor) are output.
- The connection tells whether OpenGL and GLX have direct access to the display when client and server are the same machine. If the type is Indirect, the client and server are remote or they are on the same host, but display requests pass through the X server. In general, direct connections are faster than indirect connections when the display is local.
The example output shown below is from a Digital AlphaStation 400 4/233 with an 8-bit entry level graphics option.
- For Windows (WinGL) platforms:
- The OpenGL version number, vendor name, hardware name, and a list of supported extensions. The hardware name can be the vendor's code name for the graphics option, not the usual product name, but it should give enough information to uniquely identify the hardware.
- OpenGL parameters are displayed. These are ARGB color buffer depths, Z-buffer depth, maximum number of lights, and maximum 2D texture image dimension.
- The example output below shows what is displayed on platforms running WinGL.
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:
- This extension is a generic OpenGL extension that allows the OpenGL renderer to support 3D texture. The OpenGL renderer uses 3D texture in the following ways (note that no mip-mapping is available for 3D texture mapping):
- Texture mapping volume data onto arbitrary 3D surfaces. Surface primitives must have uvw texture coordinate node data. The application must supply the texture image, an optional texture colormap, and surfaces.
- Direct rendering of volumes. A 3D uniform field with byte node data creates a 3D texture and the volume is rendered as a stack of slice planes blended from back-to-front. See Volume Rendering for more details.
- This extension is an SGI-specific extension that allows the OpenGL renderer to support indexed texture. Indexed texture uses 8-bit index data directly as a texture map. The standard OpenGL renderer converts byte textures to ARGB before loading them into texture memory. Using this extension, byte data is loaded into texture memory and the color look-up table is loaded into a separate hardware texture color table. At render time, the application performs the look-up of the texture colors. This has three important effects:
- Indexed texture reduces texture memory requirements. It uses 25% less memory than the conventional implementation with ARGB components.
- Textures are created faster because the texture data does not pass through a color look-up in the renderer.
- Indexed texture achieves faster colormap animation because only the texture colormap is reloaded. A standard implementation reconstructs the texture by color look-up in the renderer and reloads it into texture memory.
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.
- Note: The 2D texture method attempts to load all 2D slices into texture memory. If this fails, the slices are rendered one at a time so that only one texture is in texture memory at any one time.
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:
- Point color - If there is color node data, each glyph has a constant color determined by the data value at its associated vertex.
- Uniform highlight color - If there is no color node data and there are Line and/or Surface modes enabled for the same data, all glyphs take the relevant highlight color property.
- Uniform object color - If there is no color node data and no other rendering of the same dataset, the glyphs inherit the primary object color property.
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 scale - If there is radius node data, it is used as a world coordinate length to determine the length of each glyph independently.
- Uniform scale - If there is no radius node data, the length is taken from the Glyph size property.
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:
- tube =
- ribbon =
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.
- The GLX extension that supports OpenGL is not available or was not configured in the X server when it started. On some platforms, you must start the X server with command line options to get OpenGL and double buffering. See the system prerequisites chapter for your platform.
- GLX and OpenGL are supported, but do not provide a satisfactory visual for use by AVS/Express. The specification of GLX ensures that at least one single buffered visual is available. Try to re-instance the OpenGL renderer for a view in single-buffered mode.
- GLX and OpenGL are available, and a satisfactory visual was found on the server. However, other resources were not found and the server cannot create an OpenGL renderer window or the associated X colormap.
- OpenGL is always supported at the operating system level in Windows, but a mismatch can occur between the pixel format requirements of the AVS/Express OpenGL renderer and the descriptor used by the Windows display. Try restarting Windows with 24-bit format.
- The system ran out of resources or had a memory management error while the renderer tried to allocate a palette.
- The application tried to display an object with 3D texture on a system that does not support the OpenGL 3D texture extension. Only SGI Reality Engine, Reality Engine 2, and VTX support 3D texture; you must relink AVS/Express to enable 3D and indexed texture extensions on these machines. Note that 3D textures cannot be displayed from a remote client unless the client also supports the relevant extensions. If you do not have one of these high-end machines, use the Software Renderer to display 3D texture.
- The graphics display supports texture, but ran out of resources allocating texture memory from the host's main memory or from the graphics adapter. Reduce the size of the texture using filter modules (for example, downsize), or allocate more swap space, main memory, or hardware texture memory.
OpenGL error X in gluBuild2DMipmaps
OpenGL error X in glTexImage3DEXT
OpenGL error X in glTexImage2D
OpenGL error X in gluScaleImage
- A standard OpenGL error occurred in one of these functions. The OpenGL error message should follow this AVS/Express error. Possibly, texture memory overflowed, in which case, reduce the size of the texture using filter modules (for example, downsize) or allocate more swap space, main memory, or hardware texture memory.
- These are specifically generated by the back-to-front volume rendering routines. The volume data must be a 3D uniform scalar byte field. The dimensions of the slice perpendicular to the view direction must fit in texture memory.
- The back-to-front volume renderer tries to use the datamap to get a color table. If there is no datamap, these warnings are issued and it defaults to a greyscale ARGB ramp.
Vertex Level Texture Mapping (VLTM) is available on the ZX ("leo") adapter. This option is on the Object Editor Surface Conversion menu. The default method of texture mapping is "normal".
VLTM subdivides triangles to simulate a texture using per-vertex coloring. Since the ZX adapter can quickly render geometry with per-vertex colors (and has no low-level acceleration for "normal" texturing), this is faster than using the normal method. Note the texture method is not inherited in the object hierarchy, so the object must be selected before a change of texture method or parameter takes effect.
For VLTM, the subdivision level controlling texture sharpness can be set via the object Triangle Subdivision option and values. The two forms of subdivision are adaptive and fixed. For adaptive, triangles subdivide until a certain pixel tolerance (specified as the adaptive value) is reached. For fixed, each triangle is subdivided by the number of segments specified.
Be aware that VLTM subdivision can consume large quantities of swap space, depending on the size and complexity of the geometry being textured. This is particularly true for adaptive subdivision. When using adaptive subdivision, start with a large value for the subdivision level and gradually reduce the value while monitoring swap space, until you obtain the desired image quality. When using fixed subdivision, take the opposite approach, by starting with a small value and gradually increasing it. You may find, for geometry that does not vary too greatly in size from one triangle to another, that fixed subdivision gives better results and consumes less memory than the adaptive method.
Some graphics adapters, most notably the Evans & Sutherland Freedom board, achieve their best performance from a display list form of rendering. In XGL this is called pcaching. This option is on the View Editor menu. It is disabled by default. Note that you cannot selectively Pcache objects, only all objects within a view. Use the timer option, also in the View Editor menu, to determine if pcaching increases performance on the adapter you are using. Use the adapter only if you see a substantial performance improvement because more memory is consumed when using this option.
The Accelerate Mode and Input/Output Frame Buffer options are available on SunOS 5 only and not on SunOS 4, since the image and Z buffer data in the framebuffer cannot be accessed on the SunOS 4 version of XGL.
Accelerate mode is unlikely to give any performance improvement unless the graphics adapter is "slow" and/or there is a "large" amount of data to be rendered. In practice this means there is likely to be a performance degradation on the (T)ZX and UltraSPARC Creator 3D adapters unless there is a very large amount of data being rendered. On the SX there might be a performance benefit using this option. It is doubtful if this option will work on the GS and GT adapters, since image and Z buffer readback are probably not implemented. Support for these adapters has been dropped by Sun Microsystems in Solaris 2.5.
Frame buffer I/O should work on all adapters except the now defunct GS and GT boards. Note that the "native" framebuffer image format is ABGR and Z buffer format is "int". You should find that better performance is achieved by ensuring framebuffer input into an XGL renderer is in these native formats.
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.
- Note: This is a 2D only renderer; no 3D objects will be rendered when using it.
The PEX renderer currently does not support:
The revision date of the /usr/lib/libPEX5.sl library must be greater than or equal to the date of the PEX library that Advanced Visual Systems used to link the AVS/Express application. If the dates are not compatible, the following message will be displayed when you attempt to start AVS/Express.
/lib/dld.sl: Invalid version for shared library: /usr/lib libPEX5.sl
/lib/dld.sl: Exec format error
IOT trap
Several errors can occur during the initialization of the PEX renderer that cause AVS/Express to use the software renderer. The errors and an explanation are provided below.
- The initialization of the PEXlib display connection via a call to PEXInitialize failed. Refer to the PEX manuals for more information.
- The PEX renderer requires a PEX 5.1 server. To verify that you have the proper version of PEXlib, type:
- Immediate mode is not supported in the currently installed version of the PEX server, and this feature is required by the PEX renderer.
- The visual class specified by the vclass or vid subobject in the virtual palette attached to the view was not found. This can happen if the specified visual is an 8-bit PseudoColor visual or if you are running to a remote display.
- Double buffer mode was requested via the buffer subobject in the view, but it is not available in the requested visual. You may want to change the buffer subobject to request single buffering and try again.
- The visual class obtained for the vid subobject in the virtual palette is not supported. Make sure the visual class of the specified vid is PseudoColor, DirectColor, or TrueColor.
| |
|
|
|