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

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

Download PDF

advertisement