PHIGS
PHIGS, or Programmer's Hierarchical Interactive Graphics System, is an international standard defining an application programming interface (API) for rendering and interacting with 2D and 3D computer graphics, emphasizing hierarchical structures for modeling complex scenes.[1] Developed to promote portability across diverse hardware and software environments, it provides approximately 400 functions for defining graphical primitives, managing attributes like color and orientation, and supporting dynamic modifications without redrawing entire displays.[1][2] The standard emerged in the 1980s as an advancement over the earlier Graphical Kernel System (GKS), incorporating hierarchical modeling capabilities to better suit applications in computer-aided design (CAD), simulation, and scientific visualization.[3][2] Its development was led by the International Organization for Standardization (ISO) and the International Electrotechnical Commission (IEC), with key contributions from bodies like ACM SIGGRAPH's Graphics Standards Planning Committee.[3] The core PHIGS standard, ISO/IEC 9592:1989, specified device-independent functions for data interchange between applications and graphics support systems, enabling consistent output on devices ranging from plotters to interactive screens.[3] In 1992, the standard was extended with PHIGS PLUS (ISO/IEC 9592-1a to 9592-4:1992), adding support for advanced features such as lighting, shading, and texture mapping to enhance realism in 3D rendering.[3] Adopted as a U.S. Federal Information Processing Standard (FIPS PUB 153-1) in 1995, PHIGS facilitated cost-effective development by allowing programs to run across installations without hardware-specific adaptations, though its adoption waned in the 1990s with the rise of more flexible APIs like OpenGL.[1] Despite this, PHIGS remains influential in legacy systems and as a foundational model for hierarchical graphics programming.[3]Overview
Definition and Purpose
PHIGS, or Programmer's Hierarchical Interactive Graphics System, is an international standard defining an application programming interface (API) for retained-mode 2D and 3D computer graphics, enabling the creation, storage, manipulation, and display of hierarchical scene descriptions in a device-independent manner.[4] As specified in ISO/IEC 9592-1, it provides a set of functions for defining and manipulating geometrically defined 2D and 3D pictures, supporting operator input and interactions through a centralized database of graphical elements rather than immediate-mode rendering. This retained-mode approach stores complete scene hierarchies, allowing efficient updates and interactions without redrawing the entire image from scratch.[5] The primary purpose of PHIGS is to facilitate the development of portable graphics applications that can operate across diverse hardware and software environments, thereby reducing development costs and promoting interoperability in complex visualization tasks.[4] It targets applications demanding sophisticated 2D and 3D modeling and interaction, such as computer-aided design (CAD), scientific simulations, engineering design, molecular modeling, and process control systems, where hierarchical data structures enable the representation of intricate relationships like assemblies in CAD or dynamic simulations in scientific computing.[2] By emphasizing database-driven graphics, PHIGS supports rapid modifications, geometric articulation, and multi-level hierarchies, making it suitable for workstation-based environments prevalent in the 1980s.[5] In scope, PHIGS encompasses modeling through geometry creation and hierarchical organization, viewing via transformations and projections for scene rendering, and interaction mechanisms for user input directly on stored structures, all while extending 2D graphics concepts to full 3D capabilities. Its key goal is to deliver a standardized, portable interface that abstracts hardware specifics, ensuring consistent behavior for hierarchical graphics across implementations and fostering widespread adoption in professional graphics programming.[4]Core Principles
PHIGS operates in a retained-mode paradigm, where graphical elements are persistently stored in a Centralized Structure Store (CSS) rather than being immediately rendered upon creation. This database serves as a hierarchical repository for graphics data, enabling applications to build, edit, and update structures without the need to regenerate the entire scene for each display cycle. The CSS allows for efficient manipulation, such as inserting, deleting, or modifying elements, which supports dynamic applications by minimizing computational overhead during interactions.[6][7] Central to PHIGS is its hierarchical modeling approach, organizing graphical objects into tree-like structures with parent-child relationships. Transformations applied to a parent node, such as rotations or scalings, are inherited by all child elements, facilitating the representation of complex scenes like assemblies in CAD systems. This structure enables traversal and editing at various levels, promoting modularity and reuse of graphical components across different views or workstations.[4][6] Device independence is achieved through an abstraction layer that separates application logic from hardware specifics, using the concept of workstations to interface with diverse output devices, including vector and raster types. Applications specify graphics in a device-neutral manner, with PHIGS handling the mapping to physical devices via transformations and bundle tables, ensuring portability across platforms.[4][7] The system maintains a graphics state that captures current attributes, such as color, line style, and transformation matrices, which apply to subsequent primitives until explicitly changed. This state is managed across structures and workstations through description tables and operating modes, allowing consistent rendering and easy attribute inheritance within hierarchies.[6][7] PHIGS emphasizes interactivity by supporting real-time picking and editing of stored structures, where users can select elements via logical input devices and modify them directly in the CSS. Features like event-driven input modes enable rapid feedback, such as echoing picked points or updating views, making it suitable for interactive applications like simulations and design tools.[4][6]History
Development Origins
PHIGS originated as an extension of the Graphical Kernel System (GKS), a 2D graphics standard developed from 1977 to 1985 under international efforts led by organizations including the International Organization for Standardization (ISO). Recognizing the limitations of GKS for handling three-dimensional (3D) graphics, development of PHIGS began in 1980 to address emerging needs in interactive 3D visualization.[8] This evolution was driven by the ANSI X3H3 committee, which adopted GKS concepts and initiated work on a 3D successor under American National Standards Institute (ANSI) procedures.[8] Key contributors to PHIGS's early development included international graphics standards bodies, with significant input from the Association for Computing Machinery's Special Interest Group on Computer Graphics (ACM SIGGRAPH) and national committees focused on portability across hardware. These efforts were motivated by growing demands for 3D graphics in fields such as engineering design and aerospace simulation, where hierarchical modeling could support complex scene management. The initial design phase, spanning 1980 to 1985, centered on extending GKS's input-output model to incorporate 3D transformations and interactive hierarchies, with early prototypes tested in academic and industry laboratories to validate core functionalities.[8] Developers emphasized retaining GKS's device-independent abstractions while introducing support for dynamic scene updates. Early challenges involved balancing portability across diverse systems with the performance requirements of real-time 3D transformations, which ultimately led to the adoption of structure networks—a hierarchical approach—over simpler flat lists to efficiently manage parent-child relationships in 3D models.[8] This design choice addressed inefficiencies in non-hierarchical representations but required careful optimization to avoid computational overhead in interactive applications.Standardization Process
The standardization of PHIGS began with its adoption by the American National Standards Institute (ANSI) as ANSI X3.144-1988, which defined the core functional specifications for the graphics system to promote interoperability among application programs.[5] In 1989, the U.S. government further endorsed it through Federal Information Processing Standard (FIPS) 153, mandating its use in federal systems to ensure portability of graphics software across hardware platforms.[5] Parallel to ANSI efforts, PHIGS progressed within the International Organization for Standardization (ISO) framework, culminating in ISO/IEC 9592 published in 1989, which outlined the functional specification (Part 1), archive file format (Part 2), and clear-text encoding (Part 3).[9] This multi-part standard evolved through the 1990s, with minor revisions for clarity and completeness; for instance, Part 1 was updated in 1997 to refine the nucleus of graphics functions while maintaining backward compatibility.[10] Language bindings were separately addressed in ISO/IEC 9593, starting with FORTRAN (Part 1) and Ada (Part 3) in 1990, followed by C bindings in subsequent amendments to embed PHIGS into diverse programming environments.[11] Enhancements came via PHIGS+, formalized as ISO/IEC 9592-4 in 1992, which extended core capabilities for advanced lighting and surface rendering without altering the base architecture.[12] The entire process was coordinated through the ISO/IEC JTC 1/SC 24 committee (formerly TC 97/SC 24), facilitating international harmonization by aligning PHIGS with European (via CEN) and Japanese standards to achieve cross-platform compatibility and global adoption in computer graphics applications.[3]Technical Architecture
Hierarchical Structure Storage
The Centralized Structure Store (CSS) in PHIGS serves as a server-side database that maintains all picture structures, enabling centralized management of graphical data across applications and workstations. This store holds hierarchical models composed of primitives, attributes, and control elements, ensuring that graphics data remains persistent during PHIGS sessions without direct user manipulation of underlying storage for enhanced portability. Access to the CSS occurs through structure management functions, such as opening a structure for editing, which implicitly creates it if it does not exist by specifying a unique integer identifier.[13][14] Structures in the CSS form a hierarchy where elements are sequentially organized and can invoke other structures via execute elements, allowing for reusable components, multiple instances of the same structure, and even cycles in the hierarchy to support complex scene graphs. Each element can be labeled with a unique identifier using functions like set label, facilitating targeted operations such as picking or editing. Transformations within the hierarchy are specified using 4x4 matrices for 3D homogeneous coordinates, applied cumulatively during structure traversal to position and orient elements relative to their parents. This design promotes modularity, as invoking a structure (e.g., via pexecute_structure) inherits the calling context, including current transformation state.[15][13] Editing operations on structures are performed while a structure is open, using an element pointer to navigate and modify content in modes like insert or replace, set via pset_edit_mode. Elements are added by invoking primitive-specific functions (e.g., ppolyline for polylines or pset_local_trans for transformations), which append or replace elements at the current pointer position; deletion removes elements ahead of the pointer with pdelete_elem, while copying uses pcopy_all_elems_from_ref for duplicating content from another structure. Traversal for inquiry or modification employs functions like pinq_elem_name to retrieve details. Each element supports visibility and highlighting flags, controllable via pset_visibility and pset_hlh_ans, allowing selective rendering or emphasis without altering the core data.[16][17] Memory management in the CSS relies on integer identifiers for structures, with no user-direct access to internals to maintain implementation independence across systems. Opening a structure (popen_struct) establishes an edit session with an initial element pointer at the beginning, and closing it (pclose_struct) finalizes changes, committing them to the store; multiple structures can exist simultaneously, but only one is open for editing at a time. Upon closing PHIGS (pclose_phigs), the CSS is cleared unless archived externally, emphasizing its role as a session-bound resource rather than permanent storage.[13][14]Primitives and Transformations
PHIGS defines a set of fundamental output primitives designed for constructing 3D graphical scenes, emphasizing geometric simplicity and compatibility with hierarchical structures. The core primitives include 3D polylines, which connect sequences of vertices to form line segments; polymarkers, which place symbolic glyphs at specified 3D points; text elements positioned and oriented in 3D space; and filled or unfilled polygons represented as fill areas. Additionally, faceted surfaces are constructed using fill area sets, allowing multiple polygonal boundaries to approximate complex 3D shapes through planar facets. Notably, the base PHIGS standard excludes curved primitives such as splines or NURBS, restricting users to piecewise linear approximations for smooth surfaces.[14][18] These primitives are manipulated through a transformation pipeline that applies successive 4x4 homogeneous matrices to map coordinates from the modeling space to the final device output. The pipeline begins with modeling transformations, which operate locally on objects to define their position, orientation, and scale relative to the world coordinate system; common operations includeptranslate for vector displacements, pscale for non-uniform scaling about a fixed point, and protat (or equivalent rotations) about principal axes. This is followed by viewing transformations, which establish the observer's perspective by specifying eye position via a view reference point and applying projection (parallel or perspective) to define the view volume. Workstation transformations then map the normalized projection coordinates to device-specific coordinates, incorporating viewport specifications for display adaptation. All transformations compose via matrix multiplication, enabling efficient hierarchical application during structure traversal.[14][19]
Clipping in PHIGS ensures only relevant geometry is processed, with volumes defined as convex polyhedra (up to six planes) in world or normalized projection space or as frustums bounded by front, back, and side planes in the view volume.[14][19]
Input and Output Mechanisms
Input Device Handling
PHIGS defines six classes of logical input devices to abstract physical input hardware, enabling applications to interact with users in a device-independent manner. These classes include the locator, which returns a position in world coordinates (WC); the stroke, which captures a sequence of WC positions; the valuator, which provides a scalar value such as from a dial or slider; the choice, which selects an integer option from a predefined set; the pick, which identifies graphical elements within a structure; and the string, which inputs character sequences from a keyboard.[14] Each class maps one or more physical devices, such as a mouse or tablet, to the logical abstraction via the workstation description table, supporting portability across hardware.[14] Each logical input device operates in one of three modes: sample, request, or event, inherited from the GKS input model to provide flexible synchronization options. In sample mode, the application immediately retrieves the current device state without blocking, suitable for continuous monitoring. Request mode is synchronous, blocking the application until input arrives or a break occurs, with the device dedicated to the requesting process. Event mode enables asynchronous operation, queuing inputs for later retrieval by any process, using a centralized FIFO queue across workstations.[14] Visual or audible echoes provide immediate feedback during input, such as a cursor for locators or a digital display for valuators, configured during device initialization and clipped to a defined echo area.[14] Input is processed through polling and prompting functions, with event queues managing asynchronous data. Polling uses functions likepget_locator or pget_valuator to sample or request data directly from the device, returning the input value along with status information. Prompting initializes devices via pin_ functions, such as pin_choice, setting parameters like sampling filters or echo specifications before activation. In event mode, inputs are stored as event reports in a nucleus-managed queue, retrievable via GPAWEV to await and transfer the next event, including device identifier and data.[14] Queues support flushing with GPFLEV for device-specific events or GPFWEV for workstation-wide, allowing filtering of irrelevant inputs.[14]
Device mapping employs user-defined transformations to convert physical device coordinates (DC) to the logical input space, typically WC, ensuring consistency with the graphical scene. For locator and stroke devices, an inverse viewing transformation applies the view matrix of the highest input priority among open structures. Pick devices use a DC-based aperture transformed through the hierarchy to identify elements. Multiple workstations are supported, with each capable of independent device configurations and queue management, serializing access via the PHIGS nucleus.[14] Asynchronous event handling may invoke user-defined callbacks through GPEVHN for custom processing, with events prioritized by timestamp and filtered by class or device to handle high-volume inputs efficiently.[14]
| Logical Input Class | Returned Data Type | Typical Physical Devices | Transformation to WC |
|---|---|---|---|
| Locator | Position (x, y, z) | Mouse, tablet | Inverse view matrix |
| Stroke | Sequence of positions | Stylus, pen plotter | Inverse view matrix per point |
| Valuator | Scalar (real) | Dial, slider | None (direct mapping) |
| Choice | Integer selection | Buttons, menu | None |
| Pick | Path and element ID | Cursor | Pick aperture in DC |
| String | Character string | Keyboard | None |
Output and Rendering Pipeline
In PHIGS, the workstation model abstracts graphics output devices, categorizing them as output-only, input-only, or input-output workstations, with the open workstation functionpopen_ws initializing the device by associating it with a central structure store and establishing initial parameters such as the workstation type and capabilities. This setup enables the system to manage rendering independently of specific hardware, supporting devices like raster displays or vector plotters. Update modes control how changes to the structure store trigger redraws: deferred mode delays updates until explicitly invoked to minimize unnecessary computations; additional mode applies incremental changes either globally (before next interaction globally) or locally (before next interaction locally); and single mode performs immediate updates after each modification.
The rendering process begins with traversal of the central structure store (CSS), where posted structures are processed hierarchically starting from designated roots, applying element types such as labels (no action), register modifications (for attributes or transformations), primitive drawing, or structure invocations. During traversal, geometric primitives from the structures—such as polylines or polygons—are transformed through a sequence of coordinate systems: from modeling coordinates (MCS) to world coordinates (WCS) via modeling transformations, then to viewing coordinates (VCS) and normalized projection coordinates (NPC) via viewing mappings defined by pset_view, which supports multiple independent views per workstation with configurable view volumes, projection types, and clipping boundaries. Primitives are clipped against view volumes or user-defined clip planes in VCS, after which the workstation transformation maps normalized coordinates to device coordinates (DCS), followed by rasterization for pixel-based devices or vectorization for line-drawing outputs, ensuring device-specific optimization.
Output attributes govern the visual appearance of rendered primitives and are managed through bundle tables for efficient device mapping. Line width is specified as a scalable factor, adjusted relative to a base width and mapped to the nearest supported device value. Color is represented via indices referencing a workstation color table, supporting up to 256 indices in the base standard for RGB or other models. Fill styles for areas include options like hollow, solid, patterned, or hatched, with patterns defined by bitmaps or predefined indices. Bundling groups these attributes (e.g., line bundle for polylines, interior bundle for polygons) into tables, allowing individual or inherited application during traversal to optimize transmission to the device and reduce redundancy.
Performance in the rendering pipeline relies on deferred updates, which buffer modifications in the CSS and only regenerate the display upon explicit calls like pupdate_ws, thereby minimizing full redraws during interactive editing. This approach suits hierarchical structures by avoiding repeated traversals for unchanged elements. Base PHIGS lacks built-in double buffering, requiring applications to implement custom techniques for flicker-free animation if needed on raster devices.