Implementation of NURBS Objects in a Ray Tracing

Implementation of NURBS Objects in a Ray Tracing
DEPARTMENT OF TECHNOLOGY AND BUILT ENVIRONMENT
Implementation of NURBS Objects in a Ray Tracing
Code for RCS Simulation
Zahir Al-Asad
22th Jun, 2010
Master’s Thesis in Electronics/Telecommunication
Programme
Examiner: Prof. Claes Beckman
Supervisor: Dr. –Ing. Frank Weinmann
Abstract
The properties of Non-Uniform Rational B-Splines (NURBS), the IGES file format and its data structure
and implementation methods are presented and discussed in this paper. The goal is to show an
approach to find intersections of rays on NURBS object. This method is implemented in an already
existing ray tracing code for the simulation of electromagnetic fields propagation and scattering. The
ray tracing code has been implemented and verified successfully before in the department.
The discussion of the report starts in the introduction chapter with the review of previous researches
done for finding intersection of ray on objects. It also contains the problem of those researches and
the goal of this project to be achieved. The theoretical discussion of NURBS and the IGES file format
are described in two chapters. A brief description of ray tracing method is also described in one
chapter. The attention is to be focused on describing the method of reading NURBS object from IGES
file and methods for finding the ray intersection points on the NURBS. The report also discusses the
problems of the methods found after implementation and possible solutions. The simulation and
measurement results are also shown in this report. The report concludes with gain of this research
and possible future implementations.
This report shows clearly the benefits of using NURBS for finding ray intersections on arbitrary
objects, which will be supportive for those engineers who work on Radar Communications, especially
on object detection and ray tracing and also the CAD/CAM designer. This method can be
implemented for finding ray intersection points on objects with a very reasonable CPU time.
Acknowledgments
First of all I would like to thank to my supervisor Dr.-Ing. Frank Weinmann for giving me the
opportunity to do my Master’s thesis work in the department of Antenna Technology and
Electromagnetic Modeling (AEM) in Fraunhofer Institute for High Frequency Physics and Radar
Techniques (FHR) in Germany and for being friendly and his excellent guidance during the
whole period of the thesis work. I am very grateful to my examiner Prof. Claes Beckman, who
allowed me to work in this thesis work.
I also would like to thank to my mother Anwara Begum, father Prof. Dr. Md. Azhar Ali and my
borther Dr. Hafiz Al-Asad for their love, financial and mental support. I would like to thank to
my friends too, especially my colleagues in Fraunhofer whose are encouraging me during the
hard time.
Contents
1.
Introduction ................................................................................................................................2
2.
NURBS ........................................................................................................................................5
3.
2.1.
B-spline Curves and Surfaces ...............................................................................................5
2.2.
B-spline Basis Functions .......................................................................................................6
2.3.
Knot Vector .........................................................................................................................6
2.4.
Non-Uniform Rational B-Spline (NURBS) Curves and Surfaces ..............................................7
IGES File Format ........................................................................................................................ 10
3.1.
Classification of Entities ..................................................................................................... 13
3.2.
128 Entity .......................................................................................................................... 14
4.
Ray Tracing ............................................................................................................................... 21
5.
Working procedure ................................................................................................................... 23
5.1.
NURBS Parameters ............................................................................................................ 24
5.2.
Read IGES File .................................................................................................................... 25
5.3.
Find Intersection Points ..................................................................................................... 26
5.3.1.
Conditions for intersection point................................................................................ 26
5.3.2.
Numerical implementation ........................................................................................ 28
5.3.3.
Optimized intersection algorithm............................................................................... 31
5.3.4.
Second optimization method ..................................................................................... 32
5.4.
6.
7.
Normal to the intersection point on NURBS ....................................................................... 33
Result and Verification .............................................................................................................. 36
6.1.
Geometrical Validation of Reading IGES Files ..................................................................... 36
6.2.
Geometrical Validation of Intersection Points .................................................................... 37
6.3.
Validation in the Ray Tracing Environment......................................................................... 38
Conclusion ................................................................................................................................ 41
7.1.
Future Work ...................................................................................................................... 41
References........................................................................................................................................ 42
Appendix I ........................................................................................................................................ 45
Read_IGES() Function .................................................................................................................... 45
Chapter I
1
1. Introduction
Radar which comes to forefront as a useful sensor in World War II is firstly used by the German Navy
in 1903 for ship detection [16]. Over the last two decades radar reflectivity measurement has
developed a lot [17]. Radar has been used primarily as a sensor to detect and track targets by using
Radar Cross Section (RCS), which describe reflection characteristics of electromagnetic wave incident
on objects [18]. However, to determine the RCS for simple shaped objects such as a sphere, cone,
paraboloid, and corner reflector by solving Maxwell’s equations, but for a complex object it’s not an
easy task [19].
Ray tracing is a popular and powerful technique for modeling complex flying objects [20]. A standard
method of the ray tracing is Shooting and Bouncing Ray method (SRB) [21]. But for complex object
SRB method is considerable challenging due to geometric and physical complexity. Basically, the
overhead of computation in the ray tracing algorithm is related to the determination of the
intersection of a ray and an object (a wall surface, a ground plane or a wall edge etc.) in the
propagation environments [22]. This geometric testing can consume more than 90% of CPU time for
a naïve SBR algorithm [23]. Several techniques have been proposed to reduce the time spent of
geometric testing using reprocessing of the propagation environment. Most of the modern ray
tracing based applications only deals with triangles as basic primitives because of their fast
intersection test with a ray [24].
The SRB algorithm is successfully applied for calculating scattered fields of arbitrary targets. This
simulation program can handle some elementary objects (e.g. spheres, cylinders) analytically, but for
complex objects, a triangular mesh is required. Also objects from common CAD file formats can be
used, but these have to be meshed into triangles by using a commercial CAD program and saving the
mesh in NASTRAN format. Although by rendering objects in triangles it is possible to use arbitrary
geometric objects in the ray tracing process, but it has disadvantages. For large and complex objects
large number of elements for intersection tests required, and also large memory required. To
improve this, an alternative geometric representation of objects needs to be studied.
A very powerful way of representing arbitrary curved surface is the use of Non Uniform Rational BSpline (NURBS). NURBS are the standard in computer graphics and most CAD programs for the
geometrical representation and design of curved objects in computer graphics. NURBS have common
mathematical formulas for both standard analytical shapes and free-form shapes. It is possible to
design 3D geometry and simple 2D curves and surfaces using NURBS and provides a much higher
geometrical precision. NURBS are recognized as powerful tools for geometric design in many
standards like IGES, STEP, and PHIGS. In this project work IGES standard has been used to read
NURBS objects. IGES form is a common language for different graphical software for interchange
geometrical data.
The goal of the project work is to develop an algorithm to implement NURBS in the existing ray
tracing code. To achieve that, a NURBS data structure has been created and an algorithm to read the
NURBS objects parameters from IGES files has been developed. Two methods for finding ray
intersection on the NURBS surface have been developed and implemented in the ray tracing code for
RCS simulation. The project code has been done using C++. The immediate benefit of implementing
NURBS is that IGES files can be read directly without the need of meshing the object into triangles.
2
Also it is expected to reduce the number of geometrical objects and thus to reduce memory usage as
well as CPU time.
This report is organized as follows; chapter II provides a short overview of the fundamental
mathematical formulas and properties of NURBS, chapter III explains the IGES file format, chapter IV
describes about the ray tracing method shortly, chapter V provides the whole working procedure in
detail, the result and verification are available chapter VI and the report ended with conclusion and
future work in chapter VII.
The research work has been done as a Master’s thesis of University of Gävle in the Department of
Antenna Technology and Electromagnetic Modeling of Fraunhofer Institute for High Frequency
Physics and Radar Techniques FHR in Wachtberg, Germany.
3
Chapter II
4
2. NURBS
NURBS, i.e. Non-Uniform Rational B-splines [1], are the mathematical representation of 3-D
geometry for describing and modeling curves and surfaces in computer aided design and computer
graphics. They can describe any shape from a simple 2-D line, circle, or curve to the most complex 3D organic free-form surface or solid.
NURBS are a special case of B-splines, whose definitions are outlined in the following subsection.
2.1.
B-spline Curves and Surfaces
A B-spline is a spline, i.e., a piecewise polynomial function. The B-spline curve H(u), is defined by,
n
H (u )   Pi Ni,k (u )
i 0
(2.1)
Where,
{Pi : i=0, 1, 2, ….., n}; are the n+1 control points. The polygon formed by these control points
is the control polygon.
Ni,k are the normalized B-spline basis functions
k +1 is the order of the polynomial segments of the B-spline curve.
A B-spline surface Q(u, v) is defined by,
n m
Q(u, v)    Ni,k (u ) M j ,l (v) Pi, j
i 0 j 0
(2.2)
Where,
Ni,k (u ) and M i,l (v) are the kth and lth-degree normalized basis functions of two knot
vectors with k+1 and l+1 order, respectively.
5
2.2.
B-spline Basis Functions
The ith B-spline basis function of k-degree (order k+1), is defined by,
If k=0,
1 if (ui  u  ui 1)
Ni,0 (u )  
otherwise
0
(2.3)
If k>0
Ni,k (u ) 
u  ui
ui k  ui
Ni,k 1(u ) 
ui k 1  u
N
(u )
ui k 1  ui 1 i 1,k
(2.4)
Where ,
Ni,k(u) is a step function, equal to zero everywhere except on the half-open interval
u [ui , ui 1 ) ;
U={u0, u1…….,um} is the knot vector with i=0, 1, . . . . m number of knot values (see following
paragraph for further description of knot vectors).
2.3.
Knot Vector
A knot vector is an increasing series of real numbers that satisfy the relation (ui ≤ ui+1). There are two
types of knot vectors, uniform and non-uniform, also known as periodic and open [1].
A uniform knot vector has evenly spaced real numbers. For example,
[0 1 2 3 4 5 6]
Or
[ 0.4 0.2 0.0 0.2 0.4 ] etc.
A non-uniform knot vector has a series of real number with multiplicity of knot values at the ends
equal to the order k of the knot vector. Internal knot values are evenly spaced. For example,
6
k=3
[0
k 3
k 3
0 0 1 2 3 3 3]
Or
k=4
2.4.
[ 0 0 0 0 0.25 0.5 0.75 1 1 1 1 ]
Non-Uniform Rational B-Spline (NURBS) Curves and Surfaces
A kth-degree NURBS curve is defined by [2],
n
 Pi Ni,k (u ) wi
C (u )  i n0
 N (u ) wi
i 0 i,k
(2.5)
Where,
Pi are the control points.
Ni,k is kth-degree normalized B-spline basis function of k+1 order.
Wi are the weights. These weights are associated with the control points. Depending on the
weight of a control point the curve moves closer to the control point. In other words, the
weight of a control point controls how much it can pull the curve [7]. There is an example in
Figure 2.1, which shows how a curve varies with different weights of control points.
Figure 2.1: Variation of curve for different wights of control points.
7
A NURBS surface S (u, v) is the extended form of B-spline surface by introducing weighted factor
which causes a four-dimensional homogeneous coordinate space is defined by,
n
m
S (u, v)   Ni ,k (u ) M j ,l (v) Pi ,hj wi , j
i 0 j 0
(2.6)
Where,
Pi ,hj are the control points with weighting factors are represented as homogeneous
coordinates in four dimensional space.
Ni ,k (u ) and M i ,l (v) are the nonrational basis functions of two knot vectors with k+1 and l+1
order respectively.
wij are the weights.
NURBS can be represented by the division of three-dimension space by the homogenous coordinate,
n
S (u, v) 
m
 N
i 0 j 0
n m
i ,k
 N
i 0 j 0
(u ) M j ,l (v) Pi , j wi , j
i ,k
n
m
  Pi , j Bi , j (u, v)
(2.7)
i 0 j 0
(u ) M j ,l (v) wi , j
Where,
Pi , j are the three-dimensional control points.
Bi , j (u, v) are the bivariate rational B-spline surface basis functions
Bi , j (u, v) 
Ni ,k (u ) M j ,l (v) wi , j
n
m
N
i1 0 j1 0
i1, k

(u ) M j1,l (v) wi1, j1
Ni ,k (u ) M j ,l (v) wi , j
sum(u, v)
(2.8)
Where,
n
m
sum(u, v)   Ni ,k (u ) M j ,l (v) wi , j
i 0 j 0
8
(2.9)
Chapter III
9
3. IGES File Format
The Initial Graphics Exchange Specification (IGES), an American National Standard (ANS) format,
serves as a neutral data format to transfer a CAD design to a dissimilar system. Translators,
developed to the IGES Standard, are used to export a design into an IGES file for exchange and for
importing the IGES file into the destination system [8].
There are over 200 different variations of IGES files that are currently being written by different
Computer-Aided Design (CAD) and 3D software packages. In general only about a quarter of the
specification is used for translation of 3D polygonal and NURBS geometry [9].
An IGES file is the representation of geometric, topological, and nongeometric product information
data. Each of those product definition is numbered by a positive integer, which is known as IGES
entity. For example, IGES entity 102 represents Composite Curve.
Most CAD/Compute-Aided Manufacturing (CAM) systems support NURBS curves and surfaces
[10][11]. IGES gives all information used to define the free-form parametric spline surfaces. Trimmed
surfaces in CAD/CAM systems can be represented by the IGES entities 102, 126, 128, 142 and 144.
The 126 and 128 entities support NURBS curves and surfaces respectively.
CAD systems usually maintain transcript files in a binary format. A binary file format is almost always
unique to a software program. Therefore it needs to export the transcript to another software using
a common language. The IGES form is that kind of format to allow the exchange of a product
definition between CAD/CAM systems. It has two format types,
a) A fixed line length format
b) A compressed format
The most commonly used IGES format is the fixed line length format. In fixed line length format each
line has 80 characters. These 80 characters are divided according to the table below [10],
1------8
9------16
17------24
25------32
33-----40
41------48
49------56
57----64
65------72
73------80
(1)
Entity
Type
Number
#
(2)
Parameter
Data
(3)
Structure
(4)
Line Font
Pattern
(5)
Level
(6)
View
(7)
Transformation
Matrix
(9)
Status
Number
(10)
Sequence
Number
)
#;)
#; )
#; )
0; )
0; )
(8)
Label
Display
Assoc.
0; )
#
D#
(11)
Entity
Type
Number
#
(12)
Line
Weight
Number
#
(13)
Color
Number
(14)
Parameter
Line Count
#
(15)
Form
Number
(16)
Reserved
(17)
Reserved
(18)
Entity
Label
(19)
Entity
Subscript
Number
#
(20)
Sequence
Number
#; )
#
Table 3.1. Format of the Directory Entry (DE) Section in the IGES file form
10
D#+1
Nomenclatures used in table 3.1 are:
(n)
Field number n
#
Integer
)
Pointer
#; )
Integer or pointer (pointer has negative
sign)
Zero or pointer
0; )
Table 3.2. Nomenclatures used in the Directory Entry (DE) section
Following the format of directory entity of Table 3.1 it is sectioned in the IGES form as bellow,
No.
Field Name
Meaning and Notes
1
Entity Type Number
Identifies the Entity types
2
Parameter Data
Pointer to the first line of the parameter data record for
the entity. The letter P is not included.
3
Structure
Negated pointer to the directory entry of the definition
entity that specifies this entity’s meaning. The letter D
is not included. The integer values, 0, 1 and 2 are
permissible in the field but should be disregarded.
4
Line Font Pattern
Line font pattern or negated pointer to the directory
entity of a line Font Definition Entity (Type 304)
5
Level
Number of the level upon which the entity resides, or a
negated pointer to the directory entry of a Definition
Levels Property Entity (Type 406, Form 1) which
contains a list of levels upon which the entity resides.
6
View
Pointer to the directory entry of a View Entity (Type
410), or pointer to a Views Visible Associativity Instance
(Type 402, Form 3 or 4), or integer zero (default).
7
Transformation Matrix
Pointer to the directory entry of a Transformation
Matrix Entity (Type 124) used in defining this entity;
zero (default) implies the identity transformation
matrix and zero translation vector will be used.
8
Label Display Associatively
Pointer to the directory entry of a label Display
Associativity (Type 402, Form 5). The value of zero
indicates no label display associativity.
11
9
Status Number
Provides four two-digit status values which are entered
from left to right in the status number field in the order
given below,
1-2 Blank Status
00 Visible
01 Blanked
3-4 Subordinate Entity Switch
00 Independent
01 Physically Dependent
02 Logically Dependent
03 Both (01) and (02)
5-6 Entity Use Flag
00 Geometry
01 Annotation
02 Definition
03 Other
04 Logical/Positional
05 2D Parametric
7-8 Hierarchy
00 Global top down
01 Global defer
02 Use hierarchy property
Physical count of this line from the beginning of the
Directory Entry Section, preceded by the letter D (odd
number).
10
Section Code and Sequence
Number
11
Entity Type Number
(Same as Field 1.)
12
Line Weight Number
System display thickness; given as a gradation value in
the range of 0 to the maximum (Parameter 16 of the
Global Section).
13
Color Number
Color number or negated pointer to the directory entry
of a Color Definition Entity (Type 314).
14
Parameter Line Count Number
Number of lines in the parameter data record for this
entity.
15
Form Number
Certain entities have different interpretations. These
interpretations are uniquely identified by a form
number. Possible form numbers are listed within each
entity description.
16
Reserved for future use
17
Reserved for future use
18
Entity Label
Up to eight alphanumeric characters (right justified).
19
Entity Subscript Number
1 to 8 digit unsigned number associated with the label.
20
Section Code and Sequence
Same meaning as Field 10 (even number).
Table 3.3. Directory Entry (DE) Section.
12
The sequence number is preceded in the line by a single letter code in column 73 given in the table
below,
Section
Letter Code
Flag (not always present)
B or C (Use to signify binary)
Start
S
Global
G
Directory Entry
D
Parameter Data
P
Terminate
T
Table 3.4. Letter Codes Specification.
3.1.
Classification of Entities
Generally, the IGES entities are classified into four classes,
a)
b)
c)
d)
Curve and surface geometry entities
Constructive solid entities
Annotation entities
Structure entities
For geometric representation of CAD data curve and surface geometry entities are needed. Entity
type numbers from 100 through 199 are generally reserved for geometry entities. The following
curve and surface geometry entities are defined in this specification:
Entity
number
100
Entity type
Circular Arc
102
Composite Curve
104
Conic Arc
106
108
Copious Data
Linear Path
Simple Closed Planar Curve
Plane
110
Line
13
112
Parametric Spline Curve
114
Parametric Spline Surface
116
Point
118
Ruled Surface
120
Surface Revolution
122
Tabulated Cylinder
124
Transformation Matrix
125
Flash
126
Rational B-Spline Curve
128
Rational B-Spline Surface
130
Offset Curve
140
Offset Surface
141
Boundary
142
Curve on a Parametric Surface
143
Bounded Surface
144
Trimmed Parametric Surface
Table 3.5. Classification of IGES entities
3.2.
128 Entity
The project work is to implement the NURBS objects into the ray tracing code. There are several IGES
entities that represent 3D curved surfaces. Each entity has different way of defining them. For
example, entity 114 represents parametric Spline surface, entity 140 represents offset surface, etc.
But entity 128 is the general form on NURBS. It is possible to almost all type of NURBS objects using
entity 128.
IGES entity type 128 represents a Rational B-Spline Surface and its directory entry is defined as
follows,
1------8
(1)
Entity
Type
Number
128
9------16
(2)
Parameter
Data
17------24
(3)
Structure
25------32
(4)
Line Font
Pattern
33-----40
(5)
Level
41------48
(6)
View
49------56
(7)
Transformation
Matrix
)
#;)
#; )
#; )
0; )
0; )
(11)
Entity
Type
Number
128
(12)
Line
Weight
Number
#
(13)
Color
Number
(14)
Parameter
Line Count
#
(15)
Form
Number
(16)
Reserved
(17)
Reserved
#; )
#
Table 3.6. Format of the directory entry for entity 128
14
57----64
(8)
Label
Display
Assoc.
0; )
65------72
(9)
Status
Number
73------80
(10)
Sequence
Number
#
D#
(18)
Entity
Label
(19)
Entity
Subscript
Number
#
(20)
Sequence
Number
D#+1
Parameter data (P-Section) are sequenced as in table 3.7.
No.
Name
Type
1
K1
Integer
Upper index of first sum (Equation 2.6 )
2
K2
Integer
Upper index of second sum(Equation 2.6 )
3
M1
Integer
Degree of first set of basis function
4
M2
Integer
Degree of second set of basis function
5
PROP1
Integer
6
PROP2
Integer
1 = Closed in first parametric variable direction
0 = Not close
1 = Closed in second parametric variable direction
0 = Not Closed
7
PROP3
Integer
1 = Polynomial
0 = Rational
8
PROP4
Integer
1 = Non-periodic in first parametric variable direction
0 = Periodic in first parametric variable direction
9
PROP5
Integer
1 = Non-periodic in second parametric variable direction
0 = Periodic in second parametric variable direction
Let,
Description
N1 =1+K1-M1,
N2 = 1+K2-M2,
A = N1+2*M1,
B = N2+2*M2,
C = (1+K1)*(1+K2)
10
S(-M1)
Real
First values of first knot sequence
.
.
.
.
.
10+A
.
.
.
.
.
S(N1+M1)
.
.
.
.
.
Real
Last value of first knot sequence
11+A
T(-M2)
Real
First value of second knot sequence
.
.
.
.
.
11+A+B
.
.
.
.
.
T(N2+M2)
.
.
.
.
.
Real
Last value of second knot sequence
12+A+B
W(0,0)
Real
First weights
15
13+A+B
W(1,0)
Real
.
.
.
.
.
11+A+B+C
.
.
.
.
.
W(K1,K2)
.
.
.
.
.
Real
Last weights
12+A+B+C
X(0,0)
Real
First control point
13+A+B+C
Y(0,0)
Real
14+A+B+C
Z(0,0)
Real
15+A+B+C
X(1,0)
Real
16+A+B+C
Y(1,0)
Real
17+A+B+C
Z(1,0)
Real
.
.
.
.
.
9+A+4*C
.
.
.
.
.
X(K1,K2)
.
.
.
.
.
Real
10+A+4*C
Y(K1,K2)
Real
11+A+4*C
Z(K1,K2)
Real
12+A+4*C
U(0)
Real
Starting value of first parametric direction
13+A+4*C
U(1)
Real
Ending values of first Parametric direction
14+A+4*C
V(0)
Real
Starting value of second parametric direction
15+A+4*C
V(1)
Real
Ending value of second parametric direction
Last control point
Table 3.7. Parametric data sequence of entity 128.
An IGES file can contain any number of entities and can have different entities in the same file. An
example of a simple IGES file given is below in figure 3.1. It contains different entities including entity
128. It is possible to read the entity form the IGES file following the table 2.6 and 3.7. Column 73 of
each line contains the letter code as in table 3.4. The IGES file starts with the letter code “S” and
terminates with “T”. All lines with letter code “D” contain the directory entities and lines with letter
code “P” contain the parameters of entities.
16
Figure 3.1. Simple IGES file containing different IGES entities
17
The IGES file in Figure 3.1 is divided into two parts shown in Figure 3.2 and 3.3. The first half of the
IGES file contains the directory entities. The directory entity is in the D section (lines with letter code
“D”) in the IGES file. For example, the directory entity of the 128 entity is bordered in Figure 3.2. The
directory entity is built up according to Table 3.6. For reading the parametric data of 128 entity, only
two entries are taken from the directory entity, the starting line and the number of lines in the P
section (lines with letter code “P”). In Figure 3.2 the second field of the directory entity is 13, it
means the 13th line in the P section is the starting line of the parametric data. And the 14th field is
42, it means there are 42 lines from 13th line in the P section containing parametric data of this 128
entity.
Figure 3.2. Directory of 128 entity is bordered.
The parametric data of all entities are sequenced in Figure 3.3. The red border highlights the
parametric data of the 128 entity. The two knot vectors, weights, control points and the ranges of
two parametric directions are sequenced inside this border respectively. In this project work those
data are used to calculate points on the NURBS surface.
18
Figure 3.3. Parametric data sequence of 128 is bordered.
Although the IGES file is a complicated format, this is a common language for the CAD/CAM, that
makes easy to share and use object definition into different software. Following the directory entities
and arrangement of parametric data as described in the above sections objects can be identified and
used in different software packages.
19
Chapter IV
20
4. Ray Tracing
For the electromagnetic modeling of scattered fields from large and complex objects, a very efficient
simulation tool based on the well-known Shooting-and-Bouncing-Rays (SBR) technique has been
developed [13]. This algorithm uses field-based high-frequency approaches for finding the relevant
propagation paths, i.e. rays are traced through the scenario according to the laws of Geometrical
Optics (GO) and diffracted rays are generated according to the laws of the Uniform Theory of
Diffraction (UTD). This GO/UTD part is combined with a source-based approach, where each ray
generates an equivalent surface current at each interaction with the object. These currents are
calculated using Physical Optics (PO) and Physical Theory of Diffraction (PTD), and the superposition
of all these contributions leads to the total scattered field strengths. Further technical details about
the ray tracing approach can be found in [13, 14, 15]. With this simulation tool, large and complex
objects can be modeled, which are still too costly for numerically exact methods. Generally, both
metallic and dielectric objects [14], and also combined metallic-dielectric objects, can be modeled.
Consider a ray hitting a smooth surface which is part of the object. The ray is described according to
GO and is reflected at the surface. However, there is also a direct field contribution to the receiver,
which is calculated by applying PO. After calculating the PO contribution, the ray is reflected
according to the laws of GO. The next interaction in the example of Figure 4.1 is at an edge of the
object. At an edge the scattered fields are calculated by PTD and diffracted ray according to the law
of UTD incident on a smooth surface reflected according to GO and another field contribution from
there is calculated by PO. Finally total scattered field strengths are calculated by combining the
calculated fields of PO and PTD.
Figure 4.3. Example of implemented calculation methods.
21
Chapter V
22
5. Working procedure
The goal of the project work is to read NURBS objects from IGES files, find the ray intersection points
on those objects and at last calculate the normal vector on those intersection points which are
needed for calculating reflected ray. To achieve this goal the work has been divided into two parts,
a) Create NURBS data structures and read the data from IGES files.
b) Find the intersection points during the ray tracing processes.
The whole working procedure is shown in a flow chart in Figure 5.1.
Figure 5.1. Flow chart of the work.
23
5.1.
NURBS Parameters
The first part of this project work is to read all 128 entities (NURBS objects) from the IGES file.
Chapter II provides more details about NURBS. The NURBS parameters are number of segments, knot
vectors, order of knot vectors, control points, weight of the control points and the parametric
directions. Considering those parameters a NURBS class has been created in the project code, which
is shown below,
class NURBS
{
public:
VECTOR ** control_net;
int n, m;
int k, l;
double * X;
double * Y;
double **N;
double **M;
double **H;
double u0,u1,v0,v1;
double delu,delv;
friend void basis_f(NURBS *, double, double);
VECTOR normal;
NURBS * p_next;
NURBS();
};
Where,
control_net is a VECTOR type two-dimensional control net. VECTOR is a self-defined class
which is created for simplifing vector calculation.
n and m are the number of segments in u and v direction.
k and l are the spline orders in u and u direction.
X and Y are the knot vectors.
H is the weights of control points.
u0, u1, v0 and v1 are the parametric directions.
basis_f() is a friend function which returns calculated results from spline basis function for
each knot vector.
M and N are the returned values from basis f() for knot vector X and Y respectively.
24
normal is a VECTOR type variable for temporarily storing the local normal vector at the
intersection point.
p_next is pointer to the next NURBS in the object list.
5.2.
Read IGES File
In order to define NURBS data structures the 128 entity is chosen from the IGES file. Considering the
IGES fixed line format as described in section 3 and following the Tables 3.6 and 3.7 for directory and
parameter sequence of 128 entity respectively, the file reading process follows the algorithm below,
Algorithm to read 128 entity from IGES file:
Step 1: Check each line if the 72th character is “D”.
For each 128 entity, the directory entry consists of 2 lines, each line having 10 fields. Each field is
represented by 8 characters.
Step 2: Look for “128“, in the first 8 characters of each line which contain “D” in the 72th position.
Step 3: Save the 2nd field of the first line, which represents the line number of the starting of
parameter data sequence.
Step 4: Read the second line and save the 4th field, which represents the number of lines for the
parameter data.
Step 5: Continue the steps 2, 3, 4 and store the data in a temporary array of parameter sequence list
of all NURBS. Stop this procedure at the end of the directory section.
The parameter data is placed in those lines where the 72th character of a line is “P”. Each two
parameters are separated by “,” and the parameter data sequence is ended with “;”.
Step 6: Start checking each line for “P” character in 72th position.
Step 7: If “P” is found in 72th position start counting the number of lines until the line number
matches with the starting line number in the NURBS class which has been stored in step 3. (The 1st
match is for the 1st NURBS, 2nd match is for 2nd NURBS and so on).
Step 8: If steps 6 and 7 satisfy then start reading the parameters sequentially as in table 3.7 and save
the data in the NURBS class until the line number reaches the limit that is stored in NURBS class in
step 4.
Step 9: Continue steps 7 and 8 until the parameters for all NURBS are read from the file.
25
The algorithm has been implemented in the function Read_IGES() in the project work, which is given
in Appendix I.
5.3.
Find Intersection Points
After reading all the NURBS the next step is to find the intersection of rays on the NURBS surface.
This procedure has to be performed for each ray on each NURBS object, and if necessary even
multiple times, e.g. after reflection of the ray. Thus, this part is very critical with respect to the run
time of a simulation. The main problem here is the fact that there is no analytical solution to finding
ray intersections on a NURBS surface. That is the reason why either the surface representation has to
be converted to plane facets or an alternative algorithm, e.g. an iterative algorithm, has to be used.
In this work, a straightforward approach has been developed, which is illustrated in the following
subsection 5.2.1 and 5.2.2. This algorithm is iterative in the sense that it uses two stages of
refinement in order to improve the accuracy of the computed intersection points. However, it turned
out that this iteration is a major drawback because it results in a large amount of calculations and
therefore increased CPU time. For this reason, an optimization of the approach is described in
subsection 5.2.3, which uses an interpolation algorithm instead of an iterative approach. It turned
out that by using this improved method of finding intersection points, computation times were
drastically reduced as well as accuracy was definitely improved. Further possible optimizations of the
intersection algorithm are briefly described at the end of this chapter.
5.3.1. Conditions for intersection point
To find an intersection point of a ray with a NURBS object, the initial approach is to follow the
method developed by Kajiya [12]. Following this method, a grid of points S(ui,vj) on the surface are
calculated using equation 2.2.
Consider a complex surface S(u,v)and a ray R(t), whose intersection point with the surface is to be
calculated. The ray can be defined by its parametric equation,
R(t )  o  td
(5.1)
Where,
o is the ray origin and d is the ray direction. t is the distance parameter of ray.
The methods to find the intersection point of the ray on the NURBS, following the development of
Kajiya, are as follows.
The ray can be represented as the intersection of two orthogonal planes, for example, P1 = (N1,d1)
and P2 = (N2,d2) (see Figure 5.1).
26
Figure 5.1: Representation of a ray by the intersection of two
orthogonal planes.
The normal of the first plane is defined as,







(dˆ y , dˆx ,0)
(dˆ , dˆ ,0)
if dˆx  dˆ y and dˆx  dˆz
(0, dˆz , dˆ y )
(0, dˆ , dˆ )
otherwise
y
x
z
(5.2)
y
Thus, N1 is always perpendicular to the ray direction d̂ . The normal of the second plane, N2, is
defined as,

 d̂
(5.3)
The distances d1 and d2 of the planes from the global origin O=(0,0,0) with respect to the normal
vectors N1 and N2 respectively are defined as,
d1  
(5.4)
d2  
(5.5)
27
Here, the ray origin o is the vector from the origin of the global coordinate system O = (0,0,0) to the
starting point of the ray, it lies on the ray and on both planes.
The addition of distance with the scalar product of normal and point on the plane must be zero if
there is an intersection point on the surface. The conditions are as bellow,
N1 .S (u, v)  d1  0
N 2 .S (u, v)  d2  0
(5.6)
(5.7)
However, due to the complex definition of a NURBS surface, equations (5.6) and (5.7) can generally
not be solved analytically. That is why an iterative algorithm has been developed in order to find a
point on the surface which satisfies equations (5.6) and (5.7) as close as possible.
5.3.2. Numerical implementation
As stated above, there is no general analytical solution to equation (5.6) and (5.7), which must be
satisfied for an intersection of a ray with a surface S(u,v). Thus, a straightforward algorithm is
developed here, using a grid of points on the surface S(u,v) and finding the point which matches (5.5)
most closely.
In IGES files, the ranges of u and v parameters are given, i.e. start and ending of u and v parameters
(u0, ui, v0, vj), which provides a clear definition of the surface (Figure 5.2). Theoretically, all the points
on the surface would have to be checked with equations (5.6) and (5.7) to find the correct
intersection point. To solve this problem, u and v parameters are first divided into very small
intervals u0, u1, …, ui, v0, v1, …, vj. This grid of parameters corresponds to a grid of points on the
surface (calculation of points according to equation 2.7), and thus S(u,v) is represented by a meshed
surface as in Figure 5.3.
Figure 5.2: Four points calculated using the end Figure 5.3: Each corner of the rectangle
and starting points of u and v.
represents points on the surface.
28
After calculating those points, the distances F1, F2 of each grid point S(ui,vj) to the two planes are
calculated using the equation below,
N1.S (ui , v j )  d1  F1 (ui , v j )
(5.8)
N 2 .S (ui , v j )  d2  F2 (ui , v j )
(5.9)
If the ray hits the patch, it will pass “in between” the four points S(ui,vj), S(ui,vj+1), S(ui+1,vj), and
S(ui+1,vj+1), which is equivalent to the following condition,
if
F1(ui , v j )  0, F1(ui , v j 1 )  0, F1(ui 1 , v j )  0, F1(ui 1 , v j 1 )  0
or
F1(ui , v j )  0, F1(ui , v j 1 )  0, F1(ui 1 , v j )  0, F1(ui 1 , v j 1 )  0
or
F 2(ui , v j )  0, F 2(ui , v j 1 )  0, F 2(ui 1 , v j )  0, F 2(ui 1 , v j 1 )  0
or
F 2(ui , v j )  0, F 2(ui , v j 1 )  0, F 2(ui 1 , v j )  0, F 2(ui 1 , v j 1 )  0
Otherwise
(5.10)
No
Intersection
Intersection
possible
As an example, in Figure 5.4 the ray crosses the surface through the black point and the resulting
intersection will be the red point. Obviously, this is a very coarse approximation of intersection
points, which is the reason for implementing an iteration of the described approach.
To get a better approximation of the real intersection point, the surface area between the points
S(ui,vj), S(ui,vj+1), S(ui+1,vj), and S(ui+1,vj+1) is refined according to Figures 5.2 and 5.3 if these points
fulfill condition 5.10 (see Figure 5.5). For this fine grid of points, the procedure described above is
applied again, in order to find a better approximation of the intersection point. Theoretically, the
refinement can be performed in many levels, which would lead to a very accurate calculation of
intersection points. However, each iteration requires the calculation of a new grid of points, which
takes more CPU resources. Thus, only two stages of refinement are used in the scope of this work.
Typical numbers of grid points are 11x11, 21x21, and 51x51, resulting in meshes of 10x10, 20x20, and
50x50 elements.
29
Figure 5.4: The red point is the approximate Figure 5.5: Second refinement to get a better
intersection on the surface.
approximation of intersection
points
However, it was found that, in some cases this algorithm cannot find the approximate intersection
points. In some cases it can find intersections only for the first refinement and during the second
refinement it cannot find any intersection. If only the first refinement is considered, there are some
grid points closer to the intersection point are also treated as intersection points.
Figure 5.6: Second refinement doesn’t find Figure 5.7: Condition of intersection is true for both
the intersection, because of the
polygons. So it takes the nearer one.
reason shows in Figure 5.7.
As it is shown in Figures 5.6 and 5.7, sometimes it is possible to find more than one polygons which
satisfy the condition of intersection. In this case the algorithm takes the nearest polygon for second
refinement, which doesn’t contain the intersection point.
Beside that it takes large amount of calculations and therefore increased CPU time.
30
5.3.3. Optimized intersection algorithm
To solve the problem of the approach described in section 5.2.1 and 5.2.2, an optimization method
has been developed. For simplification consider the nearest four points of an intersection point on
the surface, which for better readability are written here as, S11, S12, S21 and S22 instead of S(ui,vj),
S(ui,vj+1), S(ui+1,vj) and S(ui+1,vj+1). The steps of the new approach is given below,
Step 1: Project S11, S12, S21 and S22 on ray as shown in figure 5.8, which results in P1, P2, P3 and P4. So
there is an approximate intersection point,
1
P  ( P1  P2  P3  P4 )
4
(5.11)
.
Step 2: Create a plane through P and perpendicular to the ray. Project S11, S12, S21 and S22 on that
plane and the projected points are S11P, S12P, S21P and S22P. Calculate the angles, α1, α2, α3 and α4 as
shown in Figure 5.9. Now if α1+α2+ α3+ α4=3600, the approximate intersection point on the ray P is
inside the projected area. In that case, P is considered to be the approximate intersection point.
Figure 5.8: Projection of the four neighboring
points on the ray
Figure 5.9: Plane through P and perpendicular to
the ray
Although P is an approximate intersection point, but it is exactly on the ray, it may not be exactly on
the surface. To solve this problem step 3 is also considered.
Step 3: Calculate the relative distances dis1 and dis2 (as shown in Figure 5.10). Both distances must
between 0 and 1. Calculate interpolated u and v values using the following equations,
31
uint  u[i]  dis1 (u[i  1]  u[i])
vint  v[i]  dis2 (v[ j  1]  v[ j ])
(5.11)
(5.12)
The equation for dis1 and dis2 are below,
dis1  (P  S _11_ P)*(S _21_ P  S _11_ P)/(norm(S _21_ P  S _11_ P)* norm(S _21_ P  S _11_ P))
(5.13)
dis2  (P  S _11_ P)*(S _12_ P  S _11_ P)/(norm(S _12_ P  S _11_ P)* norm(S _12_ P  S _11_ P))
(5.14)
Figure 5.10: Relative distances dis1 and dis2.
The resultant approximate intersection point is Pint = S(uint, vint). This is a good approximation for the
intersection point exactly on the surface.
The first algorithm described in section 5.3.2 could yield grid points as approximate intersection
points, but this second optimized method does an interpolation between the grid points. Thus the
second refinement is not needed in this method, which reduces calculation time and thus, CPU time
decreases significantly.
5.3.4. Second optimization method
The result of the optimized intersection algorithm described above in section 5.3.3 is sufficient to
find approximate intersection points on the surface, but still CPU time is not low enough. The reason
32
for that is that for each ray, each NURBS is checked for intersection, even if it is far away from the ray
trajectory.
To implement the efficiency of the intersection algorithm, a so-called space partition can be used.
For example, 3D spatial “grids” are formed, and objects are linked with the grids they are part of.
Also there is a link between the ray and the current spatial grid the ray is in. An example is illustrated
in Figure 5.11. In this figure triangular objects are placed in different partitions. Thus, his method
performs intersection tests only in the current spatial grid, and if there is no intersection the ray
moves on to the next grid. The calculation of intersection points is done only when an object is found
in the current grid. This approach saves a lot of unnecessary intersection testing.
The described method has already been implemented earlier for triangles and could be done in a
similar way for NURBS or patches of NURBS.
Figure 5.11: Triangular objects in the space partition
Since the calculation is done only if an object is found in a space partition, calculation efforts and CPU
time are significantly decreased.
5.4.
Normal to the intersection point on NURBS
In this project work approximate normal to the intersection point has been calculated, which is
needed to find the reflection of the incident ray. For that purpose, four neighboring points close to
the intersection points are calculated by adding a very small value with u and v parameters in both
directions.
Q(ui  d , vi  d )
ui  d  ui 1 & vi  d  vi 1 ;
(5.15)
These four points can be considered as four corners of a rectangle. Taking the cross product of the
difference vectors between points the normal is calculated.
33
Figure 5.12: Suppose a ray intersects the Figure 5.13: The normal is the cross product of
surface in the black point.
the
difference
vectors
of
neighboring four points.
34
Chapter VI
35
6. Result and Verification
The verification of the thesis work has been done in 3 steps.
6.1.
6.2.
6.3.
6.1.
Geometrical Validation of reading IGES files
Geometrical validation of intersection points
Validation in the ray tracing environment by calculating radar cross section (RCS) data
of NURBS objects
Geometrical Validation of Reading IGES Files
Reading an IGES files is a very important part of this project work. It needs to be accurate in order to
represent the object’s geometrical properties correctly. To verify that, several IGES files have been
experimented.
Figure 6.1 and Figure 6.2 show the results of reading known IGES files, a sphere consisting of a single
NURBS object and a more complex object (generic missile) consisting of 29 NURBS objects,
respectively.
After reading the geometric data from the IGES file, each NURBS object is divided into 20×20 patches
by splitting the u and v domains into 20 subintervals. Then each patch is divided into two triangles
and those triangles’ data is written in an output file. Thus, a triangular mesh of the whole object is
created. Using Matlab the triangles are read from the file and displayed graphically. For better
visualization, a blue and a read triangle are used for each patch of four points S(ui,vj), S(ui,vj+1),
S(ui+1,vj), and S(ui+1,vj+1)
Figure 6.1: Reading result of a sphere from IGES file.
36
Figure 6.2: Reading result of a complex object from IGES file.
For both IGES files, the triangular meshes created in Matlab show a good representation of the
objects, so that the IGES reading algorithm is validated accurately.
6.2.
Geometrical Validation of Intersection Points
To verify the calculated intersection points, Figure 6.3 shows the graphical representation of
intersection points for the optimized algorithm. The figures show the ray intersection points at a
sphere. Each cross represents an intersection point in these figures, since there is a grid of rays was
shot at the sphere, lot of crosses shows in the figure.
Figure 6.3: Intersection points of the sphere.
37
6.3.
Validation in the Ray Tracing Environment
The IGES file of a sphere described by a single NURBS object has been used for validation in the ray
tracing environment. For frequencies with wavelengths much smaller than the sphere with radius r,
theoretical RCS equal to the geometrical cross section (pi*r^2). In dBm^2: 10*log10(pi*r^2).
The result of the project work in the ray tracing environment depends mainly on the accuracy of the
calculated intersection points. Thus, it depends also on the number of refinements. The result of
implementation of the method described in section 5.3.2 is better if the ranges of u and v
parameters are divided into smaller intervals, because the resultant approximate intersection points
become closer to the real intersection points. Figures 6.5, 6.6 and 6.7 show the different RCS results
for different intervals in the u and v domain. Where, hh-pol and vv-pl represent horizontal and
vertical polarization of the RCS signal respectively. In 10x10 intervals, the variation of RCS is from -5
dbm2 to 20 dbm2. The variation of the RCS decreases in 20x20 intervals shown in Figure 6.4 to -5 to
14 dbm2. As expected, the best result is obtained in Figure 6.7 where 50x50 intervals have been used.
RCS values are in the range from 4 to 7 dbm2. This is rather close to the expected RCS of 5 dBm2. The
simulation results in Figures 6.5 to 6.7 show that a good refinement is required in order to get
accurate RCS results.
However, the CPU time rises exponentially when improving the number of interval. For this reason,
an optimized algorithm has been developed, which is described in Section 5.3.3. The RCS results of
the improved algorithm are shown in Figures 6.8 to 6.11. Figure 6.10 and 6.11 both are for 50x50
intervals; however Figure 6.11 is for a large number of rays.
Figure 6.5: Result of RCS simulation for 10x10
intervals.
Figure 6.6: Result of RCS simulation for 20x20
intervals.
38
Figure 6.7: Result of RCS simulation for 50x50 intervals.
Figure 6.8:
Result of RCS simulation for 10x10 Figure 6.9:
intervals (improved algorithm).
Figure 6.10: Result of RCS simulation for 50x50
intervals (improved algorithm).
Result of RCS simulation for 20x20
intervals (improved algorithm).
Figure 6.11: Result of RCS simulation for 50x50
intervals and for large amount of
rays (improved algorithm)
39
Chapter VII
40
7. Conclusion
The goal of the project work is to reduce the CPU time for geometric testing (i.e. to determine ray
intersections) of objects in the ray tracing method for RCS simulation by the implementation of
NURBS objects in the already developed ray tracing code. To achieve that, a code was written, which
is able to read all 128 entities from IGES file, which represent NURBS objects. Methods to find ray
intersection points were developed and coded. Normal vector to the intersection points are also
calculated at the end of the coding.
There are two methods implemented for finding intersection points on the NURBS surface. The first
method takes a lot of CPU time and under certain conditions it is not possible to find any intersection
point. Using the second method it is possible to find all the intersection points and also decrease the
CPU time.
After implementing the code implemented in a ray tracing environment it was observed that, if the
number of refinement increases the RCS results become more accurate.
7.1.
Future Work
In future work space partition can be implemented for finding intersection on NURBS surfaces. A
possible implementation of a space partition algorithm is described briefly in section 5.3. Since this
method tests only the grids which contain objects, it avoids unnecessary testing for the grids where
no object is available. This way CPU time can decrease impressively.
It has been found that objects from IGES files with several NURBS objects (e.g. the generic missile)
show problems in the simulation. Between NURBS objects it may possible to have gaps. So rays can
travel inside the object through the gaps, which leads to errors in the calculations. To solve that an
algorithm can be developed to close gaps between NURBS objects.
41
References
[1]
Les Piegl Wayne Tiller, “The NURBS book,” Second Edition, Springer-Verlag Berlin Heidelberg
1995 and 1997.
[2]
David F. Rogers, “An Introduction to NURBS: with historical perspective,” Morgan Kaufmann
Publishers 2001.
[3]
Stephen F. Krar, Arthur Gill, “Exploring advanced manufacturing technologies,” Industrial
Press Inc. 2003.
[4]
Les Piegl, “On NURBS: A Survey.” Jan 01, 1991, IEEE Computer Graphics and Applications, Vol.
11, No. 1, pp. 55-71.
[5]
David F. Rogers, Rae A. Earnshaw (editor), “State of the Art in Computer Graphics –
Visualization and Modeling,” Springer-Verlag New York Inc. 1991.
[6]
A. Keith Turner, “Three-dimensional modeling with geoscientific information system.” North
Atlantic Treaty Organization, Scientific Affairs Division.
[7]
http://wiki.blender.org/index.php/Doc:Manual/Modelling/Curves#Weight
[8]
http://ts.nist.gov/standards/iges/about.cfm
[9]
http://www.okino.com/conv/imp_iges.htm
[10]
U. S. Department of Commerce, “The initial graphics exchanger (IGES) specification,” Version
5.0, NISTIR 4412, 1990.
[11]
Sung-Chong Chung, “CAD/CAM Integration of On-The-Machine Measuring and Inspection
System for Free-Form Surfaces,” Manufacturing Systems & Control Laboratory Department of
Mechanical Design & Production Engineering, Hanyang University, SungdongGu, Seoul 133791, KOREA.
[12]
James T. Kajiya, “Ray tracing parametric patches. Computer Graphics (SIGGRAPH ’82
Proceedings),” 16(3):245-254, July 1982
[13]
F. Weinmann, “Ray Tracing with PO/PTD for RCS Modeling of Large Complex Objects,” IEEE
Trans. Antennas Propagat., vol. 54, pp. 1797-1806, June 2006.
[14]
F. Weinmann, “PO/PTD Ray Tracing for arbitrary Metallic and Dielectric Objects,” Proceedings
of the EuCAP 2006 - European Conference on Antennas & Propagation, 6-10 Nov 2006, Nice,
France.
[15]
F. Weinmann, “UTD Shooting-and-Bouncing Extension to a PO/PTD Ray Tracing Algorithm,”
ACES Journal, vol. 24, pp. 281-293, Jun. 2009.
42
[16]
Eugene F. Knott, John F. Shaeffer, Michael T. Tuley, “Radar Cross Section,” Second edition,
SciTech Publishing, Inc., 2004.
[17]
Eugene F. Knott, “Radar Cross Section Measurements,” SciTech Publishing, Inc., 2006.
[18]
John C. Toomay, Paul J, Hannen, “Radar Principles for the Non-specialist,” Third edition,
SciTech Publishing, Inc., 2004.
[19]
Bassem R. Mahafza, “Introduction to Radar Analysis,” CRC Press LLC, 1998.
[20]
M. C. Lawton and J.P. McGeehan, “The application of a deterministic ray launching algorithm
for the prediction of radio channel characteristics in small-cell environments,” IEEE Trans.
Veh. Technol., vol. 43, pp. 955–969, Nov. 1994.
[21]
H. Ling, R. Chou and S. W. Lee, “Shooting and bouncing rays: Calculating the RCS of an
arbitrarily shaped cavity," IEEE Trans. Antennas Propagat., vol. AP-37, pp. 194-205, Feb.1989.
[22]
Zhengqing Yun, Zhijun Zhang and Magdy F. Iskander, “A Ray-Tracing Method Based on the
Triangular Grid Approach and Application to Propagation Prediction in Urban Environments,”
IEEE Transaction on Antennas and Propagation, vol. 50, no. 5, May 2002.
[23]
M. F. Catedra, J. Perez, F. S. de Anana, and O. Gutierrez, “Efficient ray-tracing techniques for
three-dimensional analyzes of propagation in mobile communications: Application to picocell
and microcell scenarios,” IEEE Antennas Propagat. Mag., vol. 40, pp. 15–28, Apr. 1998.
[24]
Alexander Efremov, Vlastimil Havran, and Hans-Peter Seidel, “Robust and Numerically Stable
B_ezier Clipping Method for Ray Tracing NURBS Surfaces,” 21th Spring Conference on
Computer Graphics, Budmerice, Slovakia, Session: Geometric Modelling. Pages: 127 - 135 ,
2005.
43
44
Appendix I
Read_IGES() Function
void Read_IGS(GLOBAL *p_global, char *filename)
{
char temp[64];
int i,j,t,tt,l,count,c,d,e,f,g,h,stop,tpx,tpy;
long int k;
string s;
double start,num,form_n,entity,u,w;
int prop[6],nx,ny;
NURBS *p_nu = new NURBS;
stop=tpy=0;
ifstream file_op0(filename,ios::in);
if(!file_op0)
{
cout<<"Cant't open file"<<endl;
exit(0);
}
//Counting the numbr of NURBS
while(!file_op0.eof())
{
getline(file_op0,s);
while(s[72]=='D')
{
if ((s[5]=='1') && (s[6]=='2') && (s[7]=='8'))
tpy++;
getline(file_op0,s);
if(s[72]!='D')
stop=1;
}
if (stop==1)
break;
}
file_op0.close;
tpy=tpy/2; //number of nurbs
//Define array for storing all the NURBS directory
long int **t_no;
t_no= new long int *[tpy];
for(i=0;i<tpy;i++)
t_no[i] = new long int[2];
ifstream file_op(filename,ios::in);
if(!file_op)
{
45
cout<<"Cant't open file"<<endl;
exit(0);
}
k=num=c=d=tt=t=count=e=f=g=h=tpx=0;
while(!file_op.eof())
{
//t_no[tpx][tpy]=0;
getline(file_op,s);
//test=s.length();
//cout<<s;
while(s[72]=='D')
{
if ((s[5]=='1') && (s[6]=='2') && (s[7]=='8'))
{
l=0;
for(j=0;j<64;j++)
temp[j]='\0';
for(i=0;i<80;i++)
{
if ((i>7)&&(i<16))
{
temp[l]=s[i];
//temporary store the starting line number
l=l++;
if (l>7)
{
start = atof(temp);
t_no[tpx][0]=start;
l=0;
for(j=0;j<64;j++)
temp[j]='\0';
}
}
}
getline(file_op,s);
l=0;
for(i=0;i<72;i++)
if ((i>23)&&(i<32))
{
temp[l]=s[i];
l=l++;
if (l>7)
{
num = atof(temp);
t_no[tpx][1]=num;
l=0;
}
}
46
}
tpx++;
}
getline(file_op,s);
}
tpx=0;
while(s[72]=='P')
{
k=k++; //index
if ((k>=int(t_no[tpx][0]))&&(k<(int(start+t_no[tpx][1]))))
{
for(i=0;i<64;i++)
{
if (s[i]!=' ')
{
for(j=0;j<64;j++)
temp[j]='\0';
l=0
while(s[i]!=',')
{
temp[l]=s[i];
i++;
if ((s[i]==',')||(s[i]==';'))
{
count++;
if(s[i]==';')
break;
}
l++;
}
}
else break;
if (count==1)
entity=atof(temp);
if (count==2)
{
p_nu->n=atoi(temp);
p_nu->H = new double *[p_nu->n+1];
p_nu->control_net = new VECTOR *[p_nu>n+1];
}
if (count==3)
{
p_nu->m=atoi(temp);
for(j=0;j<=p_nu->n;j++)
{
p_nu->H[j] = new double [p_nu->m+1];
p_nu->control_net[j] = new VECTOR [p_nu->m+1];
47
}
}
if (count==4)
{
p_nu->k=atoi(temp)+1;
p_nu->X = new double [(p_nu->n+p_nu>k)*2+3];
for (j=0; j<(p_nu->n+p_nu->k)*2+3; j++)
p_nu->X[j] = 0;
}
if (count==5)
{
p_nu->l=atoi(temp)+1;
p_nu->Y = new double [(p_nu->m+p_nu>l)*2+3];
for (j=0; j<(p_nu->m+p_nu->l)*2+3; j++)
p_nu->Y[j] = 0;
}
if (count==6)
prop[1]=atoi(temp);
if (count==7)
prop[2]=atoi(temp);
if (count==8)
prop[3]=atoi(temp);
if (count==9)
prop[4]=atoi(temp);
if (count==10)
prop[5]=atoi(temp);
if((count>10)&&(count<=(10+p_nu->n+p_nu>k+1))&&(i<65))
{
p_nu->X[c]=atof(temp);
c++;
}
if((count>(10+p_nu->n+p_nu-k+1))&&(count<=(10+p_nu>n+p_nu->k+p_nu->m+p_nu->l+2))&&(i<65))
{
p_nu->Y[d]=atof(temp);
d++;
}
//////// Read Weights from IGES file /////////
if((count>(10+p_nu->n+p_nu->k+p_nu->m+p_nu>l+2))&&(count<=((10+p_nu->n+p_nu->k+p_nu->m+p_nu->l+2)+((p_nu>n+1)*(p_nu->m+1))))&&(i<65))
48
{
if(tt<=p_nu->m)
{
p_nu->H[t][tt] = atof(temp);
t++;
I
f(t>p_nu->n)
{
t=0;
tt++;
}
}
}
///////////// Readding control points ////////////////
if((count>((10+p_nu->n+p_nu->k+p_nu->m+p_nu->l+2)+((p_nu>n+1)*(p_nu->m+1))))&&(count<=((10+p_nu->n+p_nu->k+p_nu>m+p_nu->l+2)+4*(p_nu->n+1)*(p_nu->m+1)))&&(i<65))
{
if(f<=p_nu->m)
{
if (g==0)
{
p_nu->control_net[e][f].x = atof(temp);
g++;
}
else if (g==1)
{
p_nu->control_net[e][f].y = atof(temp);
g++;
}
else if (g==2)
{
p_nu->control_net[e][f].z = atof(temp);
g=0;
e++;
}
if(e>p_nu->n)
{
e=0;
f++;
}
}
/////////////Read Parameters U,V from IGES file ////////////
49
if((count>((10+p_nu->n+p_nu->k+p_nu->m+p_nu->l+2)+4*(p_nu>n+1)*(p_nu->m+1)))&&(count<=((14+p_nu->n+p_nu->k+p_nu->m+p_nu>l+2)+4*(p_nu->n+1)*(p_nu->m+1)))&&(i<65))
{
if(h==0)
p_nu->u0 =atof(temp) ; // this is an example
if(h==1)
p_nu->u1 =atof(temp) ; // this is an example
if(h==2)
p_nu->v0 =atof(temp) ; // this is an example
if(h==3)
p_nu->v1 = atof(temp);// this is an example,
VECTOR *Q= new VECTOR;
nx =p_nu->n+p_nu->k;
p_nu->N = new double *[nx+1];
for(j=0; j<=nx; j++) // 9 is the length of the knot
vector
p_nu->N[j] = new double [nx+1];
ny=p_nu->m+p_nu->l;
p_nu->M = new double *[ny+1];
for(j=0; j<=ny; j++) // 9 is the length of the knot
vector
p_nu->M[j] = new double [ny+1];
CreatNewNurbs(p_global, p_nu);
tpx++;
p_nu = new NURBS;
count=c=d=tt=f=0;
cout<<"tpx = "<<tpx<<"\n";
}
h++;
}
if ((tpx==tpy)||(h==4))
{
h=0;
break;
}
if (tpx==tpy)
break;
getline(file_op,s);
}
if (tpx==tpy)
break;
}
file_op.close();
cout<<"\n";
}
50
Was this manual useful for you? yes no
Thank you for your participation!

* Your assessment is very important for improving the work of artificial intelligence, which forms the content of this project

Download PDF

advertisement