KID Graphics: Overview

<<< Attributes in KID

Chapters

Viewing Environment and Definition >>>

Contents

• 11.1 Introduction
• 11.2 The Class Structure
• 11.3 Output Devices

[back to top]

11.1 Introduction

Within KID there is a graphical support library known as GRA. This module is only contained in KID and not in the PARASOLID kernel library. Calls are made to GRA to define a viewing environment, and then calls may be made to the Parasolid rendering functions. These also call GRA (via the Frustrum) and this results in the appearance of a picture on the screen, or transmission of graphical output to a file.

Opening an Xwindow

To open an X window for graphical display, type:

> (graphics open_device ´x)

Re-using an existing graphics window

To re-use an existing open graphics window, allowing a lisp script to be re-run multiple times without spawning multiple windows, type:

> (graphics reopen_device ´x)

Using the class structure, which provides inherited functions and properties, the user may define many different views with great ease. A new view may be defined to show the same objects from a different viewpoint (e.g. for orthographic views), or to show different objects from the same view (e.g. for assembly viewing).

For instance, if it is required to zoom in on an area of the picture a new view can be defined as a subclass of the current view. The window sizes can be changed and all other properties are inherited. The picture can then be drawn for the new view without altering the default graphics view. This scrap view can be deleted or kept for later use.

KID only allows one view to be active, although any number can be defined. When KID is started by the command (modeller start), a default view is defined and selected.

Functions are provided which allow the user to easily change the definition of the view, to send output to files or the screen and to pick items from the display.

[back to top]

11.2 The Class Structure

The pre-defined class structure for KID graphics is very simple, see the "Graphics substructure" section in Appendix A, "KID Class Structure". All graphics functions and default view information are held in a class called xgraphics . graphics is a subclass of xgraphics and inherits all its properties.

Altering Defaults

It is possible to alter the defaults which are defined in the xgraphics class directly, but it is preferable to leave these alone. There are two methods that can be used, the first is to work in the subclass graphics , so that default values can be restored from xgraphics (or by removing the properties from graphics - which has the same effect). The other method is to define subclasses in which defaults can be changed and restored to the graphics default in the same way.

> ( graphics help)               -- information
> (graphics view_to ´(10 2 5))   -- default value changed
> (graphics view_to (xgraphics view_to))
                            -- default retrieved from xgraphics

> (define my_view graphics) 
   -- define subclass of graphics with all graphics functions
> (my_view select)         -- select my_view
> (my_view help view_to)   -- help on graphics property view_to
> (my_view view_to ´(1 1 1 ))    -- reset view_to
> (my_view - view_to )           -- removes local setting

Current View

KID allows one class to be the current view. All interaction with GRA is in terms of the attributes (local or inherited) of this current view.

> (graphics current_view)
    --> returns the name of the current view

[back to top]

11.3 Output Devices

When KID creates and selects the first view (i.e. graphics) it opens a null device to send its output to. It is possible to open and close other devices, and to send output simultaneously to a number of devices. This and other device dependent KID functions are described in Appendix F, "Machine Dependency in KID".

Framemaker, Interleaf, Laser, Plot and Postscript

These graphics functions are designed to write graphical output to a file in a specified format. Each function takes a text argument which is used for the output filename. The output is equivalent to that which would result from a (graphics redraw) command.

> (define b0 p_block)          -- define a block
> (b0 create)                  -- create it
> (graphics sketch ´b0; ar)    -- sketch it
> (graphics laser "block.ln3") -- output the sketch to the file 
                                  block as a pixel file
> (graphics zoom 0.5)          -- expand the view  
> (graphics postscript "post.pst") 
                         -- output the postscript commands for
                            the expanded view to the file post

The postscript output files are, at least, minimally conforming to the postscript file structuring conventions.

If all output is to be sent to a file then one of the plotter , laser , postscript , interleaf and framemaker devices can be used. These are opened and closed with the commands:

> (graphics open_device ´<device_name>)
> (graphics close_device ´<device_name>)

Once a device has been opened the graphical output is sent, in addition to any open display devices, to a file (plot_file, pixel_file, postscript_file, interleaf_file and framemaker_file respectively). The default files (which have no extension) may be changed, prior to opening the device, by a command of the form:

> (graphics postscript_file "output.pst")

It is important to close the device before leaving the KID session to ensure that the correct termination commands are appended to the output file. It should also be noted that all images sent to the file are superimposed.

[back to top]