GEOMETRY commands


PROGRAM NAME

render - Interactive Geometry Visualization

DESCRIPTION

Render is the Khoros geometry renderer. Implemented as an Xvroutine, it may be included as part of a Cantata workspace or run from the command line.

Render accepts input in the form of geometry created by the visualization modules in the Geometry Toolbox, and produces images, possibly displaying them. A GUI is provided which permits interaction between the user and the renderer.

To use Render, first compute some geometry with one of the modules which produce geometry (extents_box, isosurface, etc). The input parameters to Render should use the name of a transport (stream, shared memory, etc.) that contains geometry data. When Render comes up, it will pop up two windows. One window is the control panel for the Render, the second is the image display window (unless image display has been supressed). If certain default values are used (such as the "autonormalize view" option), your geometry objects should be visible when both of the display and menu windows appear on your screen.

The default position for the camera is roughly (0,10,50) looking in the -Z direction towards the XY plane (unless this position is overridden by command-line arguments).

Direct interaction with the rendered image is available with the mouse. Pressing different mouse buttons on the image and moving the mouse will perform different transformations. When a transformation is initiated by pressing on a mouse button, you will see a bounding box representing the extents of the geometry. Moving the mouse will transform this bounding box. When the desired transformation has been performed, releasing the mouse button will initiate a rendering at the new transformation.

The middle button controls rotations. Shift+middle button will produce an isometric scaling of the object. The right mouse button will translate the object parallel to the x-y image plane. Shift+right will move the object along the z-axis of the image plane.

On the keyboard, the up and down arrow keys control rotations about the X-axis; the left and right arrow keys control rotations about the Y-axis; the Page_up and Page_down keys control rotations about the Z-axis. There seems to be a bug on non-solaris machines which prevents actions from being defined on the arrow keys. If the arrow keys do not work for your display, the (x-X,y-Y,z-Z) keys may be used as alternatives.

Rotations Pressing the middle mouse button on the rendered image and moving the mouse will allow you to rotate the geometry. When you press down on the middle mouse button, you will see a circle drawn on the image. Moving the mouse up and down within this circle will perform an X rotation. Moving the mouse left and right within this circle will perform a Y rotation. Moving the mouse around the outside of the circle will perform a Z rotation.

Scaling Pressing the middle mouse button while holding down the shift key on the rendered image and moving the mouse will allow you to scale the geometry. Moving the mouse to the left will scale downward and moving the mouse up and to the left will scale upward.

Translation Pressing the right mouse button the rendered image and moving the mouse will allow you to translate the geometry in the X and Y directions. Translations in the Z direction is accomplished by pressing the right mouse button and the shift key.

Render Control Panes

A number of different control panes are present on the interface for Render. These are described below.

Objects Pane The Objects pane provides for control over different object-level properties; selecting an object from the pulldown gives you control over that particular object. Selecting the root object implies that property changes apply globally to all objects. Different object shaders are selected from the pull-down menu here. Note that selecting objects here also indicates which object you wish to transform. You can directly control object transformations, either from the Transformations Pane or directly from the image.

The "reset object transformation matrix" will change the matrix of the currently selected object to the identity matrix.

Cameras Pane The Cameras pane provides control over the camera parameters, such as the eye point, the look-at point, the up vector, the frustrum of vision (which defines the angle frustrum in degrees), as well as the front and back clipping planes.

The viewer's position is located at (Eye_X, Eye_Y, Eye_Z) in world space coordinate, looking at the point (At_X, At_Y, At_Z), also in world space coordinates. The vector specified by (Up_X,Up_Y,Up_Z) is a reference vector indicating which was is "up" from the viewer's point of view. The field-of-view parameter defines the window size through which the viewer is looking. The entire contents of this window is mapped to the display image. The aspect ratio is always 1:1, although this will be changed in future releases. Thus, when mapping a square window (defined by the 1:1 aspect ratio) into a non-square display window, the objects may appear squished or stretched, depending upon the degree of "non-squaredness" of the display window.

The clipping planes are specified as follows: A floating point value between 0 and 1.0 for the front clip plane indicates a point along the vector between the eyepoint and the look-at point at which the front clip plane will be positioned. A value of 1.0 puts the front clip plane at the look-at point. A value of 0.5 puts the front clip plane halfway between the viewer and the look-at point. A value of 0.0 (although this is not allowed) would put the front clip plane at the view point. Front plane clipping is always enabled.

A similar scheme is used for the back clip plane, although the directions are reversed. A value of 0.0 puts the back clip plane at the look-at point. A value of 1.0 puts the back clip plane "one unit" away from the look-at point, where "one unit" is defined as the distance between the viewer and the look-at point. Increasing the value for the back clip plane moves it further and further away from the look-at point along the view/look-at vector. There is no upper bound on this value. Back plane clipping may be turned on or off using the toggle on the cameras menu.

The "startup defaults" button will reset the view parameters to those used at startup time (either from the command line, if specified, or from values internal to the code used if no command line arguments are present.

The "normalize view" button will attempt to set the view parameters to those in which the displayed object appears centered in the display and sized such that they fill "Most" of the display. This operation works pretty well most of the time, although there are conditions in which it fails.

Lights Pane The Lights pane provides control to the array of lights which are provided for use in illuminating the scene. Within the light array, the user is free to set the light type be directional, bidirectional or point-light. There is one global ambient light which is separate from this array of lights. The initial configuration of the 3-element light array is 3 directional light sources, only one of which is turned on.

BUG: only Light1 works reliably. Multiple light sources are not fully functional yet (April 1995).

Imaging Pane The Imaging pane contains controls for changing the image size, the image display, and the background color, and the way in which the computed image is presented to the user.

The background color sliders are used to set the RGB value of the image background.

The image display mode parameter will allow you to choose how the image will be displayed to you. The choices available are: "3-3-2 truecolor" (an 8-bit display mode that is fast but doesn't look that great); "24bit truecolor" (best visually, but only works on 24bit displays); color quantized (an 8-bit display mode that works pretty well, but is kind of slow) and a "dithered" mode (also an 8-bit display mode that works pretty well and is a bit faster than color quantizing).

On SGI machines, an additional "24-Bit RGB OpenGL" mode is available for hardware assisted rendering. This mode will utilize the SGI graphics hardware to allow rendering at interactive speeds. In this mode, the Renderer Invocation can be turned to "Immediate". In Immediate mode rendering, interactive transformations will apply immediately to the rendered view, rather than being deferred until the mouse button is released.

The controls for texture mapping are also here. Texture maps can either be Point-Sampled or Bilinear as they are rendered. Bilinear produces a "better" image than Point-Sampled, at the cost of slower rendering time. The texture mapping can also be disabled if not needed. (Khoros 2.1 - only point-sampled texture mapping is supported.)

The image width and height sliders will allow you specify a new width and/or height for the image. You can use these sliders, or you can just resize the display window with the mouse via your window manager.

Whenever you resize the image or select a new display mode, you'll have to press the "render" button to get the objects rerendered and displayed to you.

Transformations Pane The primary purpose of the transformations pane is to provide some degree of control over how relative transformations are performed, as well as give some informational data about the objects, etc. being viewed. The user can set the amount of relative rotation along either of the X-Axis, Y-Axis or Z-axis. Effecting relative rotation is done by using the following keys on the keyboard (with the cursor positioned within the image display window): up and down buttons (X-axis relative rotation); left and right buttons (Y-axis relative rotation); page-up and page-down buttons (Z-axis relative rotation).

The balance of the items on the transformations pane are either not currently implemented (isometric scaling) or are informational only (object center point, translate vector).

Future plans include interactive transformation of lights and viewer position, but for now (April, 1995) only objects may be moved around interactively.

Input Pane The Input pane contains four input lines. these can be used to specify files containing geometry data to be rendered. If input files were specified on startup, the files specified here will replace them.

Output Pane The Output pane contains a selection for saving the currently displayed image. This feature is currently unimplemented.

Shaders Available

A number of different shaders are supported in the Render. Typical surface shaders are no-light (where the color of the surface doesn't depend upon interactions with the lights in the scene), flat (where the polygons are assumed to be of a constant shade), gouroud (where colors are interpolated between vertices across the face of the polygon) and phong (where the surface normal is interpolated across the face of the polygon). At present, only no-light, flat and gouroud shaders are supported.

For volume rendering, three shader types are supported; these are "voxel-dot" (where a single point, possibly transparent, is produced for each voxel), "splat homogeneous" (where the 2d voxel footprint is approximated with a rectangle of constant shade and opacity) and "splat homogeneous gauss" (where the 2d voxel footprint is approximated with a rectangle of constant shade, but the opacity in the rectangle is approximated with a 2D gaussian function.

One note about triangle shading : Most shading models assume per-vertex normals, and all shading calculations are performed at each vertex, with the triangle's shade interpolated across the face of the triangle. Geometry Services, in contrast, provides a wide range of combinations of per-vertex/per-facet data; color and normals may be specified either per-vertex or per-facet. By necessity, some of the potential speed increases are lost when per-face normals or colors are used as these specifications imply that shared vertices must have shading calculations performed on a per-facet basis. The portions of the rendering which is shared, regardless of the per-facet or per-vertex specification, is the geometric transformation (this calculation is less expensive than the cost of shading a vertex).

Supported Geometry

There are a number of primitives which can be rendered directly by the Render.

Disjoint Triangles Disjoint triangles, where every triangle is represented by three vertices, can be rendered by Render. Triangles with no colors, per-vertex colors, and per-face colors are supported. If no colors are provided, the global object color is used. If no normals are provided, then normals are generated on input. Texture mapping is not yet implemented for disjoint triangles.

Connected Triangles Connected triangles, also known as triangle strips or triangle meshes, have the benefit of reducing vertex redundancy, achieving up to a threefold reduction in space over disjoint triangles by employing vertices which are shared between adjacent triangles. Up to a threefold performance increase may be realized due to the fact that three times fewer per-vertex operations are performed.

Triangle strips may be rendered with 1. per-vertex colors and normals; 2. per-vertex colors and NO normals (they will be computed per-face on object read-in); 3. per-face colors and NO normals (they will be computed per-face on object read-in); 4. per-face colors and per-face normals or 5. no colors or normals.

Texture mapping onto triangle strips is not yet supported.

Spheres Spheres, where each sphere is represented by a vertex are supported. The spheres are actually tesselated into triangles for rendering. If the provided spheres data has no colors or radii, the global object color and a default radius will be used.

Disjoint and Connected Lines Both disjoint and connected lines are understood by Render.

Text Text primitives are supported by Render.

Quadmeshes Quadmeshes are supported. Currently, provided colors must be per-vertex and consist of RGBA vectors. If no normals are provided, then normals are generated on input.

Octmeshes Octmeshes are supported. Currently, provided colors must be per-vertex and consist of RGBA vectors. Octmeshes can be rendered as 3D textures on machines which have the GL_3DTEXTURE_EXT extension to OpenGL (SGI's). Otherwise, your choices are more limited, and they tend to run rather slowly.

Two-dimensional and three-dimensional text.

2d Texture mapping of two-dimensional images onto three-dimensional surfaces. In OpenGL, there is a requirement that all textures be an even power of two in size. Render will resize your textures to be an even power of two if they're not; the computed size will be the largest number which is an even power of two but that is smaller than the texture map size; width and height are separately computed. For more control, use the kroutine "gresample" to resample Khoros data objects to a particular size. Use the kroutine "gcreate2dtex" to create a texture map from a Khoros data object, then use "gbindtexture" to actually bind the texture to the geometry. You need not directly connect any textures to Render as input - the transport name for them is buried inside of the geometry object output by gbindtexture. If you do provide a texture as input, nothing happens. It actually has to be "bound" to a geometry object.

VR device events. These include control of the camera position and orientation as well as position and orientation of objects within the world.

STAY TUNED

Directed points and three dimensional textures didn't make it into the the Khoros 2.1 release. Sorry.

KNOWN BUGS

The following list (probably incomplete) enumerates the known bugs in the Render.

1. When the color quantize display mode is selected, the initial image displayed is not the same as the background color. This may be ignored. The next time an image is put to this window, the correct colors are displayed.

2. Polygon clipping is not fully implemented. Those polygons that are "too close" to the viewer are rejected, but those off-screen to the left or right still get scan converted. The result is that the runtime of Render is excessive in some conditions.

3. Software Rendering of Spheres. Is wrong.

REQUIRED ARGUMENTS

none

OPTIONAL ARGUMENTS

-i1
type: infile
desc: Input file 1
default: {none}
-i2
type: infile
desc: Input file 2
default: {none}
-i3
type: infile
desc: Input file 3
default: {none}
-i4
type: infile
desc: Input file 4
default: {none}
-i5
type: infile
desc: Input file 5
default: {none}
-i6
type: infile
desc: Input file 6
default: {none}
-i7
type: infile
desc: Input file 7
default: {none}
-iscene
type: infile
desc: Specificatio of a so-called scene file.
default: {none}
-view
type: list
desc: viewing method for rendered image
default: -1 "Best Possible"
-wsize
type: integer
desc: width of rendered image
default: 256
bounds: 32 < [-wsize] < 4096
-hsize
type: integer
desc: height of rendered image
default: 256
bounds: 32 < [-hsize] < 4096
-norm
type: boolean
desc: compute view so all objects appear in the render window.
default: true
-proj
type: list
desc: Projection method to use when rendering
default: 0 "Perspective"
-eye_x
type: float
desc: x component of eye position.
default: 0
bounds: -100 < [-eye_x] < 100
-up_x
type: float
desc: x component of up vector.
default: 0
bounds: -100 < [-up_x] < 100
-at_x
type: float
desc: x component of initial look-at point.
default: 0
bounds: -100 < [-at_x] < 100
-eye_y
type: float
desc: y component of eye position.
default: 10
bounds: -100 < [-eye_y] < 100
-up_y
type: float
desc: y component of up vector.
default: 1
bounds: -100 < [-up_y] < 100
-at_y
type: float
desc: y component of initial look-at point.
default: 0
bounds: -100 < [-at_y] < 100
-eye_z
type: float
desc: z component of eye position.
default: 50
bounds: -100 < [-eye_z] < 100
-up_z
type: float
desc: z component of up vector.
default: 0
bounds: -100 < [-up_z] < 100
-at_z
type: float
desc: z component of initial look-at point.
default: 0
bounds: -100 < [-at_z] < 100
-hither
type: float
desc: Location of front clip plane. (1 is look-at point, 0 is view point)
default: 0.05
bounds: 0.05 < [-hither] < 1
-yon
type: float
desc: Location of back clip plane. (0 is look-at point, 1 is view point)
default: 2
bounds: 0 < [-yon] < 1e+07
-bc
type: boolean
desc: turns back clipping on or off.
default: true
-use_hardware
type: boolean
desc: When Render is started, if this variable is set to true, render will invoke the hardware renderer. Otherwise, the default renderer is the software renderer.
default: true
-o
type: outfile
desc: Output rendered image
default: {none}
-oxfrm
type: outfile
desc: Data object which holds view transformation matrix, and transformation matrix for the top level object.
default: {none}
-oscene
type: outfile
desc: output scene file
default: render.scenefile

EXAMPLES

render -i geometry:ytter_iso2

SEE ALSO

geometry

RESTRICTIONS

REFERENCES

COPYRIGHT

Copyright (C) 1996,1997 , The Regents of the University of California. All rights reserved.