Rendering Nodes

• window
• viewport
• fog
• render

window

The window statement defines a window on the display screen. The dimensions and location of the window are defined in Normalized Device Coordinates (NDC) of the screen between 0 and 1.

The origin is defined in NDC by the origin statement. The origin_double is interpreted as (x_min y_min) and defines the upper left corner of the window where both x_min and y_min are in NDC.

Similarly, the dimensions of the window are defined by the size statement. The size_double is interpreted as (x_size y_size) where x_size and y_size are the horizontal and vertical sizes of the window respectively. As before, x_size and y_size are also in NDC.

These values, x_min, y_min, x_size, and y_size, are not dynamic values. They are used only as a suggestion to the windowing system to specify the initial size of the window. The window may later be reshaped by the user or by the windowing system and no longer correspond to the input values.

The color_triple defines the background color that the window is cleared to. It is an RGB triple and it can have dynamic values. For example,

window app_win
  origin     (0.5 0.5) 
  size       (0.5 0.5) 
  background (0 0 1)
endwindow

viewport

viewport view10 app_win
  origin (0.5 0)
  size   (0.5 1)
endviewport

The default values are:

fog

render

Any light that will be used to illuminate the scene must be specified in the render statement by its full path. The optional onoff_flag for each light can be used to turn that light on or off from the render statement. If a node in the path for a light has an lod of SLF_OFF, that light will still be used to illuminate the scene.

Any number of render statements can be specified in a single file, but there must be at least one for anything to be displayed. This flexible matching of viewport, geometry root and camera makes the render statement very general. Side-by-side viewports in a single window with slightly disparate views can be used to produce stereo viewing. A multiple window setup can provide different views on the same world. This, for example, could be used in the implementation of a driving simulator, with separate camera specifications and viewports corresponding to windshield, rearview mirror and sideview mirror views.

A render statement causes the image of some part of the group hierarchy to be rendered into a viewport on a display window. The viewport_id defines the viewport into which the image is drawn. Recall that a viewport has an associated window and therefore the render statement also specifies the particular window on the screen into which to render.

The camera_idpath in the render statement identifies a global camera or an instance of a camera within a scene hierarchy.

The node_id defines the root of the portion of the hierarchy to be rendered. The only geometric entities that exist in the context of this render statement are those that are contained in this hierarchy.

The render statement has an lod_flag that limits the LOD of the root node just as if it were a parent of that node in the scene hierarchy.

The tcltag statement defines a string, id, that will be used to identify all TCL variables associated with the render. The global variables SLF_MOUSE_X and SLF_MOUSE_Y will be replaced by separate variables for each tagged render statement with SLF_id_MOUSE_X and SLF_id_MOUSE_Y. The current viewport width and height, SLF_id_WIDTH and SLF_id_HEIGHT will be reset after any resize event. If more than one render statement use the same id, the values will be for the last viewport to receive a resize event. Other variables may be defined from a C++ viewer. For example, the viewer program can define the crystal ball manipulation variables, (SLF_id_AXIS_X, SLF_id_AXIS_Y, SLF_id_AXIS_Z), SLF_id_ANGLE, and SLF_id_SCALE, which can be used in an instance statement to define the crystal ball orientation.

group icosa_ball
  instance icosa
    rotate   ( {$SLF_foo_AXIS_X} {$SLF_foo_AXIS_Y} {$SLF_foo_AXIS_Z} ) ( {$SLF_foo_ANGLE} )
    scale    ( {$SLF_foo_SCALE} {$SLF_foo_SCALE} {$SLF_foo_SCALE} )
  endinstance
endgroup

render bigvp globalcam icosa_ball
  tcltag   foo
endrender

The camera_idpath

The camera_idpath is the identifier pathname of the specific camera that produces the image. If this is a single identifier, then the top-level camera with this identifier is used to produce the image.

group_id.[instance_id.]^*caminstance_id.camera_id

The [world-camera] transformation will be the inverse of the transformation that places the camera in the group identified by node_path. This root group for the camera path does not have to be the same as the render root for the scene.

For example, in this scene I have a fishtank containing two fish, each of which has two eyes. I want to render the scene from the right eye of the second fish. Therefore, I have to give the second fish instance an id so that I can refer to it in the render statement.

group fishtank
  instance fish
  endinstance
  instance fish
    id       fish2
  endinstance
endgroup

group fish
  instance fishcam
    id             right_eye
  endinstance
  instance fishcam
    id             left_eye
  endinstance
  instance       fishgeom
  endinstance
endgroup

camera fishcam
  projection SLF_PERSPECTIVE
  frustum    (-3 -3 -100) (3 3 -0.01)
endcamera

render VIEWPORT fishtank.fish2.right_eye.fishcam fishtank
  light  myspotlight SLF_ON
endrender