Path: utzoo!utgpu!water!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!mailrus!cornell!batcomputer!saponara From: saponara@batcomputer.tn.cornell.edu (John Saponara) Newsgroups: comp.graphics Subject: Re: Haine's NFF Package: Part 01/01 Message-ID: <6220@batcomputer.tn.cornell.edu> Date: 6 Sep 88 14:01:53 GMT References: <2684@uoregon.uoregon.edu> Reply-To: saponara@tcgould.tn.cornell.edu (Eric Haines, actually) Organization: 3D/Eye Inc (not Cornell, actually) Lines: 249 In article <2684@uoregon.uoregon.edu> markv@drizzle.UUCP (Mark VandeWettering) writes: > > >This is as it was posted to comp.graphics AGES ago. Have fun. If >someone figures out why "gears" turns out funny on my raytracer, let me >know, I am stumped. One possibility is that you've got an old version of gears.c. A bug that K.R. Subramanian pointed out to me was that the gear polygons overlap, which causes refraction to be pretty ill-defined. Attached are the patches to bring your posted version of the SPD package up to version 2.4. Note that the one available on netlib is at 2.4, so does not need these patches. Eric Haines (not John Saponara - do you believe me or the computer?) *** old/README --- new/README 4c4 < Version 2.2, as of 11/17/87 --- > Version 2.4, as of 5/1/88 17a18,21 > Version 2.3 released March, 1988 - corrected gears.c to avoid interpenetration, > corrected and added further instructions and global statistics for ray > tracing to README. > Version 2.4 released May, 1988 - fixed hashing function for mountain.c. 55a60,63 > The images for these databases and other information about them can be > found in "A Proposal for Standard Graphics Environments," IEEE Computer > Graphics & Applications, November 1987, pages 3-5. A corrected image of the > tree appears in IEEE CG&A, January 1987, page 18. 56a65,69 > At present, the SPD package is available for the IBM PC on 360K 5.25" > floppy for $5 from: MicroDoc, c/o F.W. Pospeschil, 3108 Jackson Street, > Bellevue, Nebraska 68005. > > 138c151 < background 0% 7% 47% 0% 81% 35% --- > background 0% 7% 34% 0% 81% 35% 141,142d153 < ave tree size 1.79 3.02 3.71 2.19 1.00 1.00 < ave light rays 3.39 6.43 0.80 4.09 0.18 4.17 143a155,159 > eye hit rays 263169 245532 173422 263169 49806 170134 > reflect rays 175616 305561 355355 316621 0 0 > refract rays 0 208153 355355 0 0 0 > shadow rays 954544 2126105 362657 1087366 46150 1099748 > 171,176c187,191 < percentage of background color (empty space) seen directly by the eye. Note < that any information in units of pixels is view dependent, and so is for the < view specified. "ave tree size" is the average number of rays in a ray tree. < "ave light rays" is the average number of shadow testing rays formed per tree < (note that if a surface is facing away from a light, or the background is hit, < a light ray is not formed). "K" means exactly 1000 (not 1024). --- > percentage of background color (empty space) seen directly by the eye for the > given view. It is calculated by "1 - ( eye hit rays/(513*513) )", since > 513 x 513 rays are generated from the eye. "specular" tells if there are > reflective objects in the scene, and "transmitter" if there are transparent > objects. 177a193,200 > "eye hit rays" is the number of rays from the eye which actually hit an > object (i.e. not the background). "reflect rays" is the total number of rays > generated by reflection off of reflecting and transmitting surfaces. "refract > rays" is the number of rays generated by transmitting surfaces. "shadow rays" > is the sum total of rays shot towards the lights. Note that if a surface is > facing away from a light, or the background is hit, a light ray is not formed. > The numbers given can vary noticeably from a given ray tracer, but should all > be within about 10%. 178a202,204 > "K" means exactly 1000 (not 1024), with number rounded to the nearest K. > > 341,344c367,369 < corners (meaning that at least 513 x 513 eye rays will be created). < The four corner contributions are averaged to arrive at a pixel < value. If this is not done, note this fact. No pixel subdivision < is performed. --- > corners (meaning that 513 x 513 eye rays will be created). The four > corner contributions are averaged to arrive at a pixel value. If this > is not done, note this fact. No pixel subdivision is performed. 348,352c373,377 < 5) All rays hitting specular and transmitting objects spawn reflection < rays, unless the maximum ray depth was reached by the spawning ray. < No adaptive tree depth cutoff is allowed; that is, all rays must be < spawned (adaptive tree depth is a proven time saver and is also < dependent on the color model used). --- > 5) All rays hitting only specular and transmitting objects spawn > reflection rays, unless the maximum ray depth was reached by the > spawning ray. No adaptive tree depth cutoff is allowed; that is, all > rays must be spawned (adaptive tree depth is a proven time saver and > is also dependent on the color model used). 355,358c380,383 < the maximum ray depth was reached. Transmitting rays should be < refracted (i.e. should not pass straight through an object). If total < internal reflection of a ray occurs, then only a reflection ray is < generated at this node. --- > the maximum ray depth was reached or total internal reflection occurs. > Transmitting rays should be refracted using Snell's (i.e. should not > pass straight through an object). If total internal reflection occurs, > then only a reflection ray is generated at this node. 360,361c385,386 < 7) Assume no hierarchy is given with the database (for example, color < change cannot be used to signal a clustering). --- > 7) A shadow ray is not generated if the surface normal points away from > the light. 363c388,392 < 8) Timing costs should be separated into at least two areas: preprocessing --- > 8) Assume no hierarchy is given with the database (for example, color > change cannot be used to signal a clustering). The ray tracing program > itself can create its own hierarchy, of course. > > 9) Timing costs should be separated into at least two areas: preprocessing 371c400 < 9) Other timing costs which would be of interest is a breakdown of --- > 10) Other timing costs which would be of interest is a breakdown of 389c418 < Kflops. However, some HP hardware engineer told me that the HP 320 is twice --- > Kflops. However, an HP hardware engineer told me that the HP 320 is twice 396c425 < language used (i.e. optimized "C", single point precision in general). --- > language used (i.e. optimized "C", single precision in general). 466c495 < number of eye rays which hit background: 213219 [ 81% ] --- > number of eye rays which hit background: 213363 [ 81% ] 469c498 < total number of shadow rays generated: 46262 --- > total number of shadow rays generated: 46150 490,491c519,520 < environment). Same question with the effects of moving light source positions < along the line defined by the light and "lookat" positions. --- > environment). Same question with the effects on the algorithms of moving light > source positions along the line defined by the light and "lookat" positions. 520,526c549,555 < Elmquist, Jeff Goldsmith, Donald Greenberg, Susan Spach, Rick Speer, John < Wallace, and Louise Watson. Other people who have freely offered their ideas < and opinions on this project include Brian Barsky, Andrew Glassner, Roy Hall, < Chip Hatfield, Tim Kay, John Recker, Paul Strauss, and Chan Verbeck. These < names are mentioned mostly as a listing of people interested in this idea. < They do not necessarily agree (and in some cases strongly disagree) with the < validity of the concept or the choice of databases. --- > Elmquist, Jeff Goldsmith, Donald Greenberg, Susan Spach, Rick Speer, K.R. > Subramanian, John Wallace, and Louise Watson. Other people who have freely > offered their ideas and opinions on this project include Brian Barsky, Andrew > Glassner, Roy Hall, Chip Hatfield, Tim Kay, John Recker, Paul Strauss, and Chan > Verbeck. These names are mentioned mostly as a listing of people interested in > this idea. They do not necessarily agree (and in some cases strongly disagree) > with the validity of the concept or the choice of databases. *** old/gears.c --- new/gears.c 6c6 < * Five light sources. --- > * Five light sources. 8c8 < * Version: 2.2 (11/17/87) --- > * Version: 2.3 (3/1?/88) 33c33,41 < #define EDGE_RATIO 0.1 --- > /* the outer radius is made slightly smaller that the full radius to create > * a finite separation between intermeshing gears. This gets rid of the bug > * of having two surfaces occupy exactly the same space. Note that if these > * are changed, the gears may interpenetrate. > */ > #define OUTER_EDGE_RATIO 0.995 > #define INNER_EDGE_RATIO 0.9 > #define EDGE_DIFF ( 1.0 - INNER_EDGE_RATIO ) > /* ratio of width of gear to thickness */ 81c89 < ( (double)SIZE_FACTOR - (double)(SIZE_FACTOR-1) * EDGE_RATIO / 2.0 ) ; --- > ( (double)SIZE_FACTOR - (double)(SIZE_FACTOR-1) * EDGE_DIFF / 2.0 ) ; 86c94 < offset.x = offset.y = outer_radius * ( 2.0 - EDGE_RATIO ) ; --- > offset.x = offset.y = outer_radius * ( 2.0 - EDGE_DIFF ) ; 122,123c130,131 < outer_radius, < (1.0 - EDGE_RATIO) * outer_radius, --- > OUTER_EDGE_RATIO * outer_radius, > (1.0 - EDGE_DIFF) * outer_radius, *** old/mountain.c --- new/mountain.c 7c7,15 < * Version: 2.2 (11/17/87) --- > * NOTE: the hashing function used to generate the database originally is > * faulty. The function causes repetition to occur within the fractal > * mountain (obviously not very fractal behavior!). A new hashing function > * is included immediately after the old one: merely define NEW_HASH if > * you want to use a good hashing function. To perform ray tracing > * comparison tests you should still use the old, faulty database (it may > * have repetition, but it's still a good test image). > * > * Version: 2.4 (5/1/88) 26a35,37 > /* to use the corrected hashing function, uncomment this next line */ > /* #define NEW_HASH */ > 41c52,56 < /* hashing function to get a seed for the random number generator */ --- > #ifndef NEW_HASH > > /* Hashing function to get a seed for the random number generator. */ > /* This is the old, buggy hashing function - use it if you wish to > * obtain the same image as in the November 1987 IEEE CG&A article. */ 44a60,77 > #else > > /* New, corrected hashing function. Use for a true fractal mountain */ > /* 134456 is M1 in routine lib_gauss_rand() */ > #define hash_rand(A,B,C) ( ( C <= 15 ) ? \ > ( ABSOLUTE( \ > ((A)<<(31-(C))) \ > + ((B)<<(15-(C))) ) \ > % 134456 ) \ > : \ > ( ABSOLUTE( \ > ((A)<<(31-(C))) \ > + ((B)>>((C)-15)) ) \ > % 134456 ) \ > ) > > #endif > 56d88 <