1.0 Introduction

2.0 Connecting Parasolid to the HOOPS/3dGS

2.1 HOOPS/Parasolid Frustrum Implementation
2.2 HOOPS/Parasolid GO Routines
2.3 Synchronizing Parasolid and HOOPS/3dGS
2.4 HOOPS Segment Structure Generated
2.5 Mapping of Parasolid Entities to HOOPS Geometry
2.5.1 PK_Faces and PK_Bodies
2.5.2 PK_Edges
2.5.3 PK_Vertices

1.0 Introduction

The HOOPS/Parasolid Bridge encapsulates the work needed to connect the Parasolid (R) Kernel Modeler from UGS to HOOPS/3dGS as well as connecting Parasolid to a particular operating system. The HOOPS/Parasolid Bridge API enables the developer to control the manner in which Parasolid's geometric tessellation is mapped to HOOPS primitives and to find exactly which HOOPS entity corresponds to which Parasolid entity and vice versa. The HOOPS/Parasolid Bridge is supplied as a dynamic linked library (dll) with an exposed API.

The following section gives technical details on how the connection between Parasolid and HOOPS/3dGS has been designed, including a reference manual for the routines in the HOOPS/Parasolid Bridge API. 

The HOOPS/Parasolid Reference Applications are a set of applications built with the components of the HOOPS 3D Application Framework, Parasolid and various GUI toolkits. They show how to build applications for the MS Windows and UNIX platforms, include clear source for the application code and can be used as a prototyping tool as well as the base architecture for new applications.


2.0 Connecting Parasolid to HOOPS/3dGS

The architecture of Parasolid defines two sets of routines, called the Parasolid Downward Interfaces, that must be implemented in order to use the modelling kernel. They are called the Frustrum and the Graphical Output Routines, or GO Routines. The Frustrum routines connect Parasolid to the operating system and the GO Routines connect Parasolid to a graphics subsystem, in this case the HOOPS 3D Graphics System. 

The HOOPS/Parasolid Bridge provides implementations of both the Frustrum and GO Routines for the MS Windows and UNIX operating systems.
 

2.1 HOOPS/Parasolid Frustrum Implementation

Parasolid requires several connections to the operating system for tasks such as file I/O and memory allocation. These connections are implemented as a set of platform specific routines. This set of routines is called the Frustrum and must be implemented by the application developer. 

The implementation of the Frustrum is specific to the target operating system and cross platform development requires unique implementations for each supported platform.
The HOOPS/Parasolid Bridge contains a full implementation of these routines for the Microsoft Windows and UNIX operating systems.
 

2.2 HOOPS/Parasolid GO Routines

Parasolid provides no visual rendering or printing capabilities. The modeler instead outputs tessellated geometric information via the Parasolid Graphical Output (GO) Routines. Calling the Parasolid PK_TOPOL_render_xxx routines cause the modeler to traverse all or part of the information currently in memory and tessellate the geometry for output to a computer monitor or printer. The developer must supply routines which accept this information and then manage the display, interaction and printing of this information on computer monitors and printers. 

The HOOPS/Parasolid Bridge includes an implementation of the GO Routines, which use the HOOPS 3D Graphics System for storing, rendering, interacting with and printing of the tessellated geometry generated by Parasolid. The tessellation of the Parasolid model is cached in the HOOPS/3dGS and all direct interactivity with the visual representation of the model occurs via the HOOPS/3dGS. HOOPS also includes output drivers for several hardcopy formats including Postscript and HPGL, which are used to communicate with printing devices.

A key aspect of the value of the integration of Parasolid and HOOPS is in the implementation of the GO Routines. They have been designed to optimally map the Parasolid tessellated information to the HOOPS graphical database, which is itself designed to optimally store and manage such graphical data . 

2.3 Synchronizing Parasolid and HOOPS/3dGS

The HOOPS/Parasolid Bridge routine HP_Render_Entities will initiate the flow of geometric information from Parasolid to the HOOPS/3dGS. The HP_Render_Entities routine accepts a list of Parasolid entities and then calls the Parasolid PK_render_topol routines, which in turn causes the tessellation of Parasolid entities to flow to the HOOPS/3dGS via the Parasolid GO routines.

2.4 HOOPS Segment Structure Generated

When Parasolid Entities are rendered via the HP_Render_Entity routine, the HOOPS/Parasolid Bridge assumes an open HOOPS segment. The HOOPS/Parasolid Bridge then creates a segment structure underneath the currently open segment and populates it with geometry corresponding to the Parasolid entities rendered.

The HOOPS/Parasolid Bridge API provides control over how the Parasolid entities are mapped to HOOPS via the routine HP_Set_Rendering_Options. The actual segment structure generated under the open segment depends on which options are chosen. 

As the HOOPS/Parasolid Bridge assumes the existence of an open HOOPS segment, the user has maximum flexibility over the structure of the top part of the HOOPS segment tree. For instance, an application working with assemblies of Parasolid bodies will create the appropriate assembly structure in the HOOPS segment tree and then open the appropriate segment in the tree when rendering bodies for the individual parts of the assembly.
 

2.5 Mapping of Parasolid Entities to HOOPS Geometry

To give the user maximum flexibility in their implementation, mappings are maintained between HOOPS and Parasolid entities. This is so that, for example, someone could pick on the HOOPS graphics on the screen and perform operations on the corresponding Parasolid geometry. The HOOPS/MVO library includes several Operator classes that make use of the entity mapping between Parasolid and HOOPS to implement sophisticated application level features.

Parasolid and HOOPS both use handles for accessing their entities; Parasolid entities are said to have "Tag IDs" and HOOPS entities are said to have "keys". The HOOPS/Parasolid Bridge routines HP_Compute_TagID and HP_Compute_Geometry_Keys can be used for converting Parasolid TagID's to HOOPS keys and vice versa.

The HOOPS/Parasolid Bridge maps the geometric tessellation of all Parasolid entities to HOOPS, inserting a new HOOPS geometric primitive into the HOOPS database for each PK_Entity. The following section gives details on how each of the Parasolid PK_Entities are mapped to HOOPS geometric primitives.

2.5.1 PK_Faces and PK_Bodies

In applications which provide highly interactive functionality such as model creation, view and markup, and dimensioning, the modeler operations will be creating, deleting and modifying PK_Faces frequently and the amount of data flowing from Parasolid to HOOPS should be minimized. This is accomplished by mapping all the tessellated geometry associated with one PK_Face to one HOOPS shell. An additional optimization step ensures the minimum amount of vertices are used and that the longest triangle strips possible may be computed internally by HOOPS for optimal rendering. 
Conversely, for applications which only require viewing of Parasolid models all the tessellated geometry associated with all the PK_Faces in one PK_Body can be mapped to one HOOPS shell. This results in a reduction in number of vertices for complex PK_Bodies and can increase rendering through-put. It is anticipated that this mode will be useful to applications primarily focused on viewing & querying model or assembly data, i.e., the Virtual Prototyping and View/Markup sectors. 

2.5.2 PK_Edges

PK_Edges map to one of the following HOOPS primitives depending on the form of their tessellated geometry generated by the Parasolid modeler. 

2.5.3 PK_Vertices

PK_Vertices do not appear in the GO Routines. If graphical display of these entities is desired, the application must use the appropriate PK_Query routines and manually insert HOOPS geometry, typically markers, to represent them.