home *** CD-ROM | disk | FTP | other *** search
/ Borland Programmer's Resource / Borland_Programmers_Resource_CD_1995.iso / code / graphics / rtnews / rtnv2n4 < prev    next >
Encoding:
Text File  |  1995-05-19  |  27.2 KB  |  647 lines

  1.  _ __                 ______                         _ __
  2. ' )  )                  /                           ' )  )
  3.  /--' __.  __  ,     --/ __  __.  _. o ____  _,      /  / _  , , , _
  4. /  \_(_/|_/ (_/_    (_/ / (_(_/|_(__<_/ / <_(_)_    /  (_</_(_(_/_/_)_
  5.              /                               /|
  6.             '                               |/
  7.  
  8.             "Light Makes Right"
  9.  
  10.                June 21, 1989
  11.                 Volume 2, Number 4
  12.  
  13. Compiled by Eric Haines, 3D/Eye Inc, 2359 Triphammer Rd, Ithaca, NY 14850
  14.     607-257-1381, hpfcla!hpfcrs!eye!erich@hplabs.hp.com, cornell!eye!erich
  15. All contents are US copyright (c) 1989 by the individual authors
  16.  
  17. Contents:
  18.     Introduction
  19.     Hardcopy News (Andrew Glassner)
  20.     New People (Stuart Green, Craig Kolb (and Ken Musgrave), Kaveh Kardan)
  21.     Comments on "Free" Ray Tracers and on Renderman (Kaveh Kardan)
  22.     Minimum Bounding Sphere, continued (Jack Ritter)
  23.     Comments on "A Review of Multi-Computer Ray-Tracing" (Thierry Priol)
  24.     ======== USENET cullings follow ========
  25.     Query: Dataflow Architectures and Ray Tracing (George Kyriazis)
  26.     More on Pixar's Noise Function (Jon Buller)
  27.     DBW_render for Sun 3 (Tad Guy)
  28.     Steel Colors (Eugene Miya)
  29.     Dirty Little Tricks (Jack Ritter)
  30.     Obfuscated Ray Tracer (George Kyriazis)
  31.     Contents of FTP archives, skinner.cs.uoregon.edu (Mark VandeWettering)
  32.  
  33. -----------------------------------------------------------------------------
  34.  
  35. Introduction
  36. ------------
  37.  
  38. First off, please note that I now have a second mail address:
  39.  
  40.     eye!erich@wrath.cs.cornell.edu
  41.  
  42. This is a lot more direct than hopping the HP network through Palo Alto and
  43. Colorado just to get to Ithaca.  We have the connection courtesy of the
  44. Computer Science Dept at Cornell, and they have asked us to try to keep our
  45. traffic down.  So, please don't be a funny guy and send me image files or
  46. somesuch.
  47.  
  48. I just noticed that Andrew and I are out of sync: his hardcopy version is on
  49. Volume 3, and I'm on Volume 2.  One excuse is that the first year of the email
  50. edition is labeled "Volume 0", since it wasn't even called "The Ray Tracing
  51. News" at that point.  An alternate excuse is that I program in "C", and so
  52. start from 0.  Anyway, until maybe the new year, I'll stick with the current
  53. scheme (hey, no one even noticed that last issue was misnumbered (and corrected
  54. on the USENET copy)).
  55.  
  56. -----------------------------------------------------------------------------
  57.  
  58. Hardcopy News
  59. -------------
  60.  
  61. by Andrew Glassner
  62.  
  63.  
  64. The latest issue of the hardcopy Ray Tracing News (Volume 3, Number 1, May
  65. 1989) goes into the mail today, 31 May.  Everyone who is on the softcopy
  66. mailing list should receive a copy.  If you don't get a copy in a week or two,
  67. please let me know (glassner.pa@xerox.com).  It would help if you include your
  68. physical mailing address, so I can at least confirm that your issue was
  69. intended to go to the right place.
  70.  
  71. Contributions are now being solicited for Vol. 3, No. 2.  Start working on
  72. those articles!
  73.  
  74. -----------------------------------------------------------------------------
  75.  
  76. New (and Used?) People
  77. ----------------------
  78.  
  79. The Cornell Program of Computer Graphics computers have all changed their
  80. addresses.  Any computer with the name "*.tn.cornell.edu" is now
  81. "*.graphics.cornell.edu".
  82.  
  83. ------------
  84.  
  85. Stuart Green            - multiprocessor systems for realistic image synthesis
  86. Department of Computer Science
  87. University of Bristol
  88. Queen's Building
  89. University Walk
  90. Bristol.  BS8 1TR
  91. ENGLAND.
  92. green@uk.ac.bristol.compsci
  93.  
  94. I am working on multiprocessor implementations of algorithms for realistic
  95. image synthesis.  So far, this has been restricted to straightforward ray
  96. tracing, but I hope to look at enhanced ray tracing algorithms and radiosity.
  97. I've implemented a ray tracer on a network of Inmos Transputers which uses
  98. mechanisms for distributing both computation and the model data amongst the
  99. processors in a distributed memory MIMD system.
  100.  
  101. ------------
  102.  
  103. Craig Kolb (and Ken Musgrave)
  104.  
  105. My primary interests include modeling natural phenomena, realistic image
  106. synthesis, and animation.
  107.  
  108. I can be reached at:
  109. Dept. of Mathematics
  110. Yale University
  111. P.O. Box 2155
  112. Yale Station
  113. New Haven, CT  06520-2155
  114. (203) 432-7053
  115.  
  116. alias    craig_kolb    craig@weedeater.math.yale.edu
  117. alias    ken_musgrave    musgrave-forest@yale.edu
  118.  
  119. ...I've just started looking into ray/spline intersection.  We do a lot of
  120. heightfield-tracing 'round here, and in the past have rendered them using a
  121. triangle tessellation.  I'm giving splines a shot in order to render some
  122. pictures of eroded terrain for our SIGGRAPH talk.  I notice that you list
  123. spline intersection among your primary interests.  What sort of methods have
  124. you investigated?  At the moment I've implemented (what I assume is) the
  125. standard Newton's method in tandem with a DDA-based cell traversal scheme (as
  126. per our SIGGRAPH paper).  Although this works, it's not exactly blindingly
  127. fast...  Do you know of any 'interesting' references?
  128.  
  129. ------------
  130.  
  131. Kaveh Kardan
  132. Visual Edge Software Ltd.
  133. 3870 Cote Vertu
  134. Montreal, Quebec H4R 1V4
  135. (514)332-6430
  136. larry.mcrim.mcgill.edu!vedge!kaveh
  137.  
  138. I graduated with a BS in Math from MIT in 1985, did some work in molecular
  139. graphics at the Xerox Research Centre of Canada (XRCC), wrote the renderer at
  140. Neo-Visuals (now known as SAS Canada) -- which included a raytracer --, and the
  141. animation stuff at Softimage.  I'm currently working at Visual Edge on the UIMX
  142. package: an X Windows user interface design system.
  143.  
  144. Regarding the Softimage raytracer: it was written by Mike Sweeney (who used
  145. to be at Abel, and who did "Crater Lake" at Waterloo).
  146.  
  147. I will also be acting as a mail forwarder for Mike, as Softimage is not on any
  148. networks.  So in effect, you should probably include Mike in the mailing list
  149. as well, with my address -- or somehow let people know that he can be reached
  150. tc/o me.
  151.  
  152. If I may make some comments about the stuff I have read so far in the back
  153. issues:
  154.  
  155. ====================
  156.  
  157. Jeff Goldsmith writes:
  158.  
  159. >    I don't get it.  Why doesn't every CG Software vendor supply a
  160. >ray tracer.  It's definitely the easiest renderer to write.  Yes,
  161. >they are slo-o-o-o-o-o-w, but they sound glitzy and (I bet) would
  162. >stimulate sales, even if buyers never used them.
  163.  
  164. Having worked at two CG Software companies, I know firsthand how the "to do"
  165. list grows faster than you can possibly implement features (no matter how many
  166. programmers you have -- c.f."The Mythical Man-Month").
  167.  
  168. Jeff is right that ray tracing sounds glitzy, and, yes, it is another factor to
  169. toss into the sales pitch -- but it is not at all clear that it is worth the
  170. effort.
  171.  
  172. Most (if not all) ray tracers assume either infinite rendering time or infinite
  173. disk space.  In the real world (a 68020 and a 144Meg disk) this is not the
  174. case.  The raytracer I wrote at Neo Visuals was written in Fortran -- ergo no
  175. dynamic memory allocation -- so I had to work on optimizing it without
  176. significantly increasing the memory used.  This mostly involved intelligently
  177. choosing when to fire rays.  The renderer performs a Watkins-style rendering,
  178. and fires secondary rays from a pixel only if the surface at that pixel needs
  179. to be raytraced.  Memory constraints prevented me from using any spatial
  180. subdivision methods.
  181.  
  182. Yes, ray traced images are great sales tools.  They are also sometimes not
  183. entirely honest -- novice users ("I want a system to animate Star Wars quality
  184. images, about ten minutes of animation a day on my XT") are not aware of the
  185. expense of raytracing, and very few salesmen go out of their way to point this
  186. out.  However, these same users, unsure of the technology, put together a list
  187. of buzzwords (amongst them "raytracing") and go out to find that piece of
  188. software which has the most features on their list.  Hence I coined the phrase
  189. "buzzword compatible" while at Neo-Visuals (and also "polygons for polygons
  190. sake" -- but that's another story).
  191.  
  192. I have also seen demos, animations, and pictures at trade shows, presented by
  193. hardware and software vendors, which were extremely and deliberately
  194. misleading.  A very common example is to show nice animation that was not
  195. really created with your software product.  The animation having been typically
  196. created by special programs and add-ons.  An obvious example was Abel,
  197. marketing their "Generation 2" software with "Sexy Robot", "Gold", "Hawaiian
  198. Punch", etc.  I only mention Abel because they are no longer in business -- I
  199. don't want to mention any names of existing companies.
  200.  
  201. I hadn't intended this to be a flame.  But that sums up why not all software
  202. vendors bother with raytracing, and how it can be abused if not handled
  203. carefully.
  204.  
  205. ====================
  206.  
  207. On Steve Upstill's remarks on the Renderman standard:
  208.  
  209. Disclaimer: I have not read the Renderman specs, and have spoken to people who
  210. liked it and people who didn't.
  211.  
  212. I would like to say that while I was at Neo-Visuals, Tom Porter and Pat
  213. Hanrahan did indeed drop by to ask us about our needs, and to ensure that the
  214. interface would be compatible with our system.  As I recall, we asked that the
  215. interface be able of handling arbitrary polygons (n vertices, concave, etc).
  216. As I recall, I was playing devil's advocate at the meeting, questioning
  217. whether rendering had settled down enough to be standardized.  So yes, at
  218. least Neo-Visuals did get to have a say and contribute to the interface.
  219.  
  220. I spoke to one rendering person at Siggraph who didn't appreciate the way Pixar
  221. had handed down the interface and said "thou shalt enjoy."  Well the
  222. alternative would be a PHIGS-like process: years spent in committees trying to
  223. hash out a compromise which will in all likelihood be obsolete before the ink
  224. is dry.  In fact, two hardware vendors decided to take matters into their own
  225. hands and came up with PHIGS+.
  226.  
  227. Yes, the interface is probably partly a marketing initiative by Pixar.  Why
  228. would they do it otherwise?  Why should they do it otherwise?  I would guess
  229. that Pixar hopes to have the standard adopted, then come out with a board which
  230. will do Renderman rendering faster than anyone else's software.  This seems a
  231. natural progression.  More and more rendering features have been appearing in
  232. hardware -- 2D, 3D, flat shaded, Gouraud, and now Phong and texture maps.  It
  233. is very probable that in a few years, "renderers" will be hardware, except for
  234. experimental, research, and prototype ones.
  235.  
  236. -----------------------------------------------------------------------------
  237.  
  238. Minimum Bounding Sphere, continued
  239. ----------------------------------
  240.  
  241.     by Jack Ritter, {ames,apple,sun,pyramid}!versatc!ritter
  242.  
  243. I noticed in "The Ray Tracing News" an answer to my query about minimum
  244. bounding spheres. The answer following my question assumes there are 3 points.
  245. (Search for "Ray Traced Bounding Spheres").  This is wrong; I meant n points in
  246. 3 space.  Since then, Lyle Rains, Wolfgang Someone and I have arrived at a fast
  247. way to find a tight bounding sphere for n points in 3 space:
  248.  
  249. 1) Make 1 pass through pts. Find these 6 pts:
  250.     pt with min x, max x, min/max y, min/max z.
  251.     Pick the pair with the widest dimensional span. This describes the
  252.     diameter of the initial bounding sphere. If the pts are anywhere near
  253.     uniform, this sphere will contain most pts.
  254.  
  255. 2) Make 2nd pass through pts: for each pt still outside current sphere, update
  256.     current sphere to the larger sphere passing through the pt on 1 side,
  257.     and the back side of the old sphere on the other side.  Each new sphere
  258.     will (barely) contain its previous pts, plus the new pt, and probably
  259.     some new outsiders as well. Step 2 should need to be done only a small
  260.     fraction of total num pts.
  261.  
  262. The following is code (untested as far as I know) to increment sp:
  263.  
  264. typedef double Ordinate;
  265. typedef double Distance;
  266. typedef struct { Ordinate x; Ordinate y; Ordinate z; } Point;
  267. typedef struct { Point center; Distance radius; } Sphere;
  268.  
  269.  
  270. Distance separation(pa, pb)
  271.   Point *pa;
  272.   Point *pb;
  273. {
  274.   Distance delta_x, delta_y, delta_z;
  275.  
  276.   delta_x = pa->x - pb->x;
  277.   delta_y = pa->y - pb->y;
  278.   delta_z = pa->z - pb->z;
  279.   return (sqrt(delta_x * delta_x + delta_y * delta_y + delta_z * delta_z));
  280. }
  281.  
  282.  
  283. Sphere *new_sphere(s, p)
  284.   Sphere *s;
  285.   Point *p;
  286. {
  287.   Distance old_to_p;
  288.   Distance old_to_new;
  289.  
  290.   old_to_p = separation(&s->center, p);
  291.   if (old_to_p > s->radius) { /* could test vs r**2 here */
  292.     s->radius = (s->radius + old_to_p) / 2.0;
  293.     old_to_new = old_to_p - s->radius;
  294.     s->center.x =
  295.       (s->radius * s->center.x + old_to_new * p->x) / old_to_p;
  296.     s->center.y =
  297.       (s->radius * s->center.y + old_to_new * p->y) / old_to_p;
  298.     s->center.z =
  299.       (s->radius * s->center.z + old_to_new * p->z) / old_to_p;
  300.   }
  301.   return (s);
  302. }
  303.  
  304.    Jack Ritter, S/W Eng. Versatec, 2710 Walsh Av, Santa Clara, CA 95051
  305.    Mail Stop 1-7.  (408)982-4332, or (408)988-2800 X 5743
  306.    UUCP:  {ames,apple,sun,pyramid}!versatc!ritter
  307.  
  308. [This looks to be a good quick algorithm giving a near-optimal solution.  Has
  309. anyone come up with an absolutely optimal solution?  The "three point" solution
  310. (in last issue) gives us a tool to do a brute force search of all triplets, but
  311. this is insufficient to solve the problem.  For example, a tetrahedron's
  312. bounding sphere cannot be found by just searching all the triplets, as all such
  313. spheres would leave out the fourth point. - EAH]
  314.  
  315. -----------------------------------------------------------------------------
  316.  
  317. Comments on "A Review of Multi-Computer Ray-Tracing"
  318. ---------------------------------------------------
  319.  
  320. by Thierry Priol
  321.  
  322.  
  323. I read with a great interest in the hardcopy "Ray Tracing News (May 1989)" "A
  324. Review of Multi-Computer Ray-Tracing".  But, D.A.J. Jevans said that our work
  325. presented in CGI "may even serve to cloud the important issues in
  326. multi-computer ray-tracing"!  I do not agree with this remark.  The
  327. presentation at CGI describes only a first step in using multi-processor ray
  328. tracing algorithms.  It is true that there were no interesting results in this
  329. paper.  D.A.J. Jevans also said that a hypercube architecture is hardware
  330. specific.  I do not agree.  This kind of architecture represents a great part
  331. of distributed memory architectures.  Our algorithm is not specific for this
  332. topology and can work on a SYMULT-2010 which uses a mesh topology.  However, I
  333. agree when he said that our algorithm provides little in the way of new
  334. algorithms, since we used Cleary's algorithm.  But we think that for the
  335. moment, the main problem is not to create new algorithms but to make
  336. experiments with some algorithms presented by several authors because most of
  337. them have been simulated but not implemented.  Our experiments show that many
  338. problems due to distributed computing (not only load and memory balancing) were
  339. not solved by the authors.
  340.  
  341. At present, our algorithm has been modified to take into account load balancing
  342. and we have several results not yet published.  These new results may give some
  343. important conclusions about the Cleary approach (processor-volume association).
  344. We are working now on a new algorithm based on a global memory on distributed
  345. memory architectures!  For my mind it is the best solution to obtain load and
  346. memory balancing.  The ray coherence property is a means to have a sort of
  347. locality when data is read in the global memory (best use of caches).
  348.  
  349. We are very interested (D. Badouel, K. Bouatouch and myself) in submitting to
  350. the "Ray-tracing News" a short paper which summarizes our work in parallel
  351. ray-tracing algorithm for distributed memory architecture.  This contribution
  352. should present two ray tracing algorithms with associated results.  This work
  353. has not been yet published outside France.
  354.  
  355. ======== USENET cullings follow ===============================================
  356.  
  357. Subject: Dataflow architectures and Ray Tracing
  358. From: kyriazis@rpics (George Kyriazis)
  359. Newsgroups: comp.arch,comp.graphics
  360. Organization: RPI CS Dept.
  361.  
  362. Hi!  I am wondering if anybody knows if there have been any attempts to port a
  363. ray tracing algorithm on a dataflow computer, or if there has been such a
  364. machine especially built for ray tracing.
  365.  
  366. I am posting to both comp.arch and comp.graphics since I think that it concerns
  367. both newsgroups.
  368.  
  369. It seems to me that a dynamic dataflow architecture is more appropriate to this
  370. problem because of the recursiveness and parallelism of the algorithm.
  371.  
  372. Thanks in advance for any info...
  373.  
  374. -----------------------------------------------------------------------------
  375.  
  376. Subject: Re: Pixar's noise function
  377. Summary: my noise, better described (I hope)
  378. Reply-To: bullerj@handel.colostate.edu.UUCP (Jon Buller)
  379. Organization: Colorado State University, Ft. Collins CO 80523
  380.  
  381. In article <...> jamesa@arabian.Sun.COM (James D. Allen) writes:
  382. >In article <...>, aaa@pixar.UUCP (Tony Apodaca) writes:
  383. >> In article <...> coy@ssc-vax.UUCP (Stephen B Coy) writes:
  384. >> >          ...My question:  Does anyone out there know what this
  385. >> >noise function really is?
  386. >> 
  387. >> ... Conceptually, noise()
  388. >> is a "stochastic three-dimensional function which is statistically
  389. >> invariant under rotation and translation and has a narrow bandpass
  390. >> limit in frequency" (paraphrased from [Perlin1985]).  This means that
  391. >> you put three-space points in, and you get values back which are basically
  392. >> random.  But if you put other nearby points in, you get values that are
  393. >> very similar.  The differences are still random, but the maximum rate of
  394. >> change is controlled so that you can avoid aliasing.  If you put a set
  395. >> of points in from a different region of space, you will get values out
  396. >> which have "the same amount" of randomness.
  397. >
  398. >       Anyone willing to post a detailed description of such an
  399. >       algorithm?  (Jon Buller posted one, but I couldn't figure it out:
  400. >       what is `Pts'?)
  401.  
  402. Sorry about not really describing my program to anyone, I know what it does,
  403. and I never expected anyone else to see it (isn't it obvious) :-)
  404.  
  405. What it does is: pass a location in space, and an array of random numbers (this
  406. is 'Pts').  I fill the array with 0.0 .. 1.0 but any values or range will work.
  407. (I have other textures which color based on distance to the nearest point of a
  408. random set, hence the name, It has 4 values per entry at times.)
  409.  
  410. Step 1: change the location to a group of points to interpolate.  This is where
  411. xa,xb,xc,...zc come in, any location with the same coords (when trunc'ed) will
  412. produce the same xa...zc values, making the same values for the interpolation
  413. at the end.  These xa..zc are then hashed in to the 'Pts' array to produce
  414. p000...P222, these 27 random numbers are then interpolated with a Quadratic 3d
  415. B-Spline (the long ugly formula at the end).  The variables based on xf,yf, and
  416. zf (I believe they are x0..z2) are the B-Spline basis functions (notice to get
  417. DNoise, just take the (partial) derivatives of the basis functions and
  418. re-evaluate the spline).
  419.  
  420. Step 2: now you have a value that is always smaller than the largest random
  421. number in 'Pts' (equal to in the odd case that major bunches of the numbers are
  422. also the maximum in the range).  By the same argument, all numbers returned are
  423. larger than the smallest number in the array. (this can be handy if you don't
  424. want to have to clip your values to some limit.)
  425.  
  426. I hope this explains the use of the routine better.  Sorry I didn't realize
  427. that earlier.  If you have any other questions about it, mail them to me, and
  428. I'll do my best to explain it.
  429.  
  430. Jon
  431.  
  432. -----------------------------------------------------------------------------
  433.  
  434. From: tadguy@cs.odu.edu (Tad Guy)
  435. Newsgroups: comp.graphics
  436. Subject: Re: DBW_render for SUN 3 ?
  437. Organization: Old Dominion University, Norfolk, VA
  438.  
  439. daniel@unmvax.unm.edu writes:
  440. >Has anyone converted the public domain ray trace program called DBW_render
  441. >to run on a SUN workstation?
  442.  
  443. Ofer Licht <ofer@gandalf.berkeley.edu> has done just that.  His modified
  444. DBW_Render is available via anonymous ftp from xanth.cs.odu.edu as
  445. /amiga/dbw.zoo.  It is also designed to use ``DistPro'' to distribute the
  446. computations between many machines (this is available as well as
  447. /amiga/distpro.zoo).
  448.  
  449. His address:
  450.  
  451.     Ofer Licht  (ofer@gandalf.berkeley.edu)
  452.     1807 Addison St. #4
  453.     Berkeley, CA 94703
  454.     (415) 540-0266
  455.  
  456. -----------------------------------------------------------------------------
  457.  
  458. From: eugene@eos.UUCP (Eugene Miya)
  459. Newsgroups: comp.graphics
  460. Subject: Re: Steel colors
  461. Organization: NASA Ames Research Center, Calif.
  462.  
  463. In article <...> jwl@ernie.Berkeley.EDU.UUCP (James Wilbur Lewis) writes:
  464. >In article <...> jep@oink.UUCP (James E. Prior) writes:
  465. >>I've noticed that when I look closely at reasonably clean bare steel in good
  466. >>sunlight that it appears to have a very fine grain of colors.  
  467. >>
  468. >>What is this due to?
  469. >
  470. >Probably a diffraction-grating type effect due to scratches, roughness, or
  471. >possibly crystalline structure at the surface.
  472.  
  473. Funny you should mention this.  I was sitting with my officemate, George
  474. Michael, he says Hi Kelly, and we were talking about stuff and he brought up
  475. the subject of polish.  He said there were people at Livenomore who were
  476. researching the issue of polish for big mirrors, but that polish really isn't
  477. well understood, still open interesting physical science questions.  Polish
  478. consists of minute "scratches" which have a set of interesting properties.  You
  479. can probably [write] to them and get TRs on the topic.  Polish is more than
  480. iridescence.
  481.  
  482. Also, since somebody asked, the date on the Science article by Greenberg on
  483. Light reflection models for graphics is 14 April 1989, page 166.  It will
  484. provide simple models for this type of stuff.
  485.  
  486. -----------------------------------------------------------------------------
  487.  
  488. From: ritter@versatc.UUCP (Jack Ritter)
  489. Newsgroups: comp.graphics
  490. Subject: Dirty Little Tricks
  491. Organization: Versatec, Santa Clara, Ca. 95051
  492.  
  493. I've come up with a fast approximation to
  494. 3D Euclidean distance ( sqrt(dx*dx+dy*dy+dz*dz) ).
  495.   (It's probably not original, but .....)
  496.  
  497. 1) find these 3 values: abs(dx), abs(dy), abs(dz).
  498.  
  499. 2) Sort them (3 compares, 0-3 swaps)
  500.  
  501. 3) Approx E.D. = max + (1/4)med + (1/4)min.
  502.                         (error: +/- 13%) 
  503.  
  504.         max +  (5/16)med + (1/4)min has  9% error.
  505.         max + (11/32)med + (1/4)min has  8% error.
  506.  
  507. As you can see, only shifts & adds are used, and it can be done with integer
  508. arithmetic.  It could be used in ray tracing as a preliminary test before using
  509. the exact form.
  510.  
  511. We all have our dirty little tricks.
  512.  
  513. -----------------------------------------------------------------------------
  514.  
  515. From: kyriazis@turing.cs.rpi.edu (George Kyriazis)
  516. Newsgroups: comp.graphics
  517. Subject: Obfuscated ray tracer
  518. Organization: RPI CS Dept.
  519.  
  520. A while ago, while it was still snowing, I was feeling adventurous, and a nice
  521. weekend I decided to write an obfuscated ray tracer.  A friend of mine told me
  522. that is not too obfuscated for the "Obfuscated C Contest", I had already wasted
  523. one whole day, so I gave up.  Today, I was cleaning up my account, and I
  524. thought it would be a very appropriate posting for comp.graphics.
  525.  
  526. It is a hacker's approach to ray tracing; produces a text image on the screen.
  527. No shading; different characters represent different objects.  The source code
  528. is 762 bytes long.  I KNOW that I'll get flamed, but who cares! :-)
  529.  
  530. Have fun people!
  531.  
  532. So, here it is:
  533.  
  534. Compile with  cc ray.c -o ray -lm
  535.  
  536.  
  537. /* (c) 1988 by George Kyriazis */
  538. #include <math.h>
  539. #define Q "
  540. #define _ define
  541. #_ O return
  542. #define T struct
  543. #_ G if
  544. #_ A(a,b) (a=b)
  545. #define D double
  546. #_ F for
  547. #define P (void)printf(Q
  548. #define S(x) ((x)*(1/*p-"hello"[6])/*comment*/*x))
  549. T oo{D q,r,s,t;};int m[1]={2};T oo o[2]={{10,10,10,18},{15,15,17,27}};int x,y;D
  550. I(i){D b,c,s1,s2;int*p=0,q[1];b=i/*p+1["_P]+(1-x*x)*erf(M_PI/i)/1*/**q+sin(p);{
  551. {b=2*-(i+o)->s;c=S(x-i[o].q)+S(y-o[i].r)+S(i[o].s)-(o+i)->t;}A(s1,S(b));}{G((s2
  552. =(S(b)-4*c)<0?-1:sqrt(-4*c+S(b)))<0){O(b-(int)b)*(i>=0-unix);}}s1=(-b+s2)/2;s2=
  553. s1-s2;s1=s1<=0?s2:s1;s2=s2<=0?s1:s2;O s1<s2?s1:s2;}main(){D z,zz;int i,ii;F(A(y
  554. ,0);y<24;y-=listen(3,0)){F(x-=x;x<40;x++){F(z=!close(y+3),A(i,0);i<*m*(y>-1);i=
  555. A(i,i+1))G(z<(A(zz,I(i))))z=zz,ii=i;G(!!z)P%d",ii);else P%c",32-'\0');}P\n");}}
  556.  
  557. -----------------------------------------------------------------------------
  558.  
  559. Subject: Contents of FTP archives, skinner.cs.uoregon.edu
  560. From: markv@tillamook.cs.uoregon.edu (Mark VandeWettering)
  561. Newsgroups: comp.graphics
  562. Organization: University of Oregon CIS Dept.
  563.  
  564. Recently, the ftp archive of raytracing stuff was moved from our dying
  565. VAX-750 (drizzle.cs.uoregon.edu) to our new fileserver, which is called
  566. skinner.cs.uoregon.edu, or just cs.uoregon.edu.
  567.  
  568. There is more diskspace available, and I have expanded the archives to contain
  569. several new items.  I thought I would post the README here to let people know
  570. of its availability.
  571.  
  572. skinner.cs.uoregon.edu contains information largely dealing with the subject of
  573. raytracing, although a radiosity tracer or solid modeler would be a welcome
  574. addition to the contents there.  I am always busy looking for new software
  575. aquisitions, so if you have anything you wish to put there, feel free to send
  576. me a note.
  577.  
  578. Mark VandeWettering
  579.  
  580. -cut-cut-cut-cut-cut-cut-cut-cut-cut-cut-cut-cut-cut-cut-cut-cut-cut-cut-cut-cut
  581.  
  582. The old README was dated, so I thought I would update this new one...
  583.  
  584. dr-xr-xr-x  2 ftp           512 Feb 11 18:53 bibs
  585.  
  586.         contains bibliographies for fields that I am interested in,
  587.         such as graphics and functional programming.
  588.  
  589. drwxrwxr--  2 ftp           512 May 13 23:44 gif.fmt
  590.  
  591.         descriptions of the gif format.  Too many people wanted this, so I 
  592.         thought I would make it available.
  593.  
  594. drwxrwxr-x  2 root          512 May 24 22:25 grafix-utils
  595.  
  596.         Utilities for converting among graphics formats etc.
  597.         Now includes fuzzy bitmap, should also include pbm
  598.         and utah raster toolkit soon.
  599.  
  600. drwxrwxr--  2 ftp          1024 May 14 15:45 hershey
  601.  
  602.         The Hershey Fonts.  Useful PD fonts.
  603.  
  604. drwxrwxr-x  2 root          512 May 24 22:26 mtv-tracer
  605.  
  606.         My raytracer, albeit a dated version.
  607.  
  608. dr-xr-xr-x  2 ftp           512 Feb 16 17:24 musgrave
  609.  
  610.         Copies of papers on refraction by Kenton Musgrave.
  611.  
  612. drwxrwxr-x  2 root          512 May 24 22:26 nff
  613.         
  614.         Haines SPD raytracing package, with some other NFF images
  615.         created by myself & others.  Useful for the mtv raytracer.
  616.  
  617. drwxr-xr-x  2 ftp          1536 May 24 11:44 off-objects
  618.  
  619.         Some interesting, PD or near PD images from the OFF distribution.
  620.  
  621. dr-xr-xr-x  2 ftp           512 Feb 15 22:48 polyhedra
  622.  
  623.         Polyhedra from the netlib server.  I haven't done anything with 
  624.         these...
  625.  
  626. dr-xr-xr-x  2 ftp           512 Mar  6 17:45 qrt
  627.  
  628.         The popular raytracer for PCs.
  629.  
  630. dr-xr-xr-x  2 ftp           512 May 24 22:26 rayfilters
  631.  
  632.         Filters to convert the MTV output to a number of devices...
  633.  
  634. drwxrwxr-x  2 root          512 May 24 22:26 raytracers
  635.  
  636.         Other raytracers....
  637.  
  638. -rw-r--r--  1 ftp        323797 May 24 01:47 sunrpc.tar.Z
  639.  
  640.         SUN RPC v.3.9
  641.  
  642. [All issues of the email version of "The RT News" have been put in the
  643. directory "RTNews" since this posting.]
  644.  
  645. -----------------------------------------------------------------------------
  646. END OF RTNEWS
  647.