The World of Computer Software

home *** CD-ROM | disk | FTP | other *** search

/ The World of Computer Software / World_Of_Computer_Software-02-386-Vol-2of3.iso / c / ctds220.zip / CTDS220.DOC < prev next >

Wrap

Text File | 1993-01-25 | 25KB | 623 lines

Connect The Dots Smoother [CTDS] version 2.20 Copyright (c) 1991, 1992, 1993 Truman Brown All Rights Reserved January 15, 1993 --- COPYRIGHT STATEMENT: --- Connect The Dots Smoother (CTDS) is freely distributable. There is no charge nor registration fee associated with its use. The author retains the copyright to the program, but authorizes free distribution by electron bulletin boards (BBS'es), networks, magnetic media, etc. If necessary, the distributor may charge no more than five dollars ($5) U.S. for distribution of this program. CTDS may NOT be used as part of any commercial software or hardware package without the explicit consent of the author. Interested parties may contact the author via CompuServe ID [71477,221]. The author makes no guarantees or warranties with this program and claims no responsibility for any damages or losses incurred through use of this program. --- INTRODUCTION: --- Connect The Dots Smoother (CTDS) is a data file generator currently supporting the following raytracer formats: . Persistence of Vision Raytracer (POV-Ray) - by various contributors . Vivid Raytracer - by Stephen Coy . PolyRay Raytracer - by Alexander Enzmann For information about any of these raytracers, or about the art of raytracing, or the current state of computer graphics or computer art in general please visit the Graphics Developers forum on CompuServe (tm) (GO GRAPHDEV). For those who are familiar with the art of raytracing, you know that computer generated raytraced images are created by combining and arranging basic primitives such as spheres, cylinders, boxes, etc. Often, scenes will call for complex arrangements of primitives and it would be desirable for the connections between them to appear smooth and seamless. Accomplishing this is quite often difficult and/or memory-intensive. The artist may resort to the use of spline-based polygons generated by various modeling programs, or to the "packing" of primitives until the desired smoothness is achieved. Though effective, these may or may not be the best methods. CTDS provides another alternative. It does what it's name implies, working like a rock-steady hand of a child connecting "dots" in three dimensional space. Given a series of 3d dot coordinates, CTDS will compute the appropriate clippings or intersections, scalings, rotations, and translations of cylinders, truncated elliptic cones, or the simple cones required to "connect the dots". The author's original intent for this program was to aid in the creation of smooth spiral objects that could not easily be created manually using Constructive Solid Geometry. While CTDS can simply be used to create smooth links between spheres in space (such as a spiral), people have found CTDS useful for creating everything from human heads to outer space vehicles. Enjoy. --- CREATING A CTDS INPUT FILE: --- Using your favorite text editor or other CTDS-compatible modeling utility (such as SPIRAL or WORM), create an ASCII text file which contains numeric information describing the position and size of the spheres you desire to be connected. The format should appear as follows: [;] X-value Y-value Z-value R-value │ │ │ │ │ └> signifies a comment line └> defines X coordinate of the dot └> defines Y coordinate of the dot └> defines Z coordinate of the dot └> defines radius of the dot Example: ;This is a comment line: ;X Y Z R 1.0 1.0 -3.0 1.34 2.0 2.0 3.0 1.34 3.3 1.0 4.5 2.44 Pretty simple, dontcha think? Important points to keep in mind: . The entire XYZ and Radius values for a sphere must appear on a single line . Only one set of XYZ and Radius values may appear on a single line. . The file you create must contain at least TWO lines of coordinates. . The maximum length of a line is 80 characters. . There may be no sequential duplications, meaning no line may repeat the coordinates of the prior line (unless the /m parameter is selected - more about that later). This is a basic fact of existence: two objects cannot exist in the same space at the same time, therefore it is impossible to connect them. You will get errors. And the universe will explode in a quantum meltdown. Once you have created a dot-definition file, executing CTDS will automatically create a PoVRAY-, Vivid-, or PolyRay-compatible data file which contains spheres placed at the coordinates which you defined, as well as connecting cylinders and/or elliptic cones which will fill in the blanks between the dots. --- RUNNING CTDS --- USAGE: CTDS [various optional parameters] The optional parameters are as follows: /i[inputfile] This is the name of the ASCII dot-definition file which you created. If you don't specify a filename, the program will search for a default input filename called CTDS.CTD. /o[outputfile] This is the name of the (guess what?) output file. If you don't specify a filename, the program will create a default output file called CTDS.POV. /v If specifed, this value flags CTDS to generate Vivid output data. The default is POV-Ray output. /pr | /pr1 If specifed, this value flags CTDS to generate PolyRay output data. Output format is standard sphere-cone-sphere-cone sequence. /pr2 If specifed, this value flags CTDS to generate PolyRay output data. Output format is union of sphere-cone-sphere-cone sequence. /# If specified, this value controls the level of precision for the floating point values spit out by the program. If no value is specified, the default is 6 decimal places (/6). /m If specified, this parameter flags CTDS to create "multiple autonomous mini- objects or mini-composites". This is described in detail later. /c If specified, this parameter flags CTDS to create a connector between the first and the last spheres defined in the input file. Simply put, this closes the object. /so If specified, this parameter flags CTDS to only output the data required to render the spheres. In other words, no connectors are computed. /co This is the opposite of /so. If specified, this parameter flags CTDS to only output the data required to render the connectors. /c1 If specified, this parameter flags CTDS to only output the data required to render CYLINDRICAL connectors (connectors with equal radii on both ends). /bo If specified, this parameter flags CTDS to only output the bounding data data for POV-Ray, or the object extents for PolyRay or Vivid. Useful for manually optimizing bounds. /qt If specified, this parameter flags CTDS work without sending output to the screen. Useful for other applications that want to call CTDS silently. /sc This parameter only applies to POV-Ray output: If specified, this parameter flags CTDS to add a block of texture transforms to the output so that you can scale the texture separately from the object or composite itself. Translations use declared variables transx1 transx2 transy1 transy2 transz1 transz2 Scalers use declared variables scalex1 scaley1 scalez1 Change the values of these to translate or scale a composite before the texture is applied to it. This is useful if you need to change the location or size of a composite, but don't desire to have the texture translated or scaled as well. /n[objectname] This parameter only applies to POV-Ray output: This is the name of the object or composite that the program spits out. If no name is specified, the program will automatically name your object or composite "YourThing". /d This parameter only applies to POV-Ray output: If specified, this parameter flags CTDS to NOT include the CTDS declarations required for defining the basic spheres and connectors. You will still be required to have these declarations someplace however (such as an included file). /t[texturename] This parameter only applies to POV-Ray output: This is the name of the texture that is globally applied to your object or composite. If no texturename is specified, the program will use a default texture called CTDS_Texture. /s This parameter only applies to POV-Ray output: If specified, this parameter flags CTDS to write dots as sphere primitives instead of quadric spheres. If you want to be able to scale your output unevenly, do NOT use this parameter. Note however that sphere primitives render faster than quadric spheres. /bs This parameter only applies to POV-Ray output: If specified, this parameter flags CTDS to use spheres or quadric spheres to bound your objects/composites. The default is bounding by boxes. /f# This parameter only applies to POV-Ray output: If specified, this value enables you to specify a percentage value to "fudge" the bounding of your objects/composites. This value must be greater than or equal to zero. If no value is specified, the program bounds with no fudging (in other words: /f0). /b This parameter only applies to POV-Ray output: If specified, this parameter flags CTDS to add a summary of bounding data to the end of each object or composite. This commented bounding data provides the maximum, minimum and center extents of the object or composite and can be used for hand-optimization of the bounding of the object or composite. Miscellaneous usage notes: . All parameters are optional. . Typing CTDS with any other parameter (i.e., /h, /?, ?, /gimmeinfo) will display a summary of the usage syntax. . Whitespace is permitted between parameters and tokens: (i.e., CTDS /i myinfile /o myoutfile /n NameofObject). . Parameter token symbols are optional. In other words /b -b and b are all the same. --- USING THE OUTPUT: --- Include or copy the CTDS-generated outfile into your own .pov, .v , or .pi file, run your raytracer against it, and enjoy your image! --- IMPORTANT POV-Ray NOTE: --- . CTDS generates either a single object or a composite of objects using the dot coordinates you defined. You should inspect the output file to determine whether an object or a composite was created. . As noted earlier, CTDS generates objects and composites. When objects and/or composites are defined, PoVRAY allows them to be bounded by simpler shapes such as boxes or spheres. This GREATLY reduces the amount of time required to render an image, since bounding reduces the number of tests the raytracer must make. CTDS automatically bounds each object and/or composite with a box, unless you select the /bs parameter in which case it will bound with either a quadric dot or a sphere depending upon the status of the /s parameter. --- IMPORTANT PolyRay NOTE: --- . /PR and /PR1 are functionally the same. They will generate output in the sequence of sphere-connector-sphere-connector. . /PR2 will output data in the format of a single union with the same sequence of sphere-connector-sphere-connector. --- IMPORTANT PolyRay and Vivid NOTE: --- . Specifying any of the bounding parameters (/b /bs /bo) will cause CTDS to write a summary of the scene extents at the end of the output file. --- IMPORTANT developers NOTE: --- . If you want to call CTDS from your own application, you can specify the /qt flag. This will force CTDS to run in a quiet mode, not sending any data to the screen. Error messages *WILL* be echoed however. --- OK, SO WHAT'S THAT MULTIPLE AUTONOMOUS BLAH BLAH NONSENSE? --- The purpose of multiple autonomous mini-objects/composites is to allow you to create a single file that contains specifications for several sets of connected sequences. If you are using POV-Ray, each separate sequence is individually bounded. This is useful for creating non-sequentially linked objects such as letters. When reading an input file, CTDS will recognize blank lines as separators of "mini-objects". When CTDS reads a blank line, it interprets that as a flag to end the current sequence and start a new one. For POV-Ray, whenever a blank line is encountered, CTDS closes the current object it is processing, bounds it, and begins a new one. It is important to note that, depending upon the status of the "/m" parameter, CTDS responds to blank lines in one of two ways. To understand the difference in processing, let's go through an example: Suppose you created a dot definition file with the following coordinates: ; This is a sample definition file: ; TinySpiral ; --------------------------- ; X Y Z Radius ; --------------------------- 2.00 0.00 0.00 0.50 1.46 -0.20 -1.06 0.45 0.50 -0.40 -1.54 0.40 -0.44 -0.60 -1.36 0.35 -1.00 -0.80 -0.72 0.30 -1.05 -1.00 0.00 0.25 -0.69 -1.20 0.50 0.20 -0.20 -1.40 0.63 0.15 0.14 -1.60 0.45 0.10 0.23 -1.80 0.17 0.05 0.10 -2.00 -0.00 0.00 When the values are read by CTDS, they will be interpreted as a single object. In this particular case CTDS will create one (1) object composed of eleven dots and ten connectors. However, if blank lines are stategically placed between the sphere definitions, CTDS will interpret the list of values as a collection of smaller objects which will be used as the building blocks of a final composite. Each one of these smaller "mini-objects" can describe a unique "dot trail". Each "dot trail", however, will begin where the previous one ended. ; This is a sample definition file: ; TinySpiral ; --------------------------- ; X Y Z Radius ; --------------------------- 2.00 0.00 0.00 0.50 \ 1.46 -0.20 -1.06 0.45 \ 0.50 -0.40 -1.54 0.40 - mini-object -0.44 -0.60 -1.36 0.35 / -1.00 -0.80 -0.72 0.30 / -1.05 -1.00 0.00 0.25 \ -0.69 -1.20 0.50 0.20 \ -0.20 -1.40 0.63 0.15 - mini-object 0.14 -1.60 0.45 0.10 / 0.23 -1.80 0.17 0.05 / 0.10 -2.00 0.00 0.00 - mini-object In this case CTDS will create three mini-objects - one for the first block of coordinates [2.00, 0.00, 0.00, 0.50] through [-1.00, -0.80, -0.72, 0.30], one for the second block of coordinate [-1.05, -1.0, 0.00, 0.25] through [0.23, -1.80, 0.17, 0.05], and one for the last set of coordinates [0.10, -2.00, 0.00, 0.00]. Thus each mini-object fits into the whole, much like a piece in a jigsaw puzzle. You can probably get a clearer understanding if you visualize the sequence in which CTDS builds each mini-object and then the whole composite. When the "/m" parameter is not specified, as in the previous example, CTDS will process the dot definitions within each block in the sequence of: DOT-CONNECTOR-DOT (1st mini-object) ... CONNECTOR-DOT-CONNECTOR-DOT (subsequent mini-objects) ... When the "/m" parameter is selected however, each grouping of dot definitions is treated like a separate puzzle instead of another piece of the main puzzle. These groupings are the multiple autonomous mini-objects. CTDS will process the dot definitions within each block in the sequence of: DOT-CONNECTOR-DOT (all mini-objects) ... such that each mini-object begins with the first dot definition for that particular block and ends with the last dot definition of that particular block. This allows you to specify different starting and ending points for each block of definitions; thus these mini-objects are referred to as "autonomous". While these autonomous mini-objects will still be utilized for building the final composite, they provide a different flexibility for defining the item you wish to create. The two primary benefits of this are: . you now can create multiple mini-objects that fall under a single composite and a single, easily accessed texture statement; and . multiple "dot trails" can be defined emanating from a common coordinate. The one drawback of this is that since each mini-object is supposed to be autonomous, it will always begin with a dot. Thus, if you use the "/m" parameter to perform branching, where each "dot trail" emanates from a common coordinate, the initial dot of each branch will be overloaded (duplicated), requiring manual editing of the generated data file to remove that initial dot from the branches (if you feel so inclined of course). A final point to note is that the "/c" parameter will always connect only the first dot definition of the infile and the last dot definition. It will NOT connect the beginnings and endings of autonomous mini-objects. If the use of "/m" is is still unclear, just play around with it and see what happens (what a cop out, huh?). --- MISCELLANEOUS STUFF: --- . For POV-Ray output, the bounding boxes, spheres, or quadric spheres generated by CTDS should enhance the speed of rendering your complex images. A default "fudge factor" of 0 percent is built into the bound limits. Depending upon the irregularities of the shape you are trying to create, this may or may not be enough. You may notice large portions of your object are missing where the bounds fail. As explained earlier, CTDS can append a summary of statistics about each mini-object and composite so that you can manually optimize/customize the bounding shape as you see fit. Additionally, the command line parameter "/f#" allows you to specify a different percentage for the fudge factor (i.e., /f20 for a 20 percent fudge factor). . While CTDS will do its best to smooth out the spacing between dots, a low density of spheres will still create a somewhat "bumpy" image. This is a fact of life: if you want better quality you have to pay for it. In this case, the costs are increased dot density and increased CPU time. Keep in mind that there is basically a one-to-one relationship between the number of dots and the number of connectors generated. . A final point to note is that when attempting to create smooth curves, the (external) side of the curve farthest from the radius will appear smoother than the (internal) side closest to the radius. This is because the connectors (cylinders and cones) are basically straightedges and will intersect at sharp angles when they meet. In the case of curves, they meet on the internal side of the curve and do not meet at all on the external side. If the sharp angles bother you, increase the density of the dots. --- CONTENTS: --- Files included in the package: CTDS220.EXE The program CTDS220.DOC The documentation CTDS.CTD Sample CTDS input file POVRAY.CTD Sample CTDS input file VIVID.CTD Sample CTDS input file POLYRAY.CTD Sample CTDS input file --- HISTORY: (the life of a small program) --- 01/22/93: CTDS v2.2 . Changed /x to /pr[#] for PolyRay output . Added /bo to output bounds only. Writes object extents for PolyRay and Vivid. . Rewrote main processing function of program for easier maintenance. . Changed default bounding primitive from spheres to boxes. . Added /bs parameter to allow bounding by spheres. . Rewrote commandline parser for easier maintenance . Changed /t parameter (connectors only) to /co . Changed /p parameter (spheres only) to /so . Added /t option for a named texture . Shuffled various functions around, deleted a few, optimized a few . Fixed a big bounding bug. Minimum values for bounding weren't working right. Now they are. . Minor rewrite of documentation. 12/20/92: CTDS v2.0c Macintosh port [Eduard Schwan] . Changed YourTexture to CTDS_Texture . Changed YourTransform to CTDS_Transform ??/??/92: CTDS v2.0d . Fixed bug in declaration of roughness for POV-Ray declarations. Mixed up stuff, can't remember when this was done. 05/09/92: CTDS v2.0c . Added /SC parameter to perform scaling of composite prior to application of texture. . Translations use declared variables transx1 transx2 transy1 transy2 transz1 transz2 Scalers use declared variables scalex1 scaley1 scalez1 05/02/92: CTDS v2.0b . Fixed a major bug that nobody ever complained about - dot sequences flowing from small dot to large dot were not being connected properly 04/12/92: CTDS v2.0 Major code rewrite: . cleaned up source logic; cleared out a lot extraneous nonsense . removed DKB Raytracer output option -- outdated . fixed bug in generating null composites . added /b parameter; made bounding stats optional . added /c1 parameter; force usage of cylindrical connector only . changed default fudge factor to 0 percent instead of 10 . changed default filenames to CTDS.CTD and CTDS.POV . Jumped to v2.0 just for the hell of it. . Removed some examples from documentation; was too confusing. . Resubmitted source to PoV-team for inclusion in PoV 1.0 utilities. 04/12/92: CTDS v2.0a[ddon] . PolyRay output added by Alexander Enzmann. 02/15/92: CTDS v1.17a . Cleaned up spheres-only output. Not publicly released. 01/21/92: CTDS v1.17 . Made PoV 1.0 syntax-compliant. . Submitted source to PoV-team for inclusion in PoV 1.0 utilities. 01/16/92: CTDS v1.16 . Added Vivid support. . Added option to generate connectors only. . Made command line more flexible (major rewrite of parser). . Changed default filenames to VALS.COR and SMOOTH.INC. . Minor bug fix in /c parameter. 12/22/91: CTDS v1.15 . Removed option to choose whether to use CLIPPED_BYs or INTERSECTIONS. . Added option to generate spheres only. Not publicly released. 11/15/91: CTDS v1.14 . Added option to choose whether to use CLIPPED_BYs or INTERSECTIONS. Not publicly released. 09/19/91: CTDS v1.13 . Modified to default to POV-Ray compatibility. Uses CLIPPED_BYs instead of INTERSECTIONs for faster renderings. DKB output still uses INTERSECTIONS. . Added error message when /m and /c parameters are used together. . Revoked shareware constraint, now an official POV-Ray utility. 08/24/91: CTDS v1.12 . Added whitespace flexibility in commandline. Not publicly released. 07/30/91: CTDS v1.11 . Minor bug fixes. Not publicly released. 06/30/91: CTDS v1.10 . CTDS now generates mini-objects and a final composite instead of UNIONs. . CTDS automatically bounds the mini-objects and composite. . Added additional optional command line parameters: - /m: multiple autonomous mini-objects - /d: do NOT generate initial dot and connector declarations - /s: use spheres not quadricS - /n: user defined objectname - /f#: fudge factor for bounds . Rewrite of documentation Minor bug fixes. 06/14/91: CTDS v1.10beta Not publicly released. 05/20/91: CTDS v1.00 ! 1st Official release 05/01/91: CTDS b0.90 . Added command line option for user-specified input and output files. 04/14/91: CTDS b0.70a . Algorithm modified to work with DKB 2.10. . Corrected error in Z axis rotation that resulted in "divide by zero" error. 04/01/91: CTDS b0.70 . Tangent compensations implemented. . All axis rotations fully functioning. . SPIRAL (c) value generator written to test results. 03/25/91: CTDS b0.60 . SMOOTHER renamed to CTDS. . Full screen interface replaced by command line implementation. . DKB rotations recognized as reversed from documentation. . Tangent compensation algorithm developed with assistance from Jim Castro. 03/02/91: SMOOTHER b0.50 . Hard disk crash! No backups. Preliminary test versions lost. 01/15/91: SMOOTHER b?.?? . The idea is born. Math research begun. --- CREDITS: --- I wish to thank: My wife Madrid for her patience and love. Obsessed programmers / trace-aholics can be miserable to live with. My kids Jamaica, Martinique, and Savannah for letting Daddy hog the PC. Jim Castro, Math Specialist of California State University, Northridge for his assistance with the basic geometric algorithm. Alexander Enzman for implementing PolyRay support. Eduard Schwan and Jim Nitchals for porting CTDS to the Macintosh. Heinz Schuller for beta testing Vivid output.