NAVAL POSTGRADUATE SCHOOL

Full text

(1)

(2)

(3)

(4)

(5) NPS52-89-039. NAVAL POSTGRADUATE SCHOOL Monterey, California. INTEGRATED SUPPORT FOR MANIPULATION AND DISPLAY OF 3D OBJECTS FOR THE COMMAND AND. CONTROL WORKSTATION OF THE FUTURE by Steven Alfred. Munson. June 1989. Michael. Thesis Advisor:. Approved. for public release; distribution. Prepared. Naval Ocean Systems Center Code 402. San Diego,. CA. 92152. is. J.. Zyda. unlimited. for:. Naval Underwater Systems Center Combat Control Systems Division Building 1171/1. Newport, RI 02841. 1244004.

(6) NAVAL POSTGRADUATE SCHOOL Monterey, California. Rear Admiral R. C. Austin. Harrison Shull Provost. Superintendent. This report was prepared in conjunction with research conducted for the United States Naval Underwater Systems Center, Newport, Rhode Island and United States Naval Ocean Systems Center, San Diego, California. The work was funded by the Naval Postgraduate School.. Reproduction of all or part of this report This thesis. is. is. authorized.. issued as a technical report with the concurrence of:.

(7) iclassif led JRITY CLASSIFICATION. OF THIS PAGE. REPORT DOCUMENTATION PAGE REPORT SECURITY CLASSIFICATION. RESTRICTIVE. lb. MARKINGS. UNCLASSIFIED SECURITY CLASSIFICATION AUTHORITY DECLASSIFICATION. /. 3. DISTRIBUTION /AVAILABILITY. Approved for public release; distribution is unlimited. DOWNGRADING SCHEDULE. ERFORMING ORGANIZATION REPORT NUMBER(S). NAME OF PERFORMING ORGANIZATION. Monterey, CA. SYMBOL. 6b. OFFICE. NAME OF MONITORING ORGANIZATION. 7a.. applicable). Naval Postgraduate School (City, State,. MONITORING ORGANIZATION REPORT NUMBER(S). 5.. (If. ADDRESS. Naval Postgraduate School. 37. and ZIP Code). ADDRESS. 7b.. 93943-5000. (City, State,. and. Monterey, CA. NAME OF FUNDING /SPONSORING ORGANIZATION. OF REPORT. 8b. OFFICE (If. SYMBOL. 9.. ZIP Code). 93943-5000. PROCUREMENT INSTRUMENT IDENTIFICATION NUMBER. applicable). Direct Funding Javal Postgraduate School ADDRESS (City. State, and ZIP Code). 10.. SOURCE OF FUNDING NUMBERS. PROGRAM. Monterey, CA.. ELEMENT NO.. 93943. PROJECT NO.. TASK. WORK. NO. ACCESSION NO.. UNIT. TITLE (Include Security Classification). INTEGRATED SUPPORT FOR MANIPULATION AND DISPLAY OF 3D OBJECTS FOR THE COMMAND AND CONTROL WORKSTATION OF THE FUTURE. PERSONAL AUTHOR{S). Munson, Steven A. TYPE OF REPORT. i.. 13b.. Master's Thesis. TIME COVERED. FROM. DATE OF REPORT. 14.. (Year,. Month. Day). 15. June 1989. TO. PAGE COUNT 117. SUPPLEMENTARY NOTATION ^he views expressed in this thesis are those of the author and do not reflect the official policy or position of the Department of Defense or the U.S. Government COSATI CODES FIELD. .. GROUP. ABSTRACT (Continue on. 18.. if. if. necessary and identify by block number). Inexpensive; Graphics; Workstation; CCWF 3D; Command and Control; Display of 3D Objects. SUB-GROUP. reverse. SUBJECT TERMS (Continue on reverse. necessary. and. identify by block. number). The Command and Control Workstation of the Future (CCWF) demands a variety of platforms in parlous configurations to accurately reflect the environment it is attempting to portray, prior to this research, individual platforms for the CCWF and other simulations at NPS have been coded directly into each individual program, with no commonality of design or ability to readily share or modify individual platforms. The goal of this research is to develop a text-based file format for the description, modification and display of 3D objects in the CCWF and other simulations. The other primary goals of this research are the development of interactive, graphical routines to display, view, modify and then save current objects into new files; to permit conversion of text object files to binary format for compressed storage; and to develop routines that enable the CCWF and other simulations to import objects from libraries of such 3D files directly into their programs, and display them.. DISTRIBUTION /AVAILABILITY OF ABSTRACT SUNCLASSIFIED/UNLIMITED SAME AS RPT. l». NAME OF RESPONSIBLE INDIVIDUAL. 21.. D.. D. Prof. Michael J. Zyda DFORM 1473, 84 MAR. ABSTRACT SECURITY CLASSIFICATION. Q DTIC USERS. Unclassified 22b TELEPHONE (Include Area Code). 408-646-2305 83. APR. edition All. may be used. until. exhausted. other editions are obsolete. i. i2c.. OFFICE. SYMBOL. Cnaf, 'i?, SECURITY CLASSIFICATION OF THIS PAGE A. U.S.. ao»lrnm*nt. Prlntlnf Olllcti. Kit—«0(-24..

(8)

(9) Approved. for public release; distribution is unlimited. INTEGRATED SUPPORT FOR MANIPULATION AND DISPLAY OF 3D OBJECTS FOR THE COMMAND AND CONTROL WORKSTATION OF THE FUTURE by Steven Alfred Munson. Guard Coast Guard Academy, 1982. Lieutenant, United States Coast B.S., United States. Submitted in. partial fulfillment. of the. requirements for the degree of. MASTER OF SCIENCE IN COMPUTER SCIENCE from the. NAVAL POSTGRADUATE SCHOOL June 1989.

(10)

(11) DUDLEY FNOT LTBP,ARY KAVAI '.J GCnOOL MONTEREY, (.,„_. .A 93843-6002. ABSTRACT The Command and Control Workstation of. the Future. (CCWF) demands. ety of platforms in various configurations to accurately reflect the environment. tempting to portray. other simulations at. Prior to this research, individual platforms for the. NFS have. no commonality of design or. The goal of. ability to readily share or. 3D. develop a text-based objects in the. er primary goals of this research are the to display, view,. CCWF. file. 3D files directly. and. format for the description,. CCWF. development of. and other simulations. into their programs,. to. oth-. interactive, graphical routines. files;. to permit con-. and. to. develop. import objects from. libraries. and display them.. m. The. and other simulations.. version of text object files to binary format for compressed storage;. of such. CCWF. at-. modify individual platforms.. modify and then save current objects into new. routines that enable the. it is. been coded directly into each individual program, with. this research is to. modification and display of. a vari-.

(12)

(13) TABLE OF CONTENTS I.. THE NEED FOR A STANDARD FILE FORMAT A.. CURRENT NPS REAL-TIME VISUAL SIMULATORS. B. IRIS C.. IL. GRAPHICS PORTABILITY. THE STANDARD FILE FORMAT CONCEPT. THE OBJECT FILE FORMAT. -. ASCII VERSION. 2 3 5. DETERMINATION OF FILE TOKENS. 5. B.. HOW TOKENS RELATE TO IRIS GRAPHICS. 6. m. THE OBJECT FILE FORMAT BINARY -. 12 14. A.. ARRANGEMENT OF THE BINARY FILE. 14. B.. TOKEN GROUPINGS AND REQUIRED ELEMENTS. 14. THE DYNAMIC OBJECT STRUCTURE. 23. A.. THE PREMISE OF THE STRUCTURE. 23. B.. GENERIC NODES AND POINTERS. 25. C.. ORDERING OF ELEMENTS WITHIN THE LISTS. 27. D. LIST. V.. 1. A.. C EDITABILTY OF THE ASCII FORMAT. IV.. 1. HANDLING ROUTINES. 27. THE FILE CONVERSION TOOL. 36. A CONVERTING ASCU TO BINARY. 36. CONVERTING BINARY TO ASCII. 37. B.. C A SAMPLE BINARY CONVERSION DISCUSSED. 37. D.. A SAMPLE ASCn CONVERSION DISCUSSED. 38. E.. OTHER CONVERSIONS. 40. IV.

(14) VI.. THE PREVIEW PROGRAM. 42. A.. THE NEED FOR SUCH A TOOL. 42. B.. HOW OBJECTS ARE DISPLAYED IN PREVIEW. 43. C THE OBJECT ORIGIN. 54. D.. MODIFYING ACTUAL OBJECT DATA. 55. E.. RESOLUTION LEVELS. 56. F.. SAVING THE MODIFIED OBJECT. 57. VIL INTEGRATING OBJECTS INTO. OTHER PROGRAMS. 59. A.. THE MAJOR DIFFERENCES. 59. B.. THE ROUTINES NEEDED. 62. C.. ACTUAL IMPLEMENTATION. 63. Vm. LIMITATIONS OF THE FILE FORMAT AND TOOLS. 69. A.. RESOLUTION. 69. B.. AUTOMATIC OBJECT GENERATION. 70. C.. PERFORMANCE DEGRADATION. 70. CONCLUSIONS AND FUTURE WORK. 72. APPENDIX A THE ASCII FILE FORMAT. 74. APPENDIX B THE BINARY FILE FORMAT. 81. IX.. A.. THE BINARY TOKENS. 81. B.. LAYOUT OF THE BINARY HLE. 82. APPENDIX C UNDERSTANDING LEX. 87. A.. WHAT IS LEX. 87. B.. IMPORTANT FEATURES OF LEX. 87. C THE USE OF LEX IN THE OFF D.. ADDING NEW TOKENS TO THE OFF. 88 88.

(15) APPENDIX D PREVIEW USERS MANUAL. 92. A.. AN OVERVIEW OF PREVIEW. 92. B.. HOW TO USE PREVIEW. 92. C THE PREVIEW WINDOWS. 93. D.. OTHER WINDOWS. 94. E.. SELECTING PREVIEW OPTIONS. 94. F.. THE PREVIEW OPTIONS. 96. 1.. Changing The View of the Object. 96. 2.. Object Data Modification. 97. 4.. Object Resolution. 99. G.. CREATING NEW OBJECT HLES. 101. H.. WIRE FRAME MODE. 101. LIST OF REFERENCES. 103. INITIAL DISTRIBUTION LIST. 104. VI.

(16)

(17) LIST. OF FIGURES and Comment. Figure 2.1. Sample. Figure 2.2. Sample Defline Tokens and Data. 8. Figure 2.3. Sample Polygon and Surface Definitions. 9. Figure 2.4. Sample Lighting Model Definition. 10. Figure 2.5. Sample Light Definition. 10. Figure 2.6. Sample Material and Color Tokens. 1. Figure 3.1. Binary Storage for. Figure 3.2. Storage of a Light Definition. 16. Figure 3.3. Storage of a Lighting Model Definition. 19. Figure 3.4. Material Definition Storage. 20. Figure 3.5. Storage of Defcolor, Origin, Setmaterial, Setcolor. 21. Figure 3.6. Line, Polygon and Surface Storage. 22. Figure 4.1. Object Header Definition Code. 24. Figure 4.2. Object. Figure 4.3. Node. Figure 4.4. Double Node and Generic Pointer. 28. Figure 4.5. Node. 29. Figure 4.6. Allocate Double. Figure 4.7. Code. Figure 4.8. Double. Figure 4.9. Double Append Routine Code. Figure 5.1. Code. Title, Date, Origin, Include. Draw. Title,. Date and. Comment. Code. 27. Insertion Illustrated. to. to. Check. 15. 26. List Illustrated. Definition. 7. Node Code. 31. Empty. 32. for. Insert Routine. List. Code. 34. Convert an ASCII Title. vu. 35 to. Binary. 39.

(18) 1. 40. ASCII. Figure 5.2. Code. to. Figure. Node. Insertion with. Figure 6.2. Node. Insertion with Different Materials Illustrated. Figure 6.3. Lighting. Figure 6.4. Partial Listing of Light. Figure 6.5. Remainder of Light Setup Code. 51. Figure 6.6. Current Material Setup Code. 52. Figure 6.7. Color Setup Code. 53. Figure 7.1. Polygon, Line and Surface Structure Definitions. 60. Figure 7.2. Initializer. Figure 7.3. Sample Beginning Program Code with Included. Figure 7.4. First Section. Figure 7.5. Remainder of File Type Checking Code. 65. Figure 7.6. Read Object. 67. Figure 7.7. Sample Use of Integrated Routines and Object Display. 68. Figure A.l. Sample Use ofyylexO Routine. 75. Figure A.2. Partial. Figure A.3. Completion of Sample. Figure C.l. Code Executed. Figure C.2. Code Executed Upon End of File Condition. Figure D.l. Viewport. Figure D.2. Main Tools Window Menu. 95. Figure D.3. Slider Bar. Menu. 96. Figure D.4. Normal's Slider Bar. Figure D.5. Resolution Slider Bars. 6.. Convert Binary Date. Same. to. 46. Material Illustrated. 49. Model Setup Code. Code. 50. Setup Code. for Lines, Polygons. and Surfaces Files. of File Type Checking Code. File. File in. 3D. ASCII OFF Format. Object File in ASCII. for File Include. Menu. Options. 61. 63. 64. Code. Sample 3D Object. 47. OFF Format. 79 80. 90 91. 95. Menu. 98. Menu. vui. 100.

(19) ACKNOWLEDGEMENTS I. would. like to thank Captain. Emil Velez, USA, who worked with. me on. a begin-. ning graphics project that laid some important groundwork for this thesis, including. code for object data modification. He also provided the. would. also like to thank Captain Charles Phillips,. objects currently used in the. used to. I. an. test. CCWF.. and debug the code for. also extend. initial draft. my. this thesis. file. format, as well as the. Finally, I wish to thank Professor. ance and guidance allowed. this. work. difficulty of controlling the volatile. to. to the. the. OFF. 3D and. work.. thanks to Lieutenant Michael DeHaemer,. of the ASCII. this thesis student. USA, who developed. These objects were converted. code. His assistance in getting this project started. ence. programs for converting. OFF format.. objects in the standard IRIS format to the. I. initial. was. Michael. J.. USN, who developed. first draft. of the Lex object. invaluable.. Zyda, whose patience, persever-. be completed.. It is. impossible to measure the. mix of unbridled enthusiasm and complete. embodied. Somehow, he managed.. IX. inexperi-.

(20)

(21) L THE NEED FOR A STANDARD FILE. A.. FORMAT. CURRENT NPS REAL-TIME VISUAL SIMULATORS The Naval Postgraduate School's Graphics and Video Laboratory has a long. his-. tory of developing real-time visual simulators for various Department of Defense interests.. One of. (FOGM),. simulated to fly over the terrain of Fort Hunter Liggett, California.. the. was. simulators. earliest. Fiber. the. Optic. Guided. capable of displaying a 10 kilometer by 10 kilometer area with vehicles. signed and implemented on the IRIS 3120 system [Ref.. An drawn. extension to. to the current. FOGM. was. VEH. the. polygons drawn over the. FOGM. VEH was. which limited the. FOGM. of the IRIS. bilities. and VEH.. 4D/70GT. It. currently undergoing development,. ally,. an. and. line. a. Additions to the previous work. workstation hardware.. variable sun light source.. Current work on. terrain displays,. of sight information displays for the. new and more. is. takes advantage of the advanced graphics capa-. produce high resolution, (12.5 meter) training. included. 2].. are variable terrain color schemes, collision detection, and a lighting. month and hour. was de-. terrain area. 4D/70GT and. networking capability between compatible IRIS workstations [Ref.. combination of. was. This sharply reduced the number of. ported to the IRIS. The Moving Platform Simulator (MPS),. It. 1].. simulator,. view direction and angle.. It. Missile. MPS. forward. is. model with a. being conducted to. artillery. FCXjM/TOW. observation. missile.. Addition-. detailed vehicles are being developed for the simulator, including. Ml Abrahms tank. The Commanders Display System (CDS) was. mand and. Control Workstation of the Future. the initial. (CCWF). work toward. [Ref. 3].. It. the. Com-. was designed. to.

(22) provide the contact and tactical data for simulator view programs. ten for the IRIS. 2400T. workstation, using. Navy. The. CDS. fonts to display the various contacts.. The CDS was. writ-. System (NTDS). Tactical Display. has not been ported to the IRIS. 4D/70GT.. From. the. CDS,. View Simulator. the preliminary. [Ref. 4].. work on. the. CCWF. took the form of the Surface. The Surface View Simulator was designed. to display an ar-. ea of operation as would be seen from the bridge of a surface ship or from a helicopter.. It. featured the use of resolution boundaries, high,. medium and. low, in order to. permit simulation of areas as large as 26 nautical miles in distance on a real-time basis.. Presently, the Surface. View Simulator work has been suspended. Subsurface and Periscope Views for the. CCWF.. in favor of the. This simulator allows for surface. ship bridge views, as well as subsurface (submarine) viewing, multiple platforms, resolution boundaries for real-time presentation, lighting. models and networking ca-. pabilities [Ref. 5].. B. IRIS. GRAPHICS PORTABILITY. As can be seen from is. the multitude of simulator. work being conducted. NPS,. at. it. highly desirable to develop simulators that can be easily ported to upgraded models. of the IRIS workstations.. Development of these simulators has occurred on. of IRIS machines currently employed by the. At present, graphics. NPS. all. levels. Graphics and Video Laboratory.. all. platforms are coded directly into each simulator, using the IRIS. commands. suited to the particular workstation being used, as well as having. the actual physical object coordinates stored in. each simulator.. It. some formal data. should be readily apparent that this format does. portability of these simulators. from one machine. to another,. and. structure little. in fact. to. within. enhance. can huider.

(23) such portability.. It. was. the goal of this research to develop a suitable format for the. storage, manipulation and display of. NPS.. tions at. 3D. objects within the. CCWF. and other simula-. This format should be machine independent as far as possible, making. future portability and modification a simple process.. C.. THE STANDARD FILE FORMAT CONCEPT 3D. In order to present. ware and hardware,. Of. jects.. course, this. and. limitations,. the. ASCn. that. it. it. is. objects in a. was decided. ASCII. to. manner independent of IRIS workstation. soft-. develop an ASCII text format for specifying ob-. specification had to rely. based on the IRIS. 4D/70GT. on current IRIS. capabilities. However,. series graphics facilities.. format does not use IRIS graphics commands, and creates. can be updated and modified with any standard. and. of objects. files. Furthermore, the. text editor.. code written to recognize and process various parts of the standard ASCII. file. fonnat. can be easily modified to adapt to variations in future ERIS workstation hardware and/or software. It. was understood. well contain hundreds,. that. if. IRIS graphics hardware. and also. case,. not thousands, of polygons.. ASCn. IRIS from. 3D. ongoing research. digitizer. at. NPS. camera imaging.. storage of such object formats. rectify this foreseen. This. is. due. constantly being upgraded to display. is. to the presence of. jects for the. incorporated into the simulations might. future objects. to. to the fact that the. more. in real-time,. produce high resolution ob-. Since this will inevitably be the. was considered too memory. problem, a binary format of the object. files. intensive.. To. has been developed,. along with conversion tools to freely convert from one form to the other.. The remainder of. this. work explores. the. file. formats currently being used for. object storage, their usage in previewing, modifying and storing. new. object. files,. 3D the.

(24) conversion between formats, and the integration of these routines into current and future simulations..

(25) THE OBJECT FILE FORMAT ASCU VERSION. n.. A.. -. DETERMINATION OF FILE TOKENS In deterniining what the format of the Object File Format (OFF) should be,. was necessary. to consider. what might be required. to. provide accurate information. while limiting the number of recognizable tokens to as few as possible. objective. was. to create a. meaningful yet concise and easy to learn. The IRIS 4D/70GT workstation,. for. which. this current. ognizes planar polygons and lines for graphical display.. The ultimate. file forniat.. format was developed, rec-. Furthermore, planar polygons. can be described in terms of their color or material properties for the purposes of. The IRIS graphics. ing and/or shading.. nar polygons utilizing normals. at. bound material. and active. lights.. is. uniform and detennined by. characteristics, as well as those of the current lighting. Polygons without normals of any kind are a uniform, specified. Lines are described only by color, and are not modifiable within. That. ing models.. models or tive". mode. is,. all. lines are. inactive to be. Beyond. tiie. model color.. current IRIS light-. lines are a uniform, specified color regardless of current lighting. In fact,. lights defined.. mode,. pla-. For polygons without vertex nonnals,. but with a polygon normal specified, the polygon's color currently. light-. Gouraud shading across. pipeline utilizes. each vertex.. it. if lines are. drawn black. shown. drawn with. in color.. the IRIS in the "lighting ac-. Lines must be drawn with the lighting. in their properly set colors [Ref. 6].. these needed distinctions,. it. was necessary. for the file fomiat to cover. the creation of lighting models, lights, and material and color definitions. Additionally, it. was deemed appropriate. ed, separate. for a clearly distinguished object. from other commenting. capability.. title. and date. This would allow. tlie. to. be includ-. object's. title.

(26) and date to be easily recognized and, ing that. some form of. Further,. file.. desired, displayed in any. if. inclusion capability. file. program incorporat-. was deemed highly. desir-. allowing the creation and easy use of "libraries" containing material, color,. able,. modeling and lighting. much. free-format. Finally,. definitions.. commenting. it. was. desirable that the format allow as. as possible, so that all object files could be well self-. documented.. B.. HOW TOKENS RELATE TO IRIS GRAPHICS some. intelligi-. IRIS graphics commands, so that the mental process of creating. file ele-. The tokens ble. way. to. selected to perform these file functions. However,. ments was straightforward. standard English key words as lation to. much. any particular IRIS feature. For a complete, detailed. The tokens. pendix A.. it. was. also. had. to relate in. desirable. for tokens. as possible, freeing the fonnat. in order to. enhance future. from. The. title. of creation or. more. briefly here.. The tokens. that. fault origin. The. last file modification.. assumed. is. which. it. file. position.. and any com-. Comments. are. and the date. origin token allows specification of the obis. graphed, rotated, translated,. none. (0.0 0.0 0.0) if. input to then be taken from the specified current. do not pertain. strings designed to identify the object title. ject's origin, the position about. direct corre-. of the specific token formats, please refer to Ap-. listing. are presented. and date are. utilize. portability.. directly to the graphics portion of the file are: title, date, origin, include,. ments.. to. file,. is. specified.. resuming. etc.. Tlie de-. The include token causes. after the. end of. that file at the. designed to enhance self-documentation and. clarity.. Comments follow comments. the standard. C. language commenting conventions.. are contained within a pair of. vention, however, the limitations. "/ /". on token. markers.. identification. Unlike the. C. That. is,. language con-. imposed by use of the Lex.

(27) generated lexical analyzer yield a. For. reason,. this. comments. all. maximum. OFF. in the. allowable token length of 200 characters.. should be limited to. Consecutive lines of comments are not a problem. date, origin, include and. title,. /*. comment. My fiist sample object file. at. most two. lines.. Figure 2.1 shows a sample of the. tokens.. */. / the object title is the following */ title. "My. First Carrier". /* file created */. 15. date. /* origin. May is. 1989. 0*/. other than standard. origin. 0.0 5.0 -10.0. /*. be sure to read materials defined for the carrier */. include "Carrier.materials". Figure 2.1 Sample. Title, Date, Origin,. Lines are defined by the defline token.. number specifying. the. number of. ing point vertex coordinates.. 'bgnlineO. ..... segment. Each defline vertices,. is. Comments. followed by an integer. and then x y z. triples of float-. These coordinates are graphed from within an IRIS. endlineO' sequence of commands.. and associated. tions. line. Include and. Figure 2.2 shows sample line defini-. data.. Planar polygons are obliged to have either a single polygon normal or vertex normals.. The former case. "surface.". Each. is. is. referred to as a "polygon" in the. handled a. by the number of. the latter. is. a. bit differently.. Polygons are identified by a defpoly token.. showing the normalized. OFF, and. (unit length). vertices, then. Following. this is the. polygon normal vector. This,. x y z vertex. triples.. The. x y z. in turn, is. triple. followed. vertices are graphically.

(28) displayed by an IRIS 'bgnpolygonO. endpolygonO' sequence,. ..... utilizing the single. polygon normal for lighting calculations. Figure 2.3 shows sample polygon definitions.. /* lines for carrier antennas */. defline. 4 -86.000000 26.000000 39.000000 -85.000000 40.000000 38.000000 -83.000000 40.000000 38.000000 -82.000000 26.000000 39.000000 defline. 4 -86.000000 26.000000 35.000000 -85.000000 40.000000 36.000000 -83.000000 40.000000 36.000000 -82.000000 26.000000 35.000000. Figure 2.2. Sample Defline Tokens and Data. Surfaces are identified by a defsurface token. vertices in the surface, then. length) vertex normals.. IRIS *bgnpolygon() vertex. Figure 2.3. ..... by x y z. The. i. j. This. k sextuples of. is. followed by the number of. vertices. and normalized. vertices are again graphically displayed. from within an. endpolygonO' sequence, but with normals specified. shows sample surface. (unit. at. each. definitions.. Lighting models are identified by the deflmodel token.. The. file. can then modify. any of the IRIS lighting model features, including ambient background color, lighting attenuation calculations, and whether the viewer position is local or not. Attributes of the lighting. model. model not specified. definition is determined. sample lighting model definition.. are set to current IRIS default values.. by the use of the defend token.. The end of. the. Figure 2.4 shows a.

(29) /*. some sample polygons, complete with normals. */. defpoly. -0.422903 -0.640762 0.640762 3. 0.000000 0.000000 0.000000 -0.500000 0.220000 -0.1 10000 -0.500000 0. 1 10000 -0.220000 defpoly. -0.402739 0.000000 0.915315 3. 0.000000 0.000000 0.000000 -0.500000 0. 1 10000 -0.220000 -0.500000 -0.1 10000 -0.220000 /* here are. some cube. face surfaces */. defsurface. 4 20.000000 20.000000 20.000000 20.000000. 20.000000 20.000000 0.333333 0.333333 0.333333 20.000000 -20.000000 0.333333 0.333333 -0.333333 -20.000000 -20.000000 0.333333 -0.333333 -0.333333 -20.000000 20.000000 0.333333 -0.333333 0.333333. defsurface. 4 20.000000 20.000000 20.000000 0.333333 0.333333 0.333333 20.000000 20.000000 -20.000000 0.333333 0.333333 -0.333333 -20.000000 20.000000 -20.000000 -0.333333 0.333333 -0.333333 -20.000000 20.000000 20.000000 -0.333333 0.333333 0.333333. Figure 2.3 Sample Polygon and Surface Definitions.

(30) sample. /*. model showing. light. all. attributes */. deflmodel. ambient 0.2 0.2 0.2 localviewer 1.0 attenuation. 0.5. 1 .0. defend. Figure 2.4 Sample Lighting Model Definition Lights are identified by the deflight token. fied. from. tion,. its. numbers.. their default values.. color and. The. first. its. These. The. position.. three are an x, y. ter,. it. tion.. is. is. light attributes. attributes include the light's. position. is. is at infinite. can be modi-. ambient contribu-. specified by four floating point. and z coordinate. fourth value indicates whether the light. former case, the position. The IRIS. in three dimensional space.. distance or. is. a local light.. actually a direction to the infinite light source.. an actual light position.. The. In the. In the lat-. Again, defend signals the end of the current defini-. Figure 2.5 shows a sample light definition.. /*. sample. deflight. light definition. of a red light */. redlight. ambient 0.1 0.5 0.5 IcolorO.O 1.0 0.0 position 13.0 35.0 10.0 1.0. defend. Figure 2.5 Sample Light Definition Material definitions for polygon material composition are identified by the defmaterial token.. The. material must be. named. for future reference within the object. IRIS material properties can be modified from. their default values.. file.. These properties. include material emission color, ambient color, diffuse color, specular highlighting. 10.

(31) and the material's alpha value, used. color, shininess. Once. in. again, defend signals the end of material attributes.. IRIS lighting calculations.. A. sample material. defini-. tion is found in Figure 2.6.. Colors used in line drawing are identified by the defcolor token.. be named for future reference.. tween 0.0 and. 1.0,. /*. is. followed by three floating point values, be-. is. which correspond,. respectively, to the red, green and blue. Colors are activated by use of the IRIS c3f(). nent of the color. definition. This. found. The color must. call.. A. compo-. sample color. in Figure 2.6.. */. examples of defining and setting and colors */. /* materials. /*. first,. a material */. gold. defmaterial. ambient 0.4 0.2 0.0 diffuse 0.9 0.5 0.0. specular 0.7 0.7 0.0 shininess 10.0. defend setmaterial gold. / now a color */ /. color. name quoted because. defcolor. it. is. contains a blank space */. "Antenna Color". 0.0 0.0 0.0 setcolor "Antenna Color". Figure 2.6 Sample Material and Color Tokens. Materials are. setmaterial token.. set,. or activated, for. This token. is. future surfaces and polygons by use of the. followed by the. Thereafter, untU another setmaterial this material type.. all. is. invoked,. all. name of. the material to be used.. polygons and surfaces will be of. A sample use of setmaterial is shown in Figure 2.6.. 11.

(32) Colors for lines are likewise activated by use of the setcolor token, followed by the. name of. All future lines are drawn in that color until another. the color to be used.. setcolor token. A sample use of setcolor is shown in Figure 2.6.. invoked.. is. For the purposes of the preview program there. is. no. ability to specify planar. This. vertex.. because. is. all. polygons. in the. tor research will not follow this path. all. further lines, defined. As Appendix els. illustrates, the. However,. loss of generality. it. is. in general,. without normals, polygon or. unforeseeable that. NFS. fiiture. avail. simula-. Therefore, the setcolor token affects only the. by the defline token,. names of. and materials corresponds directly. represent.. C.. A. OFF. simulators currently under development at. themselves of the IRIS lighting capabilities, and. color of. and simulator use. tool,. to the. in the object fUe.. properties used for lights, lighting. mod-. aspect of the IRIS feature which they. format can be easily changed in the future without. their exact. and readability in the OFF.. EDITABILTY OF THE ASCH FORMAT The OFF allows complete. from within the. file.. The. control of every aspect of the object's appearance. lighting model, lights used, material and color definitions, use. of lines, as well as use of polygon or vertex normals can. same. time, the format. minutes.. Its free. is. use of commenting makes. well -documented object. The. easy to read and understand. it. It. all. be controlled.. can be learned. files.. fact that the standard format is. vi,. EMACS,. few short. possible, though not automatic, to write. an ASCII. file. means. that. any object. be modified from within any standard text editor with which the user including. in a. At the. Wordperfect, Appleworks,. provements in future IRIS models or material definitions, the. OFF. may modify. etc.. While. it. is. may be. can. familiar,. possible that im-. the properties of lighting models, lights. can easily be adapted to such changes.. 12. file. Lines,.

(33) polygons and surfaces will doubtless remain unchanged able future.. changed seize. in their. format for the foresee-. Similarly, the process of setting materials or colors for use will remain un-. in the format.. The graphics code behind. upon new IRIS improvements.. 13. the format will simply change to.

(34) THE OBJECT FILE FORMAT BINARY. in.. A.. ARRANGEMENT OF THE BINARY FILE As. it is. -. a user of a binary data. file. should know, in order to read the. imperative that the precise format of the. ful input. from the. impossible.. file is. file. Each of. have been assigned to an integer value.. be. known and. the tokens. file. successfully. followed, or meaning-. from the ASCII. These tokens are thus stored. file. format. in the binary. format as integers, and these integer tokens are used to detemiine the format of the following data related to each token.. There are currently 24 recognizable tokens and. associated integer values.. Each token has. The. a required group of data, in a specific format, that. precise formatting. briefly in section. within the. B. spelled out in detail in. is. of. this chapter.. file is irrelevant,. which control polygon and fined in the. B.. must follow. it.. Appendix B, and explained more. The order of tokens and. their associated data. except as pertains to setcolor and/or setmaterial tokens, line colors for all further lines,. polygons and surfaces de-. file.. TOKEN GROUPINGS AND REQUIRED ELEMENTS Each of. the allowable tokens. data in a fixed fomiat.. is. required to be followed by a specified grouping of. These tokens and formats are as outlined. in the following. paragraphs.. The (the. title. token. is. followed by an integer number n showing the length of the. number of characters. in. it),. then by n characters (see Figure 3.1).. 14. title.

(35) The date token (the. is. followed by an integer number n showing the length of the date. number of characters. in. The comment token. is. comment. (the. it),. then by n characters (see Figure 3.1).. followed by an integer number n showing the length of the. number of characters. in. it),. # of characters n. TOK.TITLE integer. then by n characters (see Figure 3.1).. n chars. integer. allocation for title token. #. TOK_DATE. of characters. n chars. integer. allocation for date token. # of characters n. TOK_COMMENT. and data. allocation for. n chars. comment token and data. Figure 3.1 Binary Storage for light definition token, deflight, is. length of the light's name.. defend token. This is. data are allowed, in any order:. is. character. character. integer. integer. above;. character. character. ". integer. ter until the. and data. n >\^. *. The. character. character. Title,. Date and. Comment. followed by an integer n indicating the. followed by the n characters of the name.. Thereaf-. encountered, the following tokens and their associated. one or more comment tokens,. in the. an Icolor token, followed by three floating point numbers;. format described. an ambient token,. followed by three floating point numbers; a position token, followed by four floating point numbers. Figure 3.2 illustrates this storage.. The. lighting. model. definition token is deflmodel.. Until the defend token. is. en-. countered, the following tokens and their associated data are allowed, in any order:. 15.

(36) light definition starts witfi the following. # of. TOK DEFLIGHT. characters. character. n. -»•«integer. character. » < n chars. integer. and may. contain the following groups until # of characters n. TOK_COMMENT. character. n chars. TOK LCOLOR. red component. green component. integer. float. float. red component. green component. TOK AMBIENT. -»+* integer. blue component. float. blue component. -*+*-. float. y coordinate. > <. z coordinate. float. float. TOK DEFEND integer. Figure 3.2. Storage of a Light Deflnition. 16. w. coordinate. > <. > <. \. float. float. float. X coordinate. »K integer. defend. character. integer. integer. TOK_POSITION. group. float.

(37) one or more comment tokens,. in the. format described previously;. ken, followed by a floating point number;. a localviewer to-. an ambient token, followed by three floating. point numbers; an attenuation token, followed by two floating point numbers.. Figure. 3.3 illustrates this storage.. The. material definition token, defmaterial,. the length of the material's name.. Thereafter, until the defend token. This is. ciated data are allowed, in any order:. scribed previously;. followed by an integer n indicating. followed by the n characters of the name.. encountered the following tokens and their asso-. one or more. comment. tokens, in the fonnat de-. an emission token, followed by three floating point numbers;. ambient token, followed by. three floating point numbers;. three floating point numbers; bers;. is. is. a diffuse token, followed by. a specular token followed by three floating point. a shininess token followed by one floating point number;. lowed by one. The. number. Figure 3.4. floating point. color definition token, defcolor,. length of the color's name. three floating point. This. is. is. this. num-. an alpha token,. fol-. illustrates this storage.. followed by an integer n indicating the. followed by the n characters of the name.. numbers conclude. The token origin. is. an. token group (see Figure. Finally,. 3.5).. followed by three floating point numbers, corresponding to. the X, y and z values of the specified object origin (see Figure 3.5).. The setmaterial token terial's. name.. Tliis is. is. is. name. (see Figure 3.5).. followed by an integer n indicating the length of the color's. followed by the n characters of the name (see Figure. The token the. followed by an integer n indicating the length of the ma-. followed by the n characters of the. The setcolor token name. This. is. number of. to define a line. is. defline.. This. is. vertices to be connected in the line.. 17. 3.5).. followed by an integer n indicating Finally,. 3n. floating point. numbers.

(38) follow, giving the x, y and z coordinates of each vertex in the line.. Figure 3.6. illus-. trates this storage.. The token. to define a. polygon. is. floating point numbers, providing the. This. is. defpoly.. This. is. immediately followed by three. polygon surface nonnal. x,. y and z coordinates.. followed by an integer n indicating the number of vertices to be connected in. the polygon.. Finally,. 3n. floating point. numbers follow, giving the. x,. y and z coordi-. nates of each vertex in the polygon (see Figure 3.6).. The token dicating the. to define a surface is defsurface.. number of. This. is. followed by an integer n. vertices to be connected in the surface.. Finally,. in-. 6n floating. point numbers follow, giving the x, y and z coordinates of each vertex in the surface. followed immediately by the. i, j. and k vertex normal coordinates (see Figure. 18. 3.6)..

(39) light. model. definition starts with the following. group. TOK DEFLMODEL integer. and may. contain the following groups until. # of. TOK_COMMENT. defend. character. characters. character. n n chars. integer. integer. TOK LOCALVIEWER. value. -*+*•. integer. TOK AMBIENT. red component. green component. blue component. > <. > <. integer. float. float. float. float. TOK ATTENUATION. value. -•H-*. integer. value 2. 1. *H-*-. float. I. float. TOK DEFEND integer. Figure 3.3 Storage of a Lighting Model Definition. 19.

(40) material definition starts. witli. # of characters n. TOK_MATERIAL. *•-«-. the following group. » < n chars. integer. integer |. and may. character. character. |. contain the following groups until # of. TOK_COMMENT. character. character. characters. n n chars. integer. integer. TOK EMISSION. red component. green component. > < integer. TOK AMBIENT. float. red component. green component. float. blue component. > <. float. > < integer. float. blue component. » < float. float. red component. TOK DIFFUSE. defend. green component. blue component. » < integer. TOK SPECULAR. float. float. red component. green component. > < integer. TOK. blue component. > < float. float. value. SfflNINESS. float. TOK ALPHA. float. value. > < integer. integer. float. TOK DEFEND integer. Figure 3.4. Material Definition Storage. 20. float.

(41) color definition consists of the following group # of. TOK_DEFCOLOR. characters. character. character. n n chars. integer. integer. red component. green component. float. float. blue component. float. origin definition consists of ttie following. TOK_ORIGIN. X coordinate. y coordinate. group. z coordinate. •*+*-. integer. float. float. float. setmaterial consists of the following group. TOK_SETMATERIAL. # of characters n. character. > <. » <. n chars. integer. integer. character. setcolor consists of the following group. TOK_SETCOLOR integer. Figure 3.5. # of characters n. character. character. n chars. integer. Storage of Defcolor, Origin, Setmaterial, Setcolor. 21.

(42) line definition consists of thie following. # of. TOK DEFLINE. vertices. n. X coordinate. y coordinate. group. z coordinate. > * \. n. integer. integer. polygon. triples. of floats. definition consists of the following. group. normal x. nonnal y. normal z. # of. float. float. fl oat. TOK_DEFPOLY integer. X coordinate. n. y coordinate triples. vertices. n integer. z coordinate. ffloat s. surface definition consists of the following group # of. TOK DEFSURFACE. vertices. n » <. integer. vertex x. vertex y. vertex z. integer. normal X. normal y. normal z. n sextuples of floats. Figure 3.6. Line, Polygon. 22. and Surface Storage.

(43) IV.. A.. THE DYNAMIC OBJECT STRUCTURE. THE PREMISE OF THE STRUCTURE The. was. top-level goal of this research. plexity to be read into. some fonnal data. to permit. 3D. objects of any size and. and then displayed. structure,. in. com-. any simulator. number of. lines,. polygons and surfaces, as well as the materials and colors used, a dynamically. allo-. or other program in use.. cated structure. Since. is. Because each object varies radically. necessary.. through the object's structure. yond those. is to. it. is. a requirement.. was decided. that. linked 4. 1. lists. shows It is. ments.. was. of the object's elements. traversing. and deletions of object elements bestructure. is. ideally suited to be used in a. dynamically. al-. "stored" in one object header structure that title,. date, object origin,. which contained pointers. to the. maximum. heads and. (lines, lights, materials,. tails. polygons,. and miniof doubly-. etc.).. Figure. the code defining the object header structure.. impossible to display an object by merely traversing. That. is,. by traversing the. which material had been selected structure also contains a. head and. different types of double nodes.. nodes.. desired,. are. each object should be stored. contained pertinent information such as values, etc., and. tools. Further, to ensure object structure ro-. some form of generic. located stmcture, where the object. mum. modification. say, to allow future additions. currently in use,. Therefore,. here.. and. previewing. interactive. bustness, that. in the. list. of independent ele-. lists. of polygons or surfaces,. it. is. to use for individual elements. tail. pointer for a. draw. These include material,. list.. It. impossible to. Hence. the header. can contain up to five. color, line,. polygon or surface. Material nodes indicate a change of material to be applied to. 23. tell. all. future.

(44) / define the OBJECT_HEADER structure type */ typedef struct object_header struct. /*. object_header. char. title;. char. date;. float. origin[3];. main head node. for the project */. / object title / / date of object file / / object origin / / max and min x,y,z / / coordinates of the polygons / / or surfaces of the object. /. maxx,. float. OBJECT_HEADER;. minx.. maxy, miny,. maxz, minz;. / ptrs to head and tail of list of light definitions / double_ptr. head_lightdefs;. double_ptr. tail_lightdefs;. / ptrs to head and tail of list of lighting model definitions / double_ptr. head_modeldefs;. double_ptr. tail_modeldefs;. / ptrs to head and tail of list of material definitions / double_ptr. head_materialdefs;. double_ptr. tail_materialdefs;. / ptrs to head and tail of. list. of color definitions. double_ptr. head_colordefs;. double_ptr. tail_colordefs;. /. / ptrs to head and tail of list of line definitions / double_ptr. head_linedefs;. double_ptr. tail_linedefs;. / ptrs to head and tail of. list. of polygon definitions. double_ptr. head_polygondefs;. double_ptr. taiLpolygondefs;. / ptrs to head and tail of. list. of surface definitions. double_ptr. head_surfacedefs;. double_ptr. tail_surfacedefs;. /* ptrs to. head and. tail. of list of draw. double_ptr. head_drawlist;. double_ptr. tail_drawlist;. list. /. /. */. );. Figure 4.1. Object Header Definition Code. 24.

(45) polygons and surfaces,. until another material. node. is. Color nodes. encountered.. cate a change to be applied to succeeding lines until another color node tered.. illustrates the. B.. draw. list. encoun-. is. Lines, polygons and surfaces are object elements to be displayed.. indi-. Figure 4.2. concept.. GENERIC NODES AND POINTERS draw. In order to permit the addition of various structure types to the as to maintain robustness and standardization in the. dynamic object. inition. was made so. between the various. structure, the character pointer. was. list,. of elements. lists. That. as well. is,. a type def-. that a generic pointer is actually a character pointer.. These ge-. utilized.. neric pointers can then be coerced to point to any structure desired.. Each node. any given doubly-linked. in. ble pointers, one to. its. list is. a double node.. predecessor node and one to. its. It. contains two dou-. successor node.. pointer has been type defined to be a pointer to a double node structure.. A. There. double is. one. generic pointer in each double node that points to a dynamically allocated structure. where the data. is. stored for that node.. ing what type of data tail. is. It. also contains an integer dtype field indicat-. being pointed to by the generic pointer.. The. double pointers are maintained in the object's header structure.. list's. head and. Figure 4.3 pro-. vides the code defining the node structure, pointers and macros.. The. result of using. double nodes and generic pointers. pending to or inserting in any doubly-linked. one. append and. set of primitive. any data structure the user structures,. one each. surfaces.. Finally,. list. insert routines.. desires.. is. several fold.. First, ap-. of elements can be accomplished by. Second, any double node can point to. At present, there are seven such data storage. for lights, lighting models, colors, materials, lines, polygons. any new structures corresponding to new elements added. 25. and. to the.

(46) draw. This illustrates a sample. list.. Actual elements vary.. NULL. \. 1. head_drawlist material. y. to data k. structure. V to data. <. to data. line. surface. structure. "X. •. •. structure. /. "V. color. structure. to data. ^. ^ to data. '. surface. structure. line. NULL to data. Y-. structure. structure. polygon. to data. to data. line. •. material. structuD. .. structure. ^ •. to data. polygon. / to data. polygon. --.. tail. drawlist. structure. Figure 4.2 Object. Draw. 26. List Illustrated. to data. structure.

(47) object. format can be easily accommodated using the present node and pointer. file. structures and. list. handling routines. Figure 4.4. illustrates the. use of double nodes.. / define what a double node and a pointer to a double node are / typedef struct node double_node, *double_ptr; struct. / generic node in doubly-linked. node. */. list. {. generic_ptr data;. /* pointer to. any data structure */. /* data type indicated by defined tokens */. dtype;. int. prev;. /* pointer to previous. next;. /* pointer to next. end node. /*. ) ;. /* definition. */. MACROS for use in list handling routines. #define. DATA(L) ((L)->data) DATATYPE(L) ((L)->dtype) NEXT(L) ((L)->next). #define. PREV(L). #define. #define. */. ((L)->prev). Figure 4.3. C.. /. node node */. double_ptr. double_ptr. Node. Definition. Code. ORDERING OF ELEMENTS WITHIN THE LISTS Within each. was necessary the object. and the. ed to. file.. tail. its. to. list. of elements. (lights, materials, surfaces, etc.) for the object,. new nodes. determine in which order to add. In general,. new nodes. are. added. at the. pointer in the header structure updated.. end as well, except. in the. preview. tool. was read from. as data. end of each. The draw. list. list. of elements,. has elements add-. program, discussed. Lines, polygons, surfaces, materials and colors are inserted at the. it. tail. in chapter VI.. of the draw. list. as they are encountered. Figure 4.5 illustrates this insertion.. D.. LIST The. same.. HANDLING ROUTINES. routines for handling each of the eight. That. is,. one. set. of routines handles them. 27. lists. all,. in the header structure are the. since they. all. consist of double.

(48) The Double Node and Generic Pointer prev pointer next pointer. Basic. eneric. node type. Node Elements. ata. pointer. double node. N^ILL head drawlist material. t. X. / •. polygon. /. polygondeT. materiaidef. DATA. DATA NULL. -X. head linedefs line. line. linedef. linedef. DATA. DATA. NULL head colordefs color. color. "coIoraeT. colordef. DATA. Figure 4.4. DATA. Double Node and Generic Pointer. 28. •. •. •.

(49) Portion of current. •. •. •. •. material. to data. draw. list. ^. "x". to data. surface. structure. prior to insertion. to data. line. structure. structure. HULL to data. surface. structure. %. ^. Ji*. ^xC^ ^ ^. to data. surface. structure. tail. Same. draw. portion of current. material. to data. "x". to data. structure. after insertion. surface. line. structure. ^. J^. to data. surface. drawlist. to data. surface. structure. _^.. list. structure. <^. color. to data. structure. '. Figure 4.5. tail. Node. drawlist Insertion Ulustrated. 29. to data. structure. NULL polygon. to data. color. structure. to data. structure.

(50) The basic. nodes.. allocating and assigning a. routines accomplish the following tasks:. new double node, checking. a. list. to see if. empty, inserting a new node in front of. is. it. an existing node, and appending a node after an existing node.. The allocate_double_node(). routine takes as. ble node, a generic pointer to the data for the. then dynamically allocates a. ed memory.. It. in,. Figure 4.6. The see. if. and is. new double node and. sets. the. in, sets. the code for double. node. routine to check whether a. FALSE.. The. the. new node's. the value of that pointer. returns. new node, and. is. new node's. new double node. NULL.. predecessor and successor pointers to. allocation.. list is. NULL.. empty merely checks. If. it. is,. double_insert() routine takes as one of list. before which the. then calls the routine to allocate a. the head of the. the function returns. its. TRUE.. list. If not,. arguments a double pointer,. new node new. new double. is. to. it. to. be inserted.. It. ptr,. also. node, and an integer data. node, which allocates space. and assigns the data type and generic pointer of the new node.. new node's. to the val-. data pointer to the generic pointer. takes a generic pointer to the data stmcture of the It. This routine. Figure 4.7 contains the code for this routine.. pointing to the node in the. type.. a node type.. sets the value of ptr to this allocat-. then sets the dtype integer flag field of the. ue of the node type passed passed. arguments a pointer ptr to a dou-. its. Finally,. it. updates the. predecessor and successor pointers, as well as the predecessor pointer. of the insertion point. iptr),. and the successor pointer of the former predecessor of. ptr.. Figure 4.8 shows the code for this routine.. The double_append() ptr, pointing to the. node. routine takes as one of. in the list after. which. the. It. then calls the routine to allocate a. arguments a double pointer,. new node. takes a generic pointer to the data stracture of the type.. its. new. new double. is. be inserted.. It. also. node, and an integer data. node, which allocates space. and assigns the data type and generic pointer of the new node.. 30. to. Finally,. it. updates the.

(51) and establishes a new node for a generic */ where the pointer to the node is returned via */. /* this routine allocates /* doubly-linked. list,. and the data pointed to or linked via the node is provided */ /* by the argument "data", a generic pointer to the data structure */ /* containing the data for that node */ /* "ptr". intallocate_double_node(ptr,data,nodetype). double_ptr *ptr; generic_ptr data; int. nodetype;. {. new node in memory, call it item */ = double_ptr item (double_ptr)malloc(sizeof(double_node));. /* allocate space for. / check to make sure malloc call worked! (item. if. == NULL). {. printf("MALLOC. }. */. FAILURE. --. MAJOR PROBLEMS !\n");. retum(FALSE); /*endif*/. /* set pointer of the. *ptr. =. node. to. node "item" for return. to the caller */. item;. /* using. MACROS defined in "filespec.h", assign data and pointers in */. new node */ DATA(item) = data; NEXT(item) = NULL; PREV(item) = NULL; DATATYPE(item) = nodetype;. /*. the. retum(TRUE);. }. /*. end. allocate double. node */. Figure 4.6 Allocate Double Node Code. 31.

(52) /* this routine checks to see if a doubly-linked int. list is. empty. */. empty_double_list(L). double_ptr L; {. return (L }. /*. == NULL). ?. end empty double. TRUE FALSE; :. list. */. Figure 4.7 Code to Check for. 32. Empty. List.

(53) new node's predecessor and. successor pointers, as well as the successor pointer of. the insertion point (ptr), and the predecessor. Figure 4.9 contains the code for this routine.. 33. pointer of the former successor of ptr..

(54) /* this routine inserts a. new node. /* the position pointed to. by. into a doubly-linked list in front of */. "ptr",. NOT necessarily the start of the list */. int double_insert(ptr,data,type). double_ptr *ptr;. /* pointer to insertion/starting point in list */. generic_ptr data;. I* pointer to data structure */. /* integer flag indicating data structure type */. int type; {. double_ptr newnode;. new. /* allocate if. new node. /* pointer to. space,. and return. error. msg. printf("You have. and. insert */. if failed */. (!allocate_double_node(&newnode,data,type)) printf("While trying to insert, allocation for. {. new node. MAJOR MEMORY problems.. failed.Nn");. Sorry. \n");. retum(FALSE); /*endif*/. ). /* otherwise,. go ahead and. /* first case, if if. /* ). to create. list is. insert this. currently. empty. new node. */. */. (empty_double_list(*ptr) == TRUE) { PREV(newnode) = NEXT(newnode) = NULL;. second case, non-empty else. list. */. {. new node's next pointer is NEXT(newnode) = *ptr;. I*. set to. new node's previous pointer is PREV(newnode) = PREV(*ptr);. I*. I* old start's. previous pointer. is. old. start */. set to old start's previous pointer */. now new node. */. PREV(*ptr) = newnode; I* if old start. had a previous node,. set it's next pointer */. new node */ if (PREV(newnode) !=NULL) { NEXT(PREV(newnode)) = newnode;. I* to the. /*endif*/. }. I*. ). end. if. then else */. /* set old start to. *ptr. retum(TRUE);. ). /*. new node. */. = newnode;. end double. /* success */. insert */. Figure 4.8. Double Insert Routine Code. 34.

(55) /* this routine /* pointed to int. adds a new node to a doubly-linked. by. list. AFTER. the position */. NOT necessarily the end of the list */. "ptr",. double_append(ptr,data,type). double_ptr *ptr;. /* pointer to insertion point in list */. generic_ptr data;. /* pointer to data structure holding data for. node */. /* flag indicating data structure type */. int type; {. double_ptr newnode; /* allocate if. new. space, and return error. msg. printf("While trying to insert, allocation for. printfC'You have. */. if failed. (!allocate_double_node(&newnode,data,type)). {. new node. MAJOR MEMORY problems.. failed.Nn");. Sorry. \n");. retum(FALSE); /*endif*/. }. /* otherwise,. go ahead and. /* first case, if if. list is. insert this. empty. currently. (empty_double_list(*ptr). new node. */. */. = TRUE). {. PREV(newnode) = NEXT(newnode) = NULL; /* ). second case, non-empty else. list. */. {. new node's next pointer is set to NEXT(newnode) = NEXT(*ptr);. /*. new node's previous pointer PREV(newnode) = *ptr;. I*. /* old start's next pointer is. is. old start's next pointer */. set to old start */. now new node. */. NEXT(*ptr) = newnode; I* if old start. had a next node,. set it's previous pointer */. new node */ if (NEXT(newnode) != NULL) { PREV(NEXT(newnode)) = newnode;. /* to the. /*endif*/. ). I*. ]. end. if. then else */. /* set old start to. *ptr. return (TRUE);. ). /*. new node. */. = newnode; /* success */. end double append */. Figure 4.9 Double Append Routine Code. 35.

(56) V.. The. THE FILE CONVERSION TOOL. conversion program tool. file. is. called fileconvert.. It. is. located in the. ojfltoohlconvert directory, and is invoked by entering fileconvert followed. For example, to convert the ASCII object. name.. file. named. by a. "Carrier.mine" to. its. file. bina-. ry equivalent, the invocation would be: fileconvert Carrier.mine. Fileconvert determines for. OFF. whether the specified. file is in. ASCII or binary. format, then invokes the proper conversion routines to perform the conversion to. the other format.. A.. itself. No. special. names or. suffixes are required for. any object. file.. CONVERTING ASCII TO BINARY The. routines to convert an object file in the standard. converttobinary.c and writebinary.c. The. files. dinate writing to the output binary file based. ASCII. The second. file.. file. first file. ASCII format. are located in. contains the routine to coor-. upon the token read from the input. contains the actual individual token writing routines in-. voked from converttobinary.c.. The code same name input. loop. converttobinary.c. as the input. ASCII is. in. file is. ASCII. opened.. file,. first. creates. and then opens a binary. but with the tag ".bin" appended to. After the input and output. files are. entered that executes until an end of input condition. file. it.. with the. Next, the. thus opened, a control. is. reached in the ASCII. file.. Based upon the next token read from the input ASCII in the control. and write. it. file,. the switch statement. loop invokes a routine to read the appropriate data from the input to the. binary. file.. Each of. file. the actual routines are found in the file. 36.

(57) Thus. writebinary.c.. the routine. is,. one while loop. essentially,. testing for the. end of. input condition, with a switch statement nested inside.. When. end of input condition. the. successfully opened,. then closed.. is. showing the name of the new binary. B.. is. reached, the main loop exits. a message. Finally,. printed to the. is. file, if. screen. file just created.. CONVERTING BINARY TO ASCII Similar to the. from binary. to. ASCII. ASCII. invoked. tines. to read. The code same name Next,. it. perform the conversion. to binary conversion, the routines to. are located in the files converttoascii.c and writeascii.c.. former contains the main control routine, while the. The. latter contains the individual rou-. and write specific token groupings.. in converttoascii.c creates. as the specified binary input. and opens an ASCII output. file,. opens for input the specified binary. file. with the. but with the tag ".ascii" appended to file.. It. it.. then enters a while loop, which. checks for a successful read of the next token from the input is. The binary. Inside the while loop. file.. a switch statement, which evaluates the token read and invokes the appropriate. routine to read the rest of the data for that token, then write the token and data to the. output. ASCn file.. Once its.. The. file. condition. is. reached in the input binary. input and output files are then closed, and a message. indicating the. C.. end of. the. name of the new ASCII. file,. is. the while loop ex-. printed to the screen. file just created.. A SAMPLE BINARY CONVERSION DISCUSSED To. illustrate. containing the. would appear. how. title. a binary conversion. "My. First Object".. similar to: title. "My. is. accomplished, consider an ASCII. The format of such. First Object".. 37. file. a tide in an object file.

(58) As ken. the input file tokens are read in the control loop of converttobinary.c, the to-. would be. title. TOK_TITLE.. identified. This. and the variable token. causes. switch. the. in that routine. statement. write_binary_title(), a routine found in writebinary.c. tine expects that, following a title token, the next. be an identifier token.. If,. copied into the global variable. id.. file will. output binary. file. the. 5. 1. The. issue. a. shows. set to. call. token returned from the input ASCII. such a token. is. returned,. its. value has been. write_binary_title() routine then writes to the. integer token, then the length of the identifier. the. to. write_binary_title() rou-. This completes the conversion of an ASCII. string), then the string itself.. D.. The. TOK_TITLE. binary equivalent. Figure. in fact,. to. would be. code used to accomplish. (title. to its. title. this.. A SAMPLE ASCII CONVERSION DISCUSSED To. illustrate. how. an ASCII conversion. containing the date "23 Jan 1989".. would. be:. As. is. accomplished, consider a binary. The format of such a date. in. an object binary. file. file. TOK_DATE (integer), date size (integer), date string (char * date size).. the input file tokens are read in the control loop of converttoascii.c, the to-. ken date would be identified and the variable token. TOK_DATE.. This causes the switch statement to issue a. a routine found in writeascii.c.. The. integer as a date size guide, string is then read. is. placed. writes to the output. memory. from the binary at. the size+1. ASCII. file. would be. set to. call to write_ascii_date(),. write_ascii_date() routine expects that, follow-. ing a date token, the next value in the input binary. character. in that routine. is. file will. be an integer.. allocated for size+1 characters.. file into this. position.. the string "date. 38. allocated space.. An. Using. this. The. date. 'end of string'. Finally, the write_binary_date() routine ",. followed on the next line by the date.

(59) /* this routine writes the. ASCII. file title to. the binary file */. \vrite_binary_title(bf). int bf;. {. int. nexttoken;. int. firsttoken. int. titlesize;. /* next token in the input. stream */. = TOK_TITLE;. /* get next token. from input. file */. nexttoken=yy lex() /* should if. be an ID. --. a "string" */. (nexttoken==TOK_ID) = strlen(id);. {. titlesize. write(bf,&firsttoken,sizeof(int)); write(bf,&titlesize,sizeof(int));. write(bf,id,sizeof(char)*titlesize);. /* if not, error! */ }. else. {. printf("ERROR printf("No. title. --. no. identifier after. key token TITLE \n");. written to binary file\n");. ). retum(l); ). /*. end write binary. title. */. Figure 5.1 Code to Convert an ASCII Title to Binary. 39.

(60) ;. string. and a new. ASCII. equivalent.. This completes the conversion of a binary date to. line character.. its. Figure 5.2 shows the code used for this operation.. /* this routine reads. and copies a date. ASCII. to the. file */. write_ascii_date(bf,outfile). FILE int. *outfile;. bf. int datesize;. /* size of date string */. char *date;. read(bf,&datesize,sizeof(int));. date. =. (char *)malloc(sizeof(char)*(datesize+l));. read(bf,date,sizeof(char)*datesize);. date[datesize]. =. ^0';. fprintf(outfile,"\ndateNn");. f^rintf(outfile,"%s\n" ,date);. /*. ). end of write_ascii_date. */. Figure 5.2 Code to Convert Binary Date to. E.. OTHER CONVERSIONS The remaining conversions from ASCII. same. pattern.. The word tokens. lents in the binary. are. file.. Integer. ASCII. in the. numbers. stored as floating point values.. to binary, or vice versa, follow the exact file are. When. converting from binary to. stored as their integer equiva-. are stored as integers.. ASCII. ASCII. Floating point values. character strings. size*char groupings, always preceded by an integer. in. ASCII. number. are. stored as. indicating string size.. all identifiers. are automatically enclosed. double quotes, regardless of whether or not they are more than one word. Identifiers are titles, material. names,. light. names. string. or color names.. They. in length.. are stored as. character strings in the binary format without the enclosing double quotes to save. 40.

(61) space.. Comments and. date strings are written from binary to. quote enclosure.. 41. ASCII without double.

(62) THE PREVIEW PROGRAM. VI.. Preview. the. is. Preview. gram.. name of. is. OFF ASCII. is. largest. smallest all. or binary. It. file.. was designed. In this program,. last.. Resolution levels, axis orientation, object size and polygon. be interactively modified by use of. this. program.. A.. 3D. Additionally, the. object can be viewed in a "wire frame" adaptation of the normal solid object view.. pendix. to. read into the dynamic structure in order of decreasing element size,. each object. normals can. object viewing and modification pro-. located in the off/ tools/preview directory.. permit manipulation of any object in an. first,. 3D. the interactive. Ap-. D contains a preview user's manual.. THE NEED FOR SUCH A TOOL Standardization. dividual manner.. is. inherently preferable to each. The OFF was developed. simulations, present and future.. so that. programmer doing things. 3D. objects could be shared. However, an object used. need to be scaled or otherwise modified for use. in. in another simulation.. degrees, in their. an. in-. among. one simulation might For instance,. one simulation might make vehicle or vessel course calculations based on being oriented "facing north," or compass. in. all. vehicles. file specification.. Another. might wish to base such calculations on geometric/mathematic. degrees, with vehi-. cles "facing east" in their file specification.. Another. common problem. IRIS's lighting capabilities. is. in the. development of. objects for use with the. the calculation of polygon normals.. techniques used to calculate such normals.. some. 3D. These methods rely on the specification of. "internal" or reference point in order to determine. entations a calculated normal should take.. There are many. When. 42. which of the two possible. an inside point. is. specified for a. ori-. 3D.

(63) polygon nonnals are oriented. object, the vast majority of. may be. the polygons. oriented in such a. way. However, some of. correctly.. relative to the reference point that their. normals are 180 degrees out of phase. These polygons with their reversed normals. when. are easy to spot its. intended color.. the lighted object. A way. verse their normals, that. was needed is,. to. viewed, as the polygon. is. is. to interactively identify these. the normal. re-orient. black instead of. polygons and. re-. 180 degrees into the proper. direction.. Finally, variable resolution display. mining which polygons,. lines. is. a capability of preview. Interactively deter-. and surfaces. to. show. in a. given object resolution. is. a. highly useful feature. This feature allows the user to graphically "create" objects of. lower resolution based on what. modify the object as. it. is. viewed. and meaningful way. telligent. is. already in the object. Permitting the user to. file.. in order to create varying object resolutions is an in-. to create files of objects for different desired resolution. levels in any simulation.. B.. HOW OBJECTS ARE DISPLAYED IN PREVIEW As an. 4. is. object. list. on an. as. in. read in from the OFF, the dynainic structure discussed in chapter. However,. created.. draw. is. needed. method being. is. sized and put in the. Materials and colors are inserted in the. draw. list. basis, as explained in the following paragraphs.. arose as to. how. utilized at present. ered to be of size zero at. time each line, polygon and surface. descending size order.. The question. only. this. (0),. highest resolutions.. is. to. detennine. line,. polygon and surface. a rough approximation.. so that they are stored. sizes.. First, all lines are. last in the. draw. list. The. consid-. and displayed. Second, polygon and surface sizes are detennined by us-. ing a rough approximation of their volume, determined by their respective miniinum. and maxijTium. x,. y and z vertex coordinates.. 43. As each polygon. or surface. is. read from.

(64) the object data. file, its. mines the minimum and. The. gon/surface. directions. is. maximum. x,. y and z values from. difference between the. all. the vertices in that poly-. minimum and maximum. values in. three. all. These differences are then squared, added together, and the. calculated.. sum. square root of the. This routine deter-. vertices are sent to a calculation routine.. This. taken.. square root value becomes the poly-. final. gon/surface size. Resolution, in the sense of utilized. levels. in. the. terrain. 3D. display. >5PS. of current. do not need. "distance" in the picture displayed is. works much the same as the resolution. objects,. to. Objects. simulators.. be drawn in as great a. at. This. detail.. most readily accomplished by reducing the number of polygons, surfaces and. drawn when displaying. the object.. It. makes. is in. the display, the fewer "small" polygons or surfaces should be drawn.. insertion of material or color nodes in the. such node encountered in the data. That. file.. and thus the "farther away". first,. Lines should only be drawn when the highest resolution. The. is,. list. is. desired.. draw. and the most recent. list is. determined by the. setting as ordered. a current material and a current color pointer are maintained by the. When. polygon or surface nodes are to be inserted. in the. draw. list,. the. draw. list. searched from the head forward, looking for the insertion position by element. The. is. size.. routines used in this operation are found in files insertelements.c and extrain-. sert.c.. al. last. by the object. program, and modified as setmaterial and setcolor tokens are encountered. line,. lines. intuitive sense that the "smaller" poly-. gons and surfaces would "disappear" in the distance the object. a. and. As. material and color nodes already in the. list. color pointer are maintained,. material or color in the surface. is. draw. list.. When. list. list. materi-. showing the most recently encountered. the insertion point for the line or polygon or. located, the current material (for polygons. (for lines) pointer is. are encountered, a. checked against the value of the. 44. and surfaces) or current color list. (color or material) pointer..

(65) If they agree, the. new node. is. simply added. at that point.. Figure 6.1 illustrates such. an insertion. In the event that the current and serted in the. draw. list. is. copy of the. list. count of. lines,. to. termine the. maximum. be drawn. node must be added. total. is. of 15 (142/10, rounded up to include. all. new. list,. so the. new. Then, since the elements. line/polygon/surface node.. These. taken.. totals are. of polygons and surfaces. This. tion_factor, an integer variable currently set to 10. total. draw. current. illustrates.. resolution level needed.. 127 polygons and 15 surfaces for a. First, the. in-. in the present list material or col-. after the. polygons and surfaces. preview program help window. The. the. point in the. displayed in the appropriate color.. This completes the insertion, as Figure 6.2. A. do not agree, two nodes must be. at the insertion. immediately following the new node are or, a. pointers. around the new line/polygon/surface node.. material or color must be added line/polygon/surface. list. is. taken to de-. divided by the resolu-. total is. Thus, for an object consisting of. of 142 elements, a. elements). is. displayed in. maximum. resolutionjevel. required.. In the preview program, each line, polygon and surface structure has a field la-. beled 'active.'. marked. are is. It is. an integer. as 'active'. field,. by asserting. used as a boolean value.. TRUE. used to increase or decrease resolution. and. slider bars are. surfaces are. marked. lighting. call to a set. levels, or the interactive resolution. as inactive (or reactivated) as chosen. model and. is. lights. elements. Thereafter, the. used to select or delete elements from view.. only elements whose 'active' field. The. in all active fields.. Initially, all. by the. mouse. menu. Lines, polygons and user.. At. all. times,. TRUE are displayed in the viewport window. used in the preview program are determined by a. up routine. This routine. is. found in. file. setup.c.. able and used for either the lighting model or the light(s) ified in the object file.. 45. if. Default values are avail-. either attribute is not spec-.

(66) Portion of current. material. to data. draw. "x". prior to insertion. to data. surface. structure. to data. line. structure. /. J^. structure. \ •. to data. surface. list. to data. surface. structure. structure. •. to data. color. structure. t. insertion point for current material. Same. new polygon. = gold. list. portion of current. material. to data. draw. list. "x". \. surface. structure. ^. to data. polygon. structure. to data. line. structure. y to data. = gold. after insertion. to data. surface. structure. material. to data. surface. structure. structure. new polygon color. to data. structure. current material = gold. Figure 6.1. Node. list. Insertion with. 46. Same. material. = gold. Material Illustrated. •.

(67) Portion of current. ^ •. •. •. draw. ^. ^. •. material. to data. to data. ^. structure. to data. "^^X^. structure. structure. ^. J^ surface. to data. line. surface. structure. to data. prior to insertion. list. r. surface. to data. color. structure. •. •. structure. f. new polygon. insertion point for. currentjnaterial = gold. Same. portion of current. \ •. •. •. listjnaterial. •. material. to data. X. structure. draw. list. >*-^. line. structure. to data. \ to data. material. "x'. surface. structure. list. to data. structure. structure. ^S. to data r polygon. to data. structure. new polygon. current material. material. ^. to data. surface. y structure. after insertion. ^. to data. surface. = "blood red". "X". color. to data. structure. structure. material currentjnaterial. Figure 6.2. Node. = gold. listjnaterial. = gold. Insertion with Different Materials Illustrated. 47. •.

(68) The use.. If. first. item operated on by setupO. one or more. is. is. specified in the object. in the object's. header structure wUl not be. more than one. are specified). are specified, a default. file,. head pointer of the modeldefs. the. NULL. The. model. lighting. pointed to by the head modeldefs. is. model. created for use.. is. model. the selection of the lighting. The. bound through IRIS bndefO and lmbind() caUs. Figure Next, the setupO routine finds and activates. list. list. model,. (first. pointer.. current lighting. to. model. if. If. none. is. then. 6.3 presents the relevant code.. all lights. specified in the object. file.. Currently, the IRIS lighting capabilities allow only eight lights to be active, so the set-. up routine only found. in the. list.. in the lightdefs. activates the first eight lights in the lightdefs If. no. list.. bound based on the. show. 6.4 and 6.5. Then,. in the. LIGHTO. lights. lights in the. list,. list,. ..... a default light. object's materialdefs. are. created and inserted. LIGHT? (maximum). are defined and. using IRIS lmdef() and lmbind(). list.. is. defined and bound based on the. As. expected,. if. bound through use of. first. calls.. Figures. material found in the. no materials were found. in the file (lience. The current material. in the list), a default material is created for use.. fined and. is. more. if. the code used for this operation.. The current material. none. found. lights are. even. list,. is. then de-. the IRIS lmdef() and lmbind() calls.. Figure 6.6 con-. no colors were provided. in the file, a de-. tains the relevant code.. Lastly, the current color fault color is created. the object. file,. the. and. first. is. defined.. If. set as the current color.. color in the colordefs. If. one or more colors are defined. list is set. as the current color.. in. Figure 6.7. contains the code for this operation.. Once. the lighting model, lights, current material. tablished, the object. head to. tail.. is. ready for displaying.. Each node's dtype. is. Tlie. and current color have been. draw. list is. traversed in order from. checked and action taken appropriately.. 48. es-.

No results found