THE NON-NATIVE GEOMETRY FACILITY
A recently added feature of the SSV2 and CASPA systems is the
ability to make use of surface geometry definitions which are not
part of the native geometry of the system. The only requirements
are that the surfaces are parametric with rectangular patches and
that the user is able to provide supporting software in the form
of a parametric evaluator capable of evaluating points and
derivatives at any point on the surface with parametric value
(u,v). The data defining the surface will have been previously
created as a data file and must conform to a simple basic format
which is meaningful to the parametric evaluator. Once a non-native
surface has been defined in this way it can be used in machining
and other operations in exactly the same way as any of the native
sculptured surfaces of the system. An important advantage of this
approach is that surfaces from an external definition system can
be machined exactly by the APT system with no approximation errors
as occurs in most forms of inter-system surface data transfer.
Each new non-native surface type requires two specific routines,
one to interpret the data and evaluate points and derivatives on
the surface, the other to modify the data when an APT
transformation matrix is applied. These subroutines called the
evaluator and the transformator must be compiled and linked with
the sculptured surfaces system. In the IBM version of the system
dynamic loading of the evaluators is possible, with the VAX
version a seperate re-linking of the system and evaluators is
A data file for each surface referenced must be available at run
time, this has a form similar to that of an LDA and will normally
have been created by a program external to the sculptured surfaces
system. Parts of the format for these data files is precisely
defined and are a system requirement, other parts are dependent
upon the surface type and will only be meaningful to the
appropriate evaluator. The paragraphs below give the subroutine
and data file specifications in detail. Section 11.2 contains an
extended example of the creation and use of a non-native surface.
Section 11.3 contains details of the VDA-FS Non-native Interface.
This subroutine must have a name ENAME which begins with an E, the
remainder of the name 'NAME' being unique for the particular
surface type. Each evaluator must have the same parameter list
U,V should be declared as double precision and on input contain
the (U,V) parameter values which define the evaluation point P on
the selected patch.
GEO is a one dimensional double precision array, declared as
GEO(*) or more properly as the precise dimension of the patch
geometry data, which at run time will contain the patch geometry
data as read from the data file, or as modified by TNAME.
RESULT(4,8) is a double precision array which returns the
coordinates of the point P and the values of the derivatives at
this point. The detailed contents of this array on exit from ENAME
RESULT(1-4,1) Homogeneous coordinates X,Y,Z,W of the point P.
RESULT(1-4,2) Partial derivatives dX/dU, dY/dU, dZ/dU, dW/dU at P.
RESULT(1-4,3) Partial derivatives dX/dV, dY/dV etc at P.
RESULT(1-4,4) 2nd Partial derivatives d2X/dU2, d2Y/dU2 etc at P.
RESULT(1-4,5) 2nd mixed partial derivatives d2X/dUdV,d2Y/dUdV etc
RESULT(1-4,6) 2nd Partial derivatives d2X/dV2, d2Y/dV2 etc at P.
RESULT(1-3,7) Surface normal dr/du x dr/dv at P.
RESULT(1-3,8) Surface unit normal at P.
RESULT(4,8) 1.0 if unit normal available, 0.0 otherwise.
MODE should be declared as INTEGER, this is an input argument,
if MODE=0 on input only the point coordinates are evaluated,
if MODE=1 points and derivatives and normals are evaluated.
Note: The information contained in RESULT is sufficient for most
applications. For example it provides the ability to compute the
shortest distance from a point to the surface or to find the
curvature of the surface at P.
This subroutine must have a name TNAME beginning with T in which
'NAME' is the same as in ENAME.
The parameter list is:
TRANS(4,3) should be declared as a DOUBLE PRECISION (4,3)
two dimensional array. On input it contains an
APT transformation matrix (See section 3.5)
GEO Is a one dimensional DOUBLE PRECISION array
declared as in the evaluator subroutine. On input
GEO contains the patch geometry data as read from
the data file. On exit this is overwritten with
the geometry data as modified by the translation
and rotation defined by the transformation matrix
Each data file is normally produced by an external formatter
routine FNAME where 'NAME' is shared with ENAME and TNAME for this
particular surface type. In simple cases, as in section 11.2 FNAME
will actually define the surface and generate the data, in other
cases it is a routine which re-formats data which has been
produced by another geometric definition system. The data file
produced must have the same general format as an APT surface and
consists of a surface header block, a header block and geometry
block for each patch and, finally, a block of topology data. The
layout of the header blocks and the topology block are rigidly
specified by the sculptured surfaces system but the patch geometry
block layouts and interpretation are completely dependent upon
The surface header block consists of precisely 10 DOUBLE PRECISION
numbers, these are:
SHEAD(1) = APT RECORD NO. (Assigned by system)
SHEAD(2) = Total length of geometry data
SHEAD(3) = Total length of topology data
SHEAD(4) = Number of patches
SHEAD(5) = 2.0
SHEAD(6) = 1.0
SHEAD(7) = Sign of surface normal (1.0 or -1.0)
SHEAD(8) = Total length of data
SHEAD(9) = Number of splines
SHEAD(10) = Number of cross splines
The surface header block is followed, patch by patch, by the patch
header blocks. For each patch this block consists of a fixed
length header block of 6 DOUBLE PRECISION numbers. These must be
PHEAD(1) = Index of start of patch geometry data in file.
PHEAD(2) = 0.0
PHEAD(3) = 0.0
PHEAD(4) = 0.0
PHEAD(5) = Coded version of surface type 'NAME'.
PHEAD(6) = Index of start of patch topology data.
The set of patch header blocks is followed patch by patch by the
geometric data for each patch. This can be of any length provided
it can be correctly interpreted by the evaluator and transformator
routines. The detailed contents of this geometric data is not
specified in any way and will depend upon the type of non-native
surface being used.
After the last block of geometric data comes the topology table.
For each patch this table takes the same format as a standard
surface canonical form and consists of 4 consecutive real numbers
which give in turn the number of the patch adjacent to each
boundary. The boundaries are ordered as v=0, u=0, u=1, v=1, 0.0 is
stored as the adjacent patch number for any patch boundary
coinciding with the edge of the surface.
A simple example of non-native geometry definition and evaluation
has been included with the SSV2 system release tape. The relevant
subroutines are program FTORUS, which is an interactive routine
external to the system and enables the user to define a parametric
surface which forms part of a torus (or doughnut). The data
created is then evaluated by the routine ETORUS and, if necessary
can be rotated or translated by the routine TTORUS. ETORUS and
TTORUS are linked and loaded with the SSV2 system.
A torus of major radius R and minor radius r has a parametric
r(u,v) = c + rsinua + cosv(R + rcosu)b - sinv(R + rcosu)d
where c is the position vector of the centre, a is a unit vector
in the direction of the axis of symmetry, b, d are mutually
perpendicular unit vectors in the plane perpendicular to a.
The program FTORUS constructs a parametric surface of this type
which consists of precisely 4 patches, two in the u-direction and
two in the v-direction. The user is able to specify interactively
the basic dimensions, position and orientation of the surface and
how much of the torus is to be represented.
FTORUS has two subsidiary routines DEFTOR and PUNTOR which are
responsible respectively for the actual geometric definition and
for storing the data generated in APT4 LDA format to APTLIB. When
running FTORUS the user receives a number of prompts for input
data, these together with possible responses are illustrated in
section 11.2.1 .
Before running the program FTORUS the user should create a
sub-directory .APTLIB!, if it does not already exist. In the
example below screen prompts are shown in upper case, user
responses are enclosed in ! and explanatory notes are in lower
The initial command RUN FTORUS produces the informative response
THIS PROGRAM SETS UP THE CANONICAL FORM OF A TORUS AS 4 PATCHES
AND CREATES AN APT4 LDA EXTERNAL FILE IN APTLIB
INPUT MAJOR AND MINOR RADII OF TORUS 30.0,10.0!
The user defines the major radius as 30, the minor as 10.
AXIS OF SYMMETRY VECTOR? 0.0,0.0,1.0!
The OZ axis has been chosen as the direction of the axis of
symmetry. Any 3 vector components are permissible, the user need
not supply a unit vector.
CENTRE OF TORUS? 0.0,0.0,0.0!
The origin has been selected here as the centre C, any 3
coordinates are permissible.
REF POINT (START OF PARAMETERISATION, I.E. U=0, V=0)?
The user is asked to supply a point P such that CP is in the
direction of the edge of the toroidal section and is normal to the
axis. If P is incorrectly defined the system projects CP onto the
central plane of the torus in order to find a reference point. In
this case OX has been chosen as the direction of the reference
UMAX, VMAX (IN RADIANS)?
NOTE: U-MINOR RADIUS DIRECTION
V-MAJOR RADIUS DIRECTION 3.1416,3.1416!
UMAX and VMAX define the total extent of the surface. For a
complete torus UMAX=VMAX=2p. In this case half a torus is being
defined with a semi-circular section. After definition those
parameters are re-scaled so that the final surface has parametric
range 0 < u < 2, 0 < v < 2.
APT SURFACE NAME (MAX 6 CHARACTERS)? TOR1!
The user has chosen TOR1 as his name for this particular surface.
The data will be defined in APTLIB file TOR1.LDA .
Once the non-native torus geometry has been created it can be
accessed and used by an APT part program. This usage can include
transforming it to create new surfaces, use as drive part or check
surface in machining, or data extraction via the INTOF facility
described in Chapter 9.
An example of such a part program is:
REMARK/'TOR1 HAS BEEN PREVIOUSLY CREATED BY FTORUS'
In this part program the original torus TOR1 as defined in 11.2.1
is read in from APTLIB. This is then translated to take the centre
to point(10,20,30) in order to create TOR2. TOR3 is created by
rotating TOR1 through 90 degrees about the Z axis which is in fact
its axis of symmetry. P1, P2, P3 are then defined repectively as
the points with parameter u=0.5, v=0.5 (i.e. the mid point) of the
first patch of each surface. V3 is the unit tangent vector dr/du
at P3. The results should be:
Note that P2 is the result of displacing P1 by (10,20,30) and that
P3 can be obtained by rotating P1 through 90 degrees about OZ.
VDA-FS is a German National (DIN) Standard originally developed by
the German motor manufacturers for the transfer of surface data.
the basic file format is compatible with IGES and consists of 80
character ASCII records with sequence numbers permitted in columns
73-80. The file always commences with a file or part name followed
by a human readable file header and is terminated by <name>=END
where <name> is the file or part name. Entities in the file are
PSET (sequence of points)
MDI (master dimension or point, vector sequence)
CURVE (piecewise parametric curve)
or SURF (patched bi=parametric surface)
Comment lines are permissable at any point in the file and always
start with $$ .
Surfaces in the file may be of arbitrary degree and are
communicated via their explicit polynominal coefficients. All
multi-patch surfaces must have a simple rectangular topology but
patches may differ in their degrees. All surfaces and other
entities are named with a maximum of 8 characters for the name.
The VDA-FS Formatter, FVDAFS and its associated subroutines, which
are initiated by the RUN FVDAFS command, will read a standard
VDA-FS file and format all surface data in a form suitable for the
evaluator EVDAFS and the transformator TVDAFS.
In reading the VDA-FS file all comments and all POINT,PSET,MDI and
CURVE entities are ignored.
When running FVDAFS the user has the option of creating either a
single file containing all surfaces on the VDA-FS file or of
creating a seperate file for each surface. For use with the SSV2
system a seperate file must be used for each surface but CASPA
permits more than one surface per file. As far as possible the
VDA-FS surface name is used for the corresponding APT surface but
where the original name exceeds 6 characters the user is prompted
for a new surface name. A similar prompt appears if the surface
name is duplicated. Where the option of seperate files is chosen
the file names will be surface_name.LDA for each surface on the
A further difference in requirements between SSV2 and CASPA when
using FVDAFS is that for SSV2 all files created must be single
surface files of type .LDA and contained in subdirectory .APTLIB!
whereas for CASPA any file name and subdirectory can be chosen.
After the LDA files have been created by FVDAFS they can be read
into CASPA by the instruction
READ/LDA,'Filename',list of surface names!
(Default value ALL)
or into SSV2 by the instruction
For LDA files produced by FVDAFS the corresponding evaluator and
transformator are EVDAFS and TVDAFS. These are capable of an exact
evaluation and coordinate transformation of any parametric
surfaces obtained from VDA-FS files subject to a maximum degree of
24 in either u or v. In practice this limitation is sufficient for
all known surface design systems with VDA-FS pre-processors.