Registering the Frustrum

Contents

• 5.1 Introduction
• 5.2 Object-file frustrum
• 5.3 Registered frustrum
• 5.4 Application I/O
• 5.5 Indexed I/O

[back to top]

5.1 Introduction

The application writer has several options for providing the Frustrum functions for Parasolid to use.

[back to top]

5.2 Object-file frustrum

When Parasolid is used as an object-file library, the Frustrum, GO and Foreign Geometry functions must also be compiled and linked with it. These functions are specified in Appendix A, “Frustrum Functions” and Appendix B, “Graphical Output Functions”.

The functions can be split into logical groups, as shown in the following table:

Simple functions are provided for initial testing in the files frustrum.c and fg.c in the Parasolid release area.

[back to top]

5.3 Registered frustrum

Parasolid may be supplied as a shared image as well as an object-file library.

If the following method is used to provide a registered frustrum, the functions do not need to have the 6-letter FORTRAN-style names.

Parasolid still needs to call the Frustrum, GO and Foreign Geometry functions but the image must use a different mechanism to the object-file library. This is done using the PK functions PK_SESSION_register_frustrum or PK_SESSION_register_fru_2. The installed Frustrum can then be identified using the PK functions PK_SESSION_ask_frustrum or PK_SESSION_ask_fru_2.

There is an example of registering the Frustrum using PK_SESSION_register_frustrum included in the file parasolid_test.c in the Parasolid release area.

A C structure is defined, with an element for each required function, and the application must register this with Parasolid before starting the modeller. This mechanism can also be used with the supplied object-file library: it is not specific to the shared image implementation. The advantages to the application of using a registered frustrum are that:

• The application-supplied functions no longer need to have the six letter FORTRAN-style names (as specified in the “Frustrum Functions” chapter).
• The application no longer needs to supply all the specified functions: e.g. if the application uses the PK_DELTA_* functions for partitioned rollback, the functions FFOPRB, FFSEEK and FFTELL need not be registered.

All applications must supply equivalents of FMALLO and FMFREE. An application can omit group of functions as required.

If a non-registered function is accessed, Parasolid may fail with PK error code PK_ERROR_fru_missing. As an example, an application that does not make use of Foreign Geometry might receive a part from another application that does.

An application using the shared image can replace the Parasolid image with an updated version without relinking. It is important that the Parasolid version in the new library is later than the old one. To guard against an incompatible combination, the application can enquire the version number of the installed Parasolid using PK_SESSION_ask_kernel_version. For example:

PK_SESSION_kernel_version_t info;

PK_SESSION_ask_kernel_version (&info);

if (info.major_revision<9)

    {

    fprintf (stderr, "Parasolid v9 is required");

    exit (EXIT_FAILURE);

    }

This function may be called at any time, in particular, without starting the modeller, by calling this function in the shared image.

If you wish to transmit and receive embedded mesh data, or optimally transmit and receive mesh data, you need to register the frustrum seek function FFSKXT using PK_SESSION_register_fru_2. This frustrum allows for the optimised transmitting and receiving of binary XT files that contain embedded meshes. You can identify the installed frustrum using PK_SESSION_ask_fru_2.

If you wish to call Parasolid’s rendering and faceting functions concurrently, or to use SMP when generating graphical output, you can indicate that the GO functions, GOSGMT, GOOPSG and GOCLSG, are thread-safe using the go_thread_safe option in PK_SESSION_register_fru_2. Where practical, we recommend a thread-safe GO implementation to allow your application to benefit from the full set of performance optimisations available in Parasolid.

[back to top]

5.4 Application I/O

There is a transmit file format called ‘application i/o’, or ‘applio’. When this format is selected in PK_PART_transmit and PK_PARTITION_transmit, transmit files are written and read using a suite of functions provided by the application. Using these functions enables the application to do further processing of the output data before storing it.

The functions open files, read and write chars, bytes, shorts, ints and doubles to/from these files, and close the files; they are registered using PK_SESSION_register_applio.

Note that the application is responsible for any conversion required between machine types (e.g. for endian byte ordering and floating point representation). The read functions must be handed the correct number of computation-ready data items, as written out by the write functions.

Snapshot files cannot use this format - they must be text or machine-dependent binary.

[back to top]

5.5 Indexed I/O

There is also a transmit file format called indexed i/o, or indexio. When this transmit_format is selected in PK_PART_transmit and PK_PARTITION_transmit, transmit files are written using a suite of functions provided by the application. Using these functions enables your application to subsequently receive only specified faces from the parts contained in the transmitted files.

The functions open files, read from and write to these files in both Unicode and non-Unicode format, and close the files; they are registered using PK_SESSION_register_indexio.

[back to top]