_ __ ______ _ __ ' ) ) / ' ) ) /--' __. __ , --/ __ __. _. o ____ _, / / _ , , , _ / \_(_/|_/ (_/_ (_/ / (_(_/|_(__<_/ / <_(_)_ / (_ enclose at least 6 objects per enclosing box (default is c4) m0 -> use simple lighting model (default is m1, which uses a model developed by Paul Strauss of SGI; it's much more complex!) When scenes have a larger amount of simple primitives like spheres and boxes the enclosing strategy isn't as efficient as when they have cones, patches, triangles, letters, etc. The value c4 is a compromise (normally the user shouldn't change it, but sometimes some tuning can be done). [c6 turns out to be a bit better in most cases, but using both options improved performance by at most 4% maximum on my machine. -EAH] The Strauss' model uses some math functions that unfortunately make the rendering somewhat slower then the standard Phong model (this is an area where I think good improvements can be done -- approximating functions like power(), sqrt(), acos()). You can also avoid the problem with the 'rings' scene using an option that increases the number of surfaces -- option '+S2000' means 2000 surfaces (default is 256). To increase the number of objects or lights you can also use '+Sn' or '+Ln'. ---- For those of you who want to know the particulars of the tests, read on: Here are the command lines I used for the various tracers. I tried to use the fastest method available for shadows for transparent objects - each tracer does this a bit different. Mostly I would say "ignore the results for gears and mount" because of the way the methods differ. I used the enhanced Standard Procedural Database package (next article) to test the ray tracers. POV: time povray +ms5000 +i$dog.pov +ft +w1 +h1 -odummy.tga ART: time art $dog.art 512 512 RAYSHADE: time rayshade $dog.ray -o -R 512 512 -O $dog.rle RTRACE: time rtrace c6 m0 +S2000 w512 h512 O1 $dog.rt $dog.ppm BOB: sed -f vivid2bob.sed $dog.b > /tmp/junk mv /tmp/junk $dog.b time bob -s $dog RADIANCE: # uses a converter Greg Ward sent, which I call NFF2Radiance ../../$dog -r 1 | NFF2Radiance -vf $dog.vp > $dog.rad oconv $dog.rad > test.oct time rpict -vf $dog.vp test.oct > $dog.pic ------------------------------------------------------------------------------- An Enhanced Standard Procedural Databases Package, by Eric Haines Alexander Enzmann and Eduard Schwan took the SPD package (which, as you may know, generates procedural models for testing ray tracer speed) and added a ton of code to it. The new code now outputs to these formats: NFF (used by MTV ray tracer; but the SPD always output using this) POV-Ray 1.0 Polyray v1.4, v1.5 Vivid 2.0 Rayshade RTrace 8.0.0 Art 2.3 QRT 1.5 POV-Ray 2.0 (no, it's not officially out yet: format subject to change) PLG format for use with "rend386" Raw triangle output It can also output the models as line drawings to the screen for previewing: IBM, Mac, and HPUX drivers are provided, and new drivers are trivial to write (i.e. draw a line). There is also a program, showdxf, which will convert or display DXF files (actually, a limited subset of these - just 3DFACE entities). There are two sample DXF files, a skull and an f117, included. There's also a sample code file which can be used as a template for writing your own output programs. What's nice about this package is that by writing a program representing your model (or interpreting your model as input a la showdxf.c), you can then convert it to a wide number of formats. I'd love to see more show*.c interpreters (e.g. one for Wavefront obj format so that the cool Viewpoint models at avalon.chinalake.navy.mil can be converted) and other output formats. I did some polishing and whatnot to the distribution and have placed the whole thing at weedeater.math.yale.edu's /incoming directory as SPDup31.tar.Z and SPDup31.zip . Hopefully I didn't futz things too badly (I suspect there needs to be some file renaming for the Mac version), but let me know if I did. Anyway, I hope that the permanent home of the code will be princeton.edu:/pub/Graphics somewhere. ------------------------------------------------------------------------------- Shadows from Refractive Objects, by Steven Collins (steve@crl.hitachi.co.jp) gophcide@cs.montana.edu (Brett Donahue) writes: >After tracing a ray from the view plane and hitting an objects surface, you >cast a ray from that point to the light source. What do you do if there is >a total transparent object with an index of refraction on the path to the >light source? Once this ray is refracted, it will not hit the light source. >Do you just ignore the object? That is what I think POV ray is doing. I >put a transparent object between a plane and the light source; and there >was no shadowed areas. There should be some areas on the plane where the >refracted light would not hit. A moot point indeed. Not many ray-tracers handle this problem correctly. Most take the "easy way out" of either a) ignoring the ray if _any_ obstacle is encountered between the surface and the lightsource or b) if the ray passes through transparent objects only, then attenuate the lighting according to some scattering approximation function. a) always gives rise to completely dark shadows, whereas b) is an improvement in that it gives rise to lighter regions of shadow where the light has been attenuated proportional to the distance of refractive material passed through. Either of these approaches do not capture the caustics effects. There seems to be 2 methods around to do this: either a) send out _lots_ of rays from the surface in the hope that some of them will hit the light source. i.e.: sample the hemisphere above the point of intersection and trace these rays. For better results the hemi-sphere may be importance sampled by determining the solid angle subtended by all light sources. This is of course incredibly expensive computationally and leads to very noisy caustic effects. The alternative approach is to shoot rays from the light sources in a pre- processing step. A number of approaches to this exist. Heckbert proposed shooting may rays from the light sources and storing the intersections of these rays with surfaces as a "texture map" of sorts. Thus when executing the secondary phase, intersections with surfaces use these texture maps as an estimate of the light incident on the surface. Another approach is that of Watt & Watt where a beam tracing first phase performs a similar operation but this time only polygonally defined surfaces are catered for (due to the beam-tracing approach). Here, light beams are traced through the scene and the intersections of these beams with surfaces are stored as polygon feature polygons and used in the "eye-phase" to estimate the caustic light energy. Finally, more recent work (I've just shipped my Siggraph '92 procs. over 3,000 miles away so forgive not being able to give the exact reference) published in Siggraph '92 (was it Kirk and Barr or Snyder...? or Arvo... these guys do so much excellent stuff its hard to keep track) [no, it was Mitchell and Hanrahan -EAH], which involved a more analytic approach to determine the location of the caustic effects by analytically estimating the wave-fronts and caustic cusps resulting from light interacting with a surface of gaussian curvature. This is, as you can probably guess, an area of interesting on-going research. ------------------------------------------------------------------------------- Shadows Through Transmitters, by Eric Haines, Greg Ward, Alexander Enzmann, Stephen Coy, and David Hook In doing the SPD timings tests on the various ray tracers available, I found that each renderer does shadowing of transmitters its own way. This is fair enough: when a transmitter "blocks" a light, there are many ways to handle the situation. One is to treat the transmitter as opaque and simply block any light. Another is to filter the color of the light by the transmitter's surface color. A more elaborate method is to actually compute the length of the ray inside the transmitter and then also attenuate the color using this distance (e.g. Radiance does this). For my tests I tried to pick the fastest option available with the ray tracer. Some comments from the designers: ---- From Greg Ward (the main author of Radiance): As for the shadow under a refracting sphere or such, I just follow the rays through the object to the light source following a refracted path, and if I hit it, I get it, if I don't, I don't. It's not the correct thing to do, but it's better than throwing the contribution away or pretending it's not there, and it does give the appearance of light concentration in some cases. To be honest, I don't care that much about refracting objects as they rarely turn up in architectural scenes. Windows, yes -- crystal balls, no. Yes, the refracted path source testing depends on the size of the light source among other things, so it's not a correct approach (as I said). But it's easy, and strikes me as better than nothing. I don't do any special type of sampling with regards to ray direction -- I just shoot assuming that there's nothing in the way, and if I hit a dielectric surface, I continue to follow the refracted (but not the reflected) ray. Works great for planar surfaces, so it makes most of my users happy. ---- From Alexander Enzmann (an author of POV-Ray): Another thing to consider with POV-Ray (especially in gears) is that diffuse shadows are computed for all surfaces. Several tracers have an option for how many surfaces will have shadows computed (Rayshade and RTrace have several options), some tracers don't ever compute shadows for an "interior" surface of a transparent object (Vivid/BOB). POV-Ray always does the maximum work. The high ratio you got on the gears benchmark comes from that to a great extent and from the fact that POV-Ray doesn't do polygons (has to have the gears broken down into triangles). ---- From Stephen Coy (an author of the Vivid/Bob ray tracers): There actually seem to be two issues here. The first is how the intersection with an "interior" surface is shaded. The second is how shadow colors are calculated. When Vivid/Bob intersects an interior surface the only component that is taken into account is the transparency. This implies that the surface doesn't have a diffuse component (hence no shadows), it doesn't have a specular highlight and there are no reflected rays generated. I've come to believe that my handling of the specular rays and highlights is wrong. As far as the diffuse component goes I think the correct solution is quite a bit tougher. I think that the proper solution would involve the effects of the light all along the ray as it passes through the transparent material. In effect, transparent materials should be treated like participating media where you actually have a diffuse contribution and shadows cast throughout the volume. When it comes to calculating the color of shadows Vivid/Bob gives you a couple of options. With the no_exp_trans flag set, the light color is simply filtered by the transparent component of the material. When this flag is not set (the default) the amount of the filtering is attenuated exponentially based on the distance the ray travels through the material. Note that this has the side-effect of making the material definition scale dependent. Additionally Vivid/Bob also supports fake caustics. For these, the color of the shadow ray is further tweaked based on the angle between the surface normal and the direction of the shadow ray. This was inspired by Andrew Pearce's trick in Graphics Gems I. ---- From David Hook (an author of the "art" ray tracer): Art traces the ray straight through the object checking for texturing and modifying the light passed through accordingly. Apart from the texturing it doesn't seem to cause to much heartache computationally, although, as Greg Ward points out, going straight through without taking into account effects due to refraction fails to produce any caustics, which are the things that make refractive light the most interesting. On the satisfaction-with-the-image side, we have another program using the same shading model that is used by architects, and the lack of caustics has never caused any problems. I sometimes wonder if computer graphics people are the only ones who notice them! ------------------------------------------------------------------------------- Faster Bounding Volume Hierarchies, by Brian Smits (bes@graphics.cornell.edu) and Eric Haines [I'm writing up this idea that Brian passed on to me. It turns out to be quite old, mentioned in Goldsmith's article and in Arvo & Kirk's section of _An Introduction to Ray Tracing_. For whatever reason, I didn't know about it until Brian filled me in (guess I should read things a bit more carefully!). I haven't seen the idea applied to Kay & Kajiya's scheme, nor have I seen any test data about it or seen it used in any free ray tracing software. It's pretty trivial to implement, so I recommend it. -EAH] This article presents a simple way to improve the performance of automatic bounding volume hierarchy schemes. Automatic bounding volume hierarchy methods are one way to improve the efficiency of ray tracing. By putting objects in a nested hierarchy of bounding boxes and testing each ray against these, most of the objects in a scene can be quickly rejected as not intersecting the ray. Goldsmith/Salmon & Scherson/Caspary explored methods of building up a hierarchy of bounding volumes automatically, as did Kay/Kajiya. Kay & Kajiya simply built a hierarchy of boxes by sorting the object set by the object centroid locations in X, then Y, then Z. For example, with a hundred objects in a scene the objects' 3D center points would be sorted by X, and then this sorted list would be split into two sublists of fifty objects each, with a box put around each list. Each sublist in turn would be sorted by their Y centroid values and split into two subboxes with twenty-five objects each, on down until boxes with two objects are created at the bottom of the hierarchy. Goldsmith & Salmon wished to group objects more tightly. Splitting a list of objects may not be such a great strategy: imagine that of our hundred objects, fifty one made up a light fixture and forty nine made up a stapler that the light shines upon. Splitting into two groups of fifty means that one box will include all of the stapler and one piece of the light, and so giving a box which contains a large amount of empty area between the light and the stapler. A tighter bound, e.g. having a box around the stapler and another around the light, would yield better timings. Goldsmith & Salmon's strategy is to randomize the list of objects and feed these into a hierarchy, placing each new object in the hierarchy so as to minimize the overall growth in size of the boxes in the tree. By randomizing the list the first few primitives will tend to create a "skeleton" upon which the rest of the primitives can efficiently become a part. [See the RTNews2 file at princeton.edu for more information.] Brian Smits implemented this scheme in his ray tracer, and Jim Arvo pointed out a simple speed up (mentioned in Goldsmith's article). By trying different randomized lists, various different configurations of the hierarchy occur. These hierarchies can be analyzed by examining their efficiency. The criterion Brian used is the internal cost of the root node (see p. 212 of _An Intro to RT_). Another simple criterion is to sum up the areas of all of the bounding volumes. Each configuration will generate a different value; using the hierarchy with the best value will generally improve performance, since fewer bounding volumes should be intersected overall. So time can be saved overall by spending a little extra time up front generating a few different configurations using different random number seeds. The best random number seed can be saved for a particular scene and reused later to generate this best hierarchy. This is quite a nice thing for fly through animations in particular: one can spend a lot of time up front getting a good hierarchy and then store just one number (the seed) for the best efficiency scheme for the scene. Brian notes: "I found that on some environments that a good hierarchy could take half to a third of the time of a bad hierarchy. `Average' hierarchies tended to be closer to good hierarchies than bad hierarchies, though." ---- (Eric Haines) I have a few comments: This same idea could be used on Kay and Kajiya. Which axis is sorted first, and which order the axes are sorted (e.g. XYZ or XZY), gives six different generation combinations when using Kay and Kajiya. By examining the fitness criterion of the boxes generated for each of these six, the tightest of the six can then be used. I have a copy of POV 2.0beta sitting around which does Kay/Kajiya, so I hacked it to try the various combinations. POV 2.0beta actually uses a different scheme than pure Kay/Kajiya: it sorts each box along the longest axis. For example, if you had 8 spheres in a row along the Z axis, it would come up (reasonably enough) with a hierarchy with each box's contents sorted along the Z axis. Timings for Kay/Kajiya: balls gears mount rings teapot tetra tree shells longest 588 1895 668 1113 306 56 542 1464 area: 5214 881 205 30995 1514 74 74548 604068 XYZ 513- 2019 639+ 1158+ 288+ 54- 516 1661- area: 4420- 938 195 29174+ 1367 72 74361+ 688388 YZX 512 2316- 644 1188 292 52 531 1605 area: 4399 1071- 211 29944 1343 72 74402 686440 ZXY 513- 1735+ 659- 1215- 298 52 549 1554+ area: 4388 764+ 233- 30936- 1334 72 85085- 649846+ YXZ 507+ 1916 656 1182 301- 52 514+ 1658 area: 4420- 884 190+ 29583 1456- 72 74557 696927- ZYX 513- 2006 658 1183 289 52 532 1572 area: 4385+ 869 226 30254 1321+ 72 74382 651506 XZY 508 1892 642 1187 293 52 552- 1579 area: 4402 910 215 30066 1373 72 74616 673416 "longest" is the "sort on the longest axis" scheme which comes with POV 2.0. "XYZ" means sort on the topmost level along X, then the subboxes along Y, then Z, etc. The lowest value in a column (among the simple orderings) and category is marked with "+", the highest with "-". As Brian notes, there's usually one bad hierarchy among the lot next to a bunch of reasonable ones. There is some correlation between the area summation and the resulting rendering time: "gears", in particular, has significantly different results and the best area summation is 1.33 times as fast as the worst (and the area of the best is 1.4 times smaller than the worst). Most of the models have a fair bit of similarity along each axis. Tetra's symmetry is a great example: the axes' order just does not matter. Gears does not, and so different schemes have significantly different results. Using more realistic scenes would be interesting and probably give larger variances in results. What's also interesting is that many of the simple XYZXYZ orderings beat the "pick the longest axis" method in overall timing. In the "mount" and "shells" models the longest axis method is always better (in both timing and area summation), and in the "balls" and "teapot" models the longest axis is always the worst strategy. Another scheme which deserves exploration is to sort on each axis, XYZ, and compare results: using the axis which creates two boxes with the smallest total area would be an interesting strategy which should give fairly low area summations overall. I suspect there is also not much difference between schemes because of the nature of the databases: there's usually one object cluster instead of a few objects separated by distances (as would occur in a room, say), so the different schemes don't make too much difference. I would also suspect wider variations when using Goldsmith/Salmon, as there is a lot more randomness and opportunity to seriously improve (or degrade) performance. As it stands, for these models doing multiple hierarchies for Kay/Kajiya and picking the best doesn't save much time (maybe 4% on average) - kind of disappointing. Using the absolutely longest axis doesn't seem to be a win for these scenes, though for other less homogeneous scenes it might perform better. I don't know why it performs consistently worse for some databases; if nothing else, it does show that intuition is not always a good guide when designing new efficiency schemes. ------------------------------------------------------------------------------- Simple Sun Position Program, by James Ashton (jaa101@deakin.anu.edu.au) Guy Carpenter asks: >I'd like to be able to specify lon, lat, elev, date, time and get an >accurate position for the sun, and position, phase and orientation for >the moon. I think I have all the necessary alg's kicking around, so it >shouldn't be too hard. > >- has anyone already done this? I haven't done it very accurately but I did scrape together a quick and dirty Sun position generator in C. It's only a rough approximation with no attempt to model the equation of time or lesser effects. You provide latitude (in degrees), month (Jan 0th = 1.0, Dec 15th = 12.5, etc) and local time of day (midnight = 0.0, midday = 12.0) and it gives the (x, y, z) coordinates for a rayshade light source direction. Z is up but I forget which axis I made North. It was designed to aid in designing a `Solar house' and I'm sure it's accurate enough for that purpose. It's a model of inefficiency but who cares! #include #include #define DTOR(d) ((d) * M_PI / 180.0) #define SEASON_ANGLE(month) (sin(((month) - 9.7) / 6 * M_PI) * 0.41) #define HOUR_ANGLE(hour) ((hour) / -12 * M_PI) #define POSITION_ANGLE(latitude) (DTOR(latitude)) double latitude, month, hour; main() { double x, y, z; for (;;) { if (scanf(" %lf %lf %lf", &latitude, &month, &hour) != 3) { fprintf(stderr, "bad floats read\n"); exit(1); } x = (-cos(SEASON_ANGLE(month)) * sin(HOUR_ANGLE(hour))), y = (-sin(SEASON_ANGLE(month)) * cos(POSITION_ANGLE(latitude)) + cos(SEASON_ANGLE(month)) * cos(HOUR_ANGLE(hour)) * sin(POSITION_ANGLE(latitude))), z = (-sin(SEASON_ANGLE(month)) * sin(POSITION_ANGLE(latitude)) - cos(SEASON_ANGLE(month)) * cos(HOUR_ANGLE(hour)) * cos(POSITION_ANGLE(latitude))); printf("%f\t%f\t\t%f\n", x, y, z); } } ------------------------------------------------------------------------------- Sphere and Cylinder/Cone/Disc/Annulus Definition, by Eric Haines Jonathan Roy asked me what I liked for quadric definitions. I worked on this question professionally a few years back, and thought I'd pass on what I found. I like for a sphere: radius, origin, axis for north pole, axis for start point on equator (and optionally right or left-handedness) The axes are important when you're applying a texture to a surface (otherwise can be ignored). Of course, the user doesn't have to see it this way. For defining ellipsoids, no one bothers with defining the foci - you simply need to non-uniformly scale (e.g. stretch) a sphere with a transformation matrix. You have to be sure to stretch the normal equation for the sphere by the transpose of the adjoint of this matrix to get the normals right (see An Intro to Ray Tracing in Pat Hanrahan's section for a little more on this, and see old issues of this newsletter). I like for cylinders/cones/annuli (i.e. "washers"): base origin, axis vector, base radius, apex radius, height, axis for starting texture point on equator This is real general and gives you three different primitives all in one. In the code you will probably want separate intersectors for them, though (i.e. height of 0.0 means it's a washer and the cone equation will tend to explode at this height). ------------------------------------------------------------------------------- Ray Tracing Roundup Watt & Watt's book, _Advanced Rendering and Animation Techniques: Theory and Practice_, is a good unified guide to advanced rendering in general and I highly recommend it. Think of it as a condensed and simplified "Best of SIGGRAPH" for the past decade and you won't be too far wrong. (Eric Haines) -------- The 3rd edition of the cross-indexed bibliography on ray-tracing and related topics is available. Included in this edition will be some 600 citations, papers from all the major graphics conferences and full keywording of citations. Cross-reference files (by keyword and author) and a glossary of the 120 keywords used are also slated for inclusion. (Rick Speer, speer@cs.colorado.edu) -------- Texture Library Site The beginning of a texture library for rendering applications is being started on wuarchive.wustl.edu located in the mirrors/architec directory. Please FTP the README file first. There are around 100 texture images stored in compressed TIFF format. (Paul David Bourke, pdbourke@ccu1.aukuni.ac.nz) [I looked at the initial 40 of these. Good idea, but only a very few of them were tileable (i.e. could be repeated seamlessly over a surface). -EAH] -------- Inventor 3D File Format, by Gavin Bell (gavin@sgi.com) You can do a great service to everybody if you avoid creating yet another 3D object file format and at least adopt Inventor's ASCII file format for your system. If not the objects, at least the syntax, to make translation easy. Documentation on the file format is free-- you can anonymously ftp it from sgi.com:sgi/inventor/Doc.tar.Z. -------- Ray Traced Church Interiors There is a series of five images of the interior of the Renaissance church "Il Redentore" in Venice. The original (huge) Utah RLE images are available from: cad0.arch.unsw.edu.au:/pub/rayshade/images/Il_Redentore The images were produced using Rayshade, the images and the model were created by Nathan O'Brien as part of his undergraduate dissertation "Building Preservation and Three Dimensional Computer Modelling" at UNSW. These images are extremely good IMHO, and well worth the effort of getting! (Stephen Peter, steve@keystone.arch.unsw.edu.au) ---- You may ftp jpeg versions of them (perhaps for a limited time only) from: services.more.net 128.206.20.15 (Columbia, Missouri, USA) in /pub/jpg/Il_Redentore. These are not the jpegs which appeared on alt.binaries.whatever but were jpegs recreated from the original .rle files by me. (David Drum, UC512052@mizzou1.missouri.edu) -------- My book is coming out in October and is called "Adventures in Raytracing," published by QUE. It covers Polyray from "top to bottom". The book is dedicated to raytracing (with Polyray), 3d modeling (with POVCAD - my program) and animation. The book has an almost complete reference on Polyray and it even includes a tear-out card with the command lines, language syntax, etc. It includes a disk with Polyray 386 (no 387) and 386/486 (+387) version, POVCAD (windows and Dos version) and CompuShow (image file viewer utility). Right now I've also written a small utility called CLAY.ZIP which does free form deformation on RAW data files. The output comes out as RAW also. In addition I've written another utility to tween 2 RAW data files in Polyray - the good thing about it is that it can do linear, quadratic or cubic interpolation... and the output from the utility is just 1 file independently of how many frames are required. (Alfonso Hermida, afanh@stdvax.gsfc.nasa.gov) -------- I've just completed a book on 3D graphics animation with Dave Mason called "Making Movies on Your PC". Lots of pretty pictures, mostly beginners tips on creating FLI/FLC format animations on IBM clones. (Alexander Enzmann, 70323.2461@compuserve.com) [This book also includes Polyray and 2D morphing software. -EAH] -------- YART 0.40 - a Fast Growing Framework for Obj.Or.Graphics, Ekkehard Beier (ekki@prakinf.tu-ilmenau.de) The time is good for a new graphics system, including both ray-tracing and gouraud shading facilities! This system should be object-oriented, highly extensible and highly interactive (Real-time raytracing or real-time shading and raytracing if explicitly wanted). Using SGI GL/PHIGS[PEX]...-shading for built-in modelling and direct interaction, and Raytracer for HiQuality final images. * YART - Yet Another Ray Tracer * is a first implementation of such a system. *there is a mailing list: yart@prakinf.tu-ilmenau.de *PLATFORMS: SGI Iris, SUN Sparc, Linux-PC, [MS Windows - in work] ftp from metallica.prakinf.tu-ilmenau.de [141.24.12.29] : pub/PROJECTS (login as "ftp", password "HARLEY FUCKIN' DAVIDSON"). *PRECONDITIONS: C++ (At&T cfront 2.1), Tcl, GL or X11 or PHIGS PLUS. [There's lots more text, contact the author for more info. -EAH] -------- General software: 3DS2POV is a utility that converts 3D Studio files to POV-Ray, Vivid, Polyray, or raw triangle formats. A bounding volume hierarchy is added to the POV-Ray files. The latest version converts from the binary .3DS format where previous versions used the ascii format. If you've got the time (or a Cray) it'll convert whole animation sequences as well. This program is on the YCCMR BBS and the TGA BBS as 3DSPOV17.ZIP. Both DOS binaries and C source are included. (Steve Anger, 70714.3113@CompuServe.COM) -------- [I haven't mentioned BRLCAD for awhile, so here's a blurb:] The US Army BRLCAD package (brl@cad.mil) -- Ballistic Research Laboratory is available as encrypted source code via anonymous ftp from: ftp.brl.mil:/brl-cad/* FAX a completed copy of the 'agreement' file to BRL for the 'crypt' key. BRLCAD is very mature -- also runs in parallel on a heterogeneous mixture of systems -- image quality is good -- but perhaps not extraordinary. (Alexander-James Annala) [It really does look like an amazing system, worth checking out if you plan on doing any "serious" modeling, esp. CAD related. - EAH] -------- Radiance related: A fellow by the name of Georg Mischler of ETH in Zurich, Switzerland, has written a new translator for exporting Radiance files from within AutoCAD. This new AutoLISP program seems to be quite capable, and he has installed it in the pub/translators directory on the anonymous ftp account of hobbes.lbl.gov (128.3.12.38). I invite users with AutoCAD to try it out. (Gregory J. Ward, greg@hobbes.lbl.gov) -------- Rayshade related: I have just compiled the 'Enhanced' version of Rayshade (patchlevel 6) for a PC running MSDOS and it appears work fine. You can get it from telva.ccu.uniovi.es (156.35.31.31): /pub/graphics/raytrace/rayshade/MSDOS/Erayshade.for.PC.zip. You'll need a 486 ( yeah, you'll can run it on a 386, but S...L...O...W ). Also I packed a shower and a converter from/to the RLE file format. (Raul y Quique, nuevos%hp400.ccu.uniovi.es@Princeton.EDU) ---- I am placing in weedeater.math.yale.edu:/incoming 3 executables: getX11, rayshade.4.0.6, raypaint.4.0.6 which have been ported to SCO UNIX & Univel SVR. They will run in both environments. These have been optimized for INTEL 486 & Pentium processors to use on-chip FPU & cache memory. (Robert Walsh, SCO ) ---- I have just uploaded a port of rayshade 4.0.6enh2 to OS/2 2.1 to weedeater.math.yale.edu. Most of the patches posted through July 20, 1993 to this list have been added. (David C. Browne, DBROWNE@diamond.kbsi.com) ---- Check out the June issue of Omni Magazine, page 52. The "computer-generated image of HIV created on a Cray Super Computer" was done with Rayshade. It really looks much larger in person :-):-). A larger version of this image may be found on: fconvx.ncifcrf.gov in tmp/rayshade as virion.rle.Z. For more info you can contact me at mcgregor@ncifcrf.gov or Connor McGrath at mcgrath@ncifcrf.gov. (Please see the acknowledgment.txt file for a few more details). -------- RTrace/Radiosity related: The "lightR" radiosity program from Bernard Kwok (ae140@freenet.carleton.ca) is now available to run in a PC with DOS DJGPP GO32 extender. You can ftp a working version with some scenes and utils at asterix.inescn.pt [192.35.246.17] in directory pub/LightR/PC-386 (lightr12.arj) The source code is in pub/LightR/PC-386/src (lightr.arj) I found the program very interesting and it helped me to learn a lot about Radiosity (a rendering algorithm). I have also adapted its output to the RTrace ray tracer so that nice images could be produced: lightr scn2sff rtrace PAT, VW ----------> SCN ----------> SFF ----------> PIC PPM I included minimal docs and specs, but I intend to improve this area in the future... Please feel free to contact me. (Antonio Costa, acc@asterix.inescn.pt) ---- There is a new version of the RTrace ray-tracing package (8.3.2) at asterix.inescn.pt [192.35.246.17] in directory pub/RTrace. Check the README file. RTrace now can use the SUIT toolkit to have a nice user interface. Compile it with -DSUIT or modify the Makefile. SUIT is available at suit@uvacs.cs.virginia.edu ---- I have put in pub/RTrace here 2 PostScript docs describing the syntax of both SFF and SCN. I would many people to read them and send me comments, if possible... The files are sffv8-p?.ps.Z and scn15-p?.ps.Z (Antonio Costa, acc@asterix.inescn.pt) [There are undoubtedly a large number of other changes and additions to RTrace by this time; Antonio seems to have unlimited time and energy for this thing! For example, I noticed he now has an IRIS Inventor input interpreter. Check with him for the latest. -EAH] -------- Vivid/Bob related: Triangular Glob Generator v1.0 copyright 1993, Dov Sherman (For use with Stephen Coy's Vivid Raytracer v1.0 or higher) GLOB is a handy utility for creating more realistic, rounded objects without relying on bezier patches (which are still good but hard to work out on paper). GLOB takes an ASCii file containing the coordinates and radii of a series of spheres and creates smooth connections between each sequential pair, connecting the first and third spheres in each sequential triple, and placing a triangular polygon over the gap created by a sequential triple. I'll try to explain this better later. The output is in the form of an include file for Stephen Coy's Vivid Raytracer. Other raytracer formats may be supported in future versions if I ever manage to figure out the other ones. GLOB10.ZIP is available from wuarchive.wustl.edu. I just put it in /pub/MSDOS_UPLOADS/graphics. Also available on the You Can Call Me Ray BBS. (Dov Sherman, DS5877@CONRAD.APPSTATE.EDU) -------- POV related: Ray Tracing Creations Drew Wells, Chris Young, Dan Farmer The Waite Group 1993 ISBN 1-878739-27-1 This book covers the POV ray tracer from soup to nuts, with lots of examples and whatnot. Essentially, it's a users manual for POV, and it comes with POV 1.0 on disk. (Eric Haines) ---- There's a new GUI modeller call MORAY out for POV-Ray. This is the most complete modeller for POV-Ray I've seen so far. It supports most of POV-Ray's primitives, CSG, hierarchical linking, and has an nice bezier patch editor. Here's a short description from the docs: MORAY V1.3 is an easy-to-use GUI modeller for use with POV-Ray 1.0 (and 2.0 when released). It supports the cube, sphere, cylinder, torus, cone, heightfield and bezier patch primitive, as well as adding conic, rotational and translational sweeps. You can add (spot)lights, bounding boxes, textures and cameras, which show the scene in wireframe 3D. Shareware US$59. Not crippled. Requires 286 or higher, mouse, runs on VGA and SVGA/VESA. MORAY version 1.3 is available at ftp.informatik.uni-oldenburg.de in /pub/dkbtrace/incoming. (Steve Anger, 70714.3113@CompuServe.COM) ---- No, POV 2.0 is not out yet. To whet your appetite: POV 2.0 includes automatic bounding boxes, better textures, recursive antialiasing, primitives for finite cylinders & cones. The parser will now accept mathematical expressions for vectors and floating point numbers. It also has some bugfixes. ---- When using PoV on a X window based Unix system as f.i. Linux, you may use my x256q Previewer code instead of the xwindows code that comes with PoV. It resides on irz301.inf.tu-dresden.de:pub/gfx/ray/misc/x256q (Andre Beck, beck@irzr17.inf.tu-dresden.de) ---- Check out the 3d l-system generator (ms-dos) for POV-Ray raytracer I found on the graphics alternative bbs 510-524-2780. the qbasic source makes a raw coordinate file for input to raw2pov for smooth_triangle output. 3 examples from 'algorithmic beauty of plants' provides about 8 variables that one can fuss with to produce diff shape trees/bushes. uploaded as treebas.zip to ftp.informatik.uni-oldenburg.de:pub/dkbtrace/incoming/ (mirrored on wuarchive.wustl.edu:graphics/graphics/mirrors/ftp.infor...) (Tony Audas, taudas@umcc.umcc.umich.edu) ---- I use POVRAY and the small Makeanim program to do animation - using makeanim you create a file with a series of movement variables - and it #defines them into the .pov code and raytraces them all in sequence. So if you want a camera pan diagonally upward, your .anm file should look like: pan_x, pan_y 0, 0 1, 1 2, 2 etc... It will define these for you, and they should be used instead of x and y in your camera definition. Makanim will only handle 20 variables, unfortunately, so you can really only make 20 or less things move - but if you move the camera around, this can make up for things. (Dane Jasper, dane@nermal.santarosa.edu) ---- RAW2POV is a utility that converts triangle data listed in xyz triplets to POV-Ray smooth triangles. It automatically adds its own bounding volume hierarchy to overcome POV-Ray's lack of an efficiency scheme. This program is on the YCCMR BBS and the TGA BBS as RAWPOV17.ZIP. Both DOS binaries and C source are included. [Also see 3DSPOV writeup above] (Steve Anger, 70714.3113@CompuServe.COM) ---- If you have any comments or suggestions about POVCAD please let me know. The home of POVCAD is Pi Square BBS (301)725-9080 in Maryland USA. You may download POVCAD (DOS or Windows version) and get the latest info on it. [POVCAD is up to version 2.0b for Windows by now, and has more features than the non-Windows version); there are also rumors that an X-Windows version may be forthcoming. -EAH] (Alfonso Hermida, afanh@stdvax.gsfc.nasa.gov) ---- A lot of developers (A. Hermida, Lutz Kretschmar, Dan Farmer, Stephen Coy) also hang out the PCG (Professional CAD Graphics Net). You can get access to this net via the BBS'es mentioned in the PoV docs, and in Europe via BBS Bennekom, fido node 2:281/283, telephone 31-8389-15331. Using Bluewave, I can read and write in the echos for free. (Han-Wen Nienhuys, hanwen@STACK.URC.TUE.NL) ---- In the PC world, I have use a program called VVFONT. It uses the stroke fonts in borland and produces the characters as unions of spheres, codes, planes, boxes, cylinders, etc. It produces very good results and allows for rounded, block, and beveled format for POV, DKB, and Vivid ray tracers. If I don't see it on the net, I will check with the author and download it somewhere and post the location if there is any interest shown. (Mike Hoyes, hoyes@rock.concert.net) ---- I've uploaded my (uppercase only) alphabet to ftp.informatik.uni-oldenburg.de:pub/dkbtrace/incoming (or some such place... you know the one I mean). The letters consists of cylinders and torii, suitably bounded for performance reasons. There is also a utility for writing strings, and two sample .pov files. Oh yes, almost forgot. The file is called 'beta.zip' (as there is already an alpha.zip... Imaginative, huh?) (Reidar "Radar" Husmo, radar@cs.keele.ac.uk) ---- There are a few other ways to render text. Look in ftp.informatik.uni-oldenburg.de: pub/dkbtrace, there are two alphabet pov files, alpha.zip and beta.zip, examples of using pov shape_types in creating 3D text. Another way I can think of is to use the connect-the-dots utility to create letters. Further possibilities include using Vision 3D's extruder to extrude the text and output DXF, then convert to pov triangles. A third method I think may work is to use Paul Bourke's "BitSurface" utility which converts bit-maps to DXF, and again convert to pov. (Helmut Dotzlaw, dotzlaw@CCU.UMANITOBA.CA) ---- I produce fonts for PoV commercially [see RTNv6n2 for more info. -EAH]. For a demo, and some sample letters, have a look in ftp.informatik.uni-oldenburg.de pub/dkbtrace/incoming or pub/dkbtrace/utils for some of these: avantest.zip 38988 21/10/92 5:14 fntbench.zip 33628 21/02/93 17:25 fntsamp.zip 132164 23/07/93 5:58 tms_rom.jpg 27560 21/02/93 17:28 Kirk2.jpg illustrates the use of the fonts in a more professional capacity. (Andrew Haveland-Robinson, andy@OSEA.DEMON.CO.UK) ---- One of the best utilties I've found for POV is called SP - Dave's Spline- Path Generator. You can find this on the You Can Call Me Ray BBS. Basically, you make a data file of a number of points and some other information, and SP will calculate position and rotations for your camera. You can do acceleration/deceleration, etc... with it as well. Its downfall (at least as of version 0.3) is that it only does one frame at a time (you tell it which of the N frames to compute). It's relatively easy to make a batch file for this, though. (Jason Barile, barilejb@ctrvax.vanderbilt.edu) ---- A good many of the utilities for POV-Ray have been designed to use what we call ".raw" format (bare vertex data) which can be bound very tightly in a hierarchical structure of bounding boxes by a utility by Steve Anger, called RAW2POV. RAW2POV can also do Phong interpolation on the triangles if desired. Any serious raytracing of large triangle databases in POV 1.0 is done with data that has been processed by RAW2POV. (Nobody tries it twice without it!) (Dan Farmer CIS[70703,1632]) ---- POV on Mac utilities: Thanks to "The Evil Tofu", I was recently made aware of a collection of utilites for POV which have been ported to the Mac by Eduard [esp] Shwan, of the Compuserve Group, called POV Mac Utilities 1.1. With kind permission of the author, it has been uploaded to the Internet. The application contains the following utilities: Coil Generator - Bill Kirby Connect the Dots (CDTS) - Truman Brown Dat2POV - Drew Wells DXF2POV - Aaron A. Collins "Lissa" Lissajous Generator - Eduard [esp] Schwan POV Suds Generator - Sam Hobbs & Dan Farmer Raw2POV - Steve Anger Shell Generator - Dan Farmer Sponge Generator - Stephen Coy Swoop - Douglas Otwell Also I think worthy of mention is that Paul D. Bourke's Vision-3D modeller for the Mac, which can export DXF files, supports lathing and extruding capabilities. Hmm, I wonder if I lathed something and used Mac POV Utils to generate a DXF -> POV? Paul has also recently written a program, BitSurface, which will generate DXF from bitmap files. Hmm, again.... Mac POV Utils 1.1 can be found at summex-aim.stanford.edu, /info-mac/grf/util/pov-utilities-11.hqx Freeware. Vision-3D and BitSurface can be found at wuarchive.wustl.edu, /mirrors/architec Shareware. (Helmut Dotzlaw, dotzlaw@CCU.UMANITOBA.CA) ---- > Does anyone have a leaf generator ? a tree generator ? flowers ? Look at treebas (tree generator in qbasic (msdos)) > Is there a technique for getting that rainbow effect that you see on a > Compact Disc ? Look at the texture in bubble.pov (an iridescent, shimmering rainbow smear). Both are available by anonymous ftp in ftp.informatik.uni-oldenburg.de:pub/dkbtrace/incoming mirrored on wuarchive.wustl.edu:graphics/graphics/mirrors/ftp.infor... (Tony Audas, taudas@UMCC.UMICH.EDU) -------- Xmgf 1.1 Motif based 3D Object Viewer xmgf can be found on export.lcs.mit.edu in /contrib files: xmgf.README xmgf.1.1.tar.Z You'll need MOTIF and patience (:-)) Have fun and feedback will be welcomed (good and bad!:-( (Paul Hoad, P.Hoad@ee.surrey.ac.uk) -------- SIGGRAPH May issue on-line By popular demand, we have created a tar'ed and compress'ed version of the May '93 experimental online edition of the SIGGRAPH "Computer Graphics" newsletter. It is in file ~ftp/publications/May_93_online/May_93_online.tar.Z available via anonymous ftp from siggraph.org. This file contains the PostScript version of the newsletter. It is 3.2MB in size compressed and uncompresses to 15MB. (Sue Mair, mair@ucs.ubc.ca) -------- A friend of mine Jason Wilson created a very basic radiosity package. This package runs on the Next Platform(version 3.0 or higher). ftp.cs.rose-hulman.edu under pub/CS_dept file NeXtrad.tar.Z (Leslie Donaldson, Donaldlf@cs.rose-hulman.edu) -------- MacCubeView 1.0.0 A 3D image display programme for the Macintosh is now available via anonymous ftp from from ftp://ftp.hawaii.edu/mirrors/info-mac/sci/mac-cube-view-16.hqx. This programme is suitable for viewing 3D eight bit medical images. A 3D MR image of the author's head is included. (Daniel W. Rickey, physics@escape.ca) -------- Some weeks ago we sent a public message with the press-release of Real-Light 1.0, a radiosity based rendering package. People interested in watching some RGB image of environments created by Real-Light can take them by anonymous ftp at: ftp.iunet.it (192.106.1.6) in the directory: ~ftp/vendor/Atma (Cristiano Palazzini, atma@relay1.iunet.it) -------- There is an interesting 3D Space Shuttle model database in .dxf (AutoCad), .nff (neutral file format for Sense8) and .vid (amiga VideoScape) ftp anonymous: artemis.arc.nasa.gov (128.102.115.149) in /sig-wtk/models directory (Emerico Natonek, natonek@imtsg5.epfl.ch) -------- |> Is there any public domain code out there for generating polygonal models |> of human faces given a small set of parameters? There are some things available by anonymous ftp to wuarchive.wustl.edu, under graphics/graphics/misc/facial-animation. (James R. (Jim Bob) Bill, jimbob@rainier.ucsc.edu) -------- Thanx to Juhana the PostScript version of my thesis can be obtained from: nic.funet.fi:pub/sci/papers/graphics/suma93.tar.gz (1115072 bytes) He promises that it will be made available from: princeton.edu:pub/Graphics/Papers/suma93.tar.gz The file is GNU zip compressed. (He says GNU zip gives him better compression.) So `gunzip' has to be used for uncompression. (Sumanta N. Pattanaik, sumant@saathi.ncst.ernet.in) %A Sumanta N. Pattanaik %T Computational Methods for Global Illumination and Visualisation of Complex 3D Environments %R PhD thesis %I Birla Institute of Technology & Science, Computer Science Department, Pilani, India %D November 1990 %K adjoint illumination equations, particle model of light, random walk, importance sampling -------- Given the number of modelers coming out for ray tracers (IRIT 4.0 should be out soon, by the way), I thought I should give a plug to Ken Shoemake's wonderful ArcBall technique for interactive rotations of objects. The original paper is: AUTHOR = "Ken Shoemake", TITLE = "ARCBALL: A User Interface for Specifying Three-Dimensional Orientation Using a Mouse", PROCEEDINGS = Graphics Interface '92, YEAR = 1992, PAGES = pp151 It's a very intuitive, easy to implement technique which can be used for unconstrained or constrained rotations. I needed one hint to understand the full functionality of the technique; other than that, it was obvious to use. The short paper (available on the net for the Mac, see below) explains it all. (Eric Haines) ---- An example written for the Mac by Shoemake is available on linc.cis.upenn.edu in the directory /pub/graphics/arcball. The file arcball is the example, while the arcball-paper is the GI paper. Note: to decode the files, you need to use BinHex 4.0. BinHex 5.0 will not work for these files, unless you are willing to edit off the heading portion of them. (Duanfeng He (Jackson), Duanfeng.He@AtlantaGa.NCR.com) ---- I have a version of Shoemake's ArcBall I wrote and I'm making it available. You'll have to do some work, however, as it uses my graphics library. You have to know enough about programming in your own 3d library to be able to convert some types and routines, although it will be _really_ simple ... a matter of finding equivalents for types such as vectors and matrices, and using your own draw routines. If you use something like GL, it will be trivial, as that's what my graphics library is based on. It's available on cs.columbia.edu:pub/bm/arcball That said, I'd like to thank Ken for his excellent paper. The ARCBALL concept aside, the arc drawing routines are pretty darn cool. :-) (Blair MacIntyre, bm@shadow.columbia.edu) -------- Hidden surface renderer (well, it's not really ray tracing related, but I'm not a purist): >I'm after a Gourand Z-buffer polygon scanline example. The one in >Gems I (PolyScan) looks pretty good but as poly_scan.c is dated >1985 and 1989, I was wondering if any improvements or optimizations >have been made (or bug fixes). I haven't used the code as it is >but am looking around before writing my own redering library. You may want to grab libXG-2.0.tar.Z from ftp.ai.mit.edu down (pub/users/sundar). It has examples of sutherland-hodgman clipping, z-buffer scanline code etc. The doc directory contains a postscript manual which documents all the functions. (This is a 3-d graphics library that runs under X). It doesn't aim to be super-fast, but it does handle multiple-polygons with loops (or holes), inter-penetrating polygons, polygons with cyclical overlap etc. (Sundar Narasimhan, sundar@ai.mit.edu) -------- Least impressive ray tracer dept: A recent issue of RS/Magazine has an article on using the IBM RS/6000 for mechanical CAD and they found it worthwhile to include a picture of an RX/6000 displaying a ray traced picture of a first level sphereflake. They liked it so much they used it three times! But, since it's only first level (a big sphere surrounded by several spheres just a bit smaller) it doesn't exactly cry out that the RS/6000 is a power cruncher, does it. (Tim O'Connor) ------------------------------------------------------------------------------- Simple Sphere Tessellation, by Mike Castle (mcastle@cs.umr.edu) How sphere.c works (at wustl and other places): Start off with 6 points on a unit sphere (1,0,0), (-1,0,0), (0,1,0), (0,-1,0), (0,0,1), (0,0,-1). These form a octahedron. Each of the 8 triangles is taken one at a time. Take one triangle, and choose its midpoint (by averaging the coordinates of the three points). Normalize that point, so it's now projected back onto the unit sphere. Replace the original triangle with 3 triangles, based on the original 3 points, and the new 4th point. Recurse. (the level of recursion is user specified). Voila, tessellated sphere. ------------------------------------------------------------------------------- Syndesis CD-ROM Review, by Eric Haines This is the CD-ROM mentioned last issue. It contains more than 600 models and more than 400 textures, and costs $200. I received a review copy during SIGGRAPH, and it's an interesting collection. The collection was made as a way of publicizing Syndesis' InterChange Plus software, which converts 3D model data in various formats. Though it's ISO-9660 and all that, I still had problems reading it on the Gateway CDROM drive next to me. I don't know where the problem lay, but our systems administrator said such problems are fairly common. I was able to read the CDROM on other drives just fine. There are, of course, a ton of files on the disk. There should also be more disks in the future, and Mr. Foust has a policy in which contributors whose creations are accepted get a free disk; contact him for more information. In fact, if you can identify yourself as the author of any of the works on this first disk, you can get a free disk (a bit of a "key locked in the treasure chest" situation, admittedly, since you pretty much need the disk to see if your creation is on it). The book that comes with the disk is quite useful, as it has thumbnail grayscale images of some of the textures and some of the models included on the disk. Unfortunately, not all of them are shown; only about 160 of the 600 models are displayed, and the synthesized textures are not shown. However, the models are all listed with descriptive titles, and there is also an index which can be pretty helpful. On the disk there are summary images of the textures available, showing thumbnail sketches of all textures available. The models come in 3D Studio, Autocad DXF, Imagine IOB, Wavefront OBJ, and Lightwave formats. (I should note that it's pretty easy to convert from IOB to many formats by using the converter at wuarchive.wustl.edu in /graphics/graphics/objects/TDDD). The models vary in quality, of course, but the disk is not a collection of every free model ever made; while limited to what was out there for free, there are few trivial or poorly modeled objects. The scope is quite amazing, and Syndesis has done quite a job in making this collection. On the disk there are some interesting models from Viewpoint which were supposed to be in their SIGGRAPH '93 free distribution, but in fact were not distributed there (they distributed a bunch of beach related models instead): a car, Big Ben, a deer head, elbow bones, and various military hardware. The textures are all tileable and in TIFF/GIF/IFF formats. It's a little annoying that the tiff images do not have the standard "*.tif" suffix. The textures overall are usable, but nothing fantastic. The synthetic textures (some 262 of these) are 256x256 and some are pretty interesting, but they tend to have the same feel to them. The other textures (about 150 of these, described below) are fairly low resolution, 128x128 at very best. Some of these are tileable simply by doing mirroring along the x and y axes. All in all, some cute stuff, but don't expect a professional quality tileable wood or marble here. In addition, in a demos directory there are a bunch of stills and FLI animations for the various companies whose work is on the disk. There is also a text area with an archive of the Imagine and Lightwave electronic mailing lists - literally megabytes of advice here. All in all, this is a great resource for amateurs and professionals who make 3D images. Some of the models are incredible, and the textures, while not particularly fantastic in and of themselves, I consider pure icing. There's a lot to explore here. Considering that a single model from Viewpoint can cost much more than this entire disk, if you're a professional and use even just a few models from this CDROM you're ahead of the game. ---- John Foust notes: About 135 of the textures were captured and massaged from hand-made, public domain Macintosh desktop textures - PPAT resources, they call them. The others were generated by a super Mac program called Texture Synth, which uses a few basic seed textures, recombined with color and multiple sine-wave textures. They look very nice, a little synthetic at times, but in an organic-synthetic sort of way... Contact: John Foust / Syndesis Corporation <76004.1763@CompuServe.COM> ------------------------------------------------------------------------------- Ray Tracing Related Abstracts from the Proceedings of Graphics Interface '93 (May 19-21, 1993, Toronto, Ont. CA). These proceedings are available from Morgan Kaufmann Publishers, 415-965-4081. ISBN 0-9695338-2-9 %A Alain Fournier %A Pierre Poulin %T A Ray Tracing Accelerator Based on a Hierarchy of 1D Sorted Lists %A Jon Genetti %A Dan Gordon %T Ray Tracing With Adaptive Supersampling in Object Space %A David P. Dobkin %A Don P. Mitchell %T Random-Edge Discrepancy of Supersampling Patterns ------------------------------------------------------------------------------- Ray Tracing Papers in the First Bilkent Computer Graphics Conference, ATARV-93, Ankara, Turkey, July 1993 "A Parallel Implementation of a Ray Tracer on a Shared Memory Multiprocessor" E. Camahort, G. Quintana, R. Vivo, and A. M. Vidal, Departamento de Sistemas Informaticos y Computacion, Universidad Politecnica de Valencia, SPAIN. "An Efficient Parallel Spatial Subdivision Algorithm for Parallel Ray Tracing Complex Scenes" V. Isler, C. Aykanat, and B. Ozguc, Dept. of Computer Eng. and Information Science, Bilkent University, TURKEY. "Modelling Rodin's Thinker: A Case Study Combining PHIGS and Ray-tracing" G. Williams, A. Murta, and T. Howard, Dept. of Computer Science, University of Manchester, U.K. "A File Format for Interchange of Realistic Scene Descriptions" P. Guitton and C. Schlick, LaBRI, Talence, FRANCE. ------------------------------------------------------------------------------- Fourth Eurographics Workshop on Rendering, Paris, France June 14-16, by Francois Sillion (sillion@dmi.ens.fr) [There may be some proceedings left for sale, contact Francois for information] The program included 24 contributed papers on a variety of topics and three invited presentations. Dynamic Stratification Andrew Glassner Progressive Ray Refinement for Monte Carlo Radiosity Martin Feda, Werner Purgathofer Invited: Realism in real-time ? Erik Jansen Making Shaders More Physically Plausible Robert Lewis Illumination of Dense Foliage Models Christopher Patmore A Customizable Reflectance Model for Everyday Rendering Christophe Schlick Importance and Discrete Three Point Transport Larry Aupperle, Pat Hanrahan A Continuous Adjoint Formulation for Radiance Transport Per Christensen, David Salesin, Tony DeRose Wavelet Projections for Radiosity Peter Schroeder, Steven Gortler, Michael Cohen, Pat Hanrahan Continuous Algorithms for Visibility: The Space Searching Approach Jenny Zhao, David Dobkin Invited paper : Viewpoint Analysis of Drawings and Paintings Rendered Using Multiple Viewpoints: Cases Containing Rectangular Objects Yoshihisa Shinagawa, Saeko Miyoshi, Tosiyasu Kunii Constant-Time Filtering by Singular Value Decomposition Craig Gotsman Measuring the Quality of Antialiased Line Drawing Algorithms Terence Lindgren, John Weber Invited: "How to solve it ?" Pat Hanrahan Numerical Integration for Radiosity in the presence of Singularities Peter Schroeder Optimal Hemicube Sampling Nelson Max, Roy Troutman Fast Calculation of Accurate Form Factors Georg Pietrek Grouping of Patches in Progressive Radiosity Arjan Kok Blockwise Refinement -- A New Method for Solving the Radiosity Problem Gunther Greiner, Wolfgang Heidrich, Philipp Slusallek Analysis and Acceleration of Progressive Refinement Radiosity Method Min-Zhi Shao, Norman Badler Texture Mapping as a fundamental Drawing Primitive Paul Haeberli, Mark Segal A Methodology for Description of Texturing Methods Pascal Guitton, Christophe Schlick Visualization of Mixed Scenes based on Volumes and Surfaces Dani Tost, Anna Puig, Isabel Navazo Physically Realistic Volume Visualization for Interactive Image Analysis H.T.M.Van der Voort, H.J. Noordmans, J.M. Messerli, A.W.M. Smeulders Reconstruction of Illumination functions using Bicubic Hermite Interpolation Rui Manuel Bastos, Antonio Augusto de Sousa, Fernando Nunes Ferreira Mesh Redistribution in Radiosity Miguel P.N. Aguas, Stefan Muller Accurate Rendering of Curved Shadows and Interreflections G.R. Jones, C.G. Christou, B.G. Cumming, A.J. Parker ------------------------------------------------------------------------------- Gamma Correction Frequently Asked Questions, by Graeme Gill (graeme@labtam.labtam.oz.au) I get regular questions about gamma correction since I go to great pains to deal with it properly in xli (the image loader program I maintain). Here is an explanation I often use to answer these questions. ######## "A note on gamma correction and images" Author: Graeme W. Gill graeme@labtam.oz.au Date: 93/5/16 "What is all this gamma stuff anyway?" -------------------------------------- Although it would be nice to think that "an image is an image", there are a lot of complications. Not only are there a whole bunch of different image formats (gif, jpeg, tiff etc etc), there is a whole lot of other technical stuff that makes dealing with images a bit complicated. Gamma is one of those things. If you've ever downloaded images from BBS or the net, you've probably noticed (with most image viewing programs) that some images look ok, some look too dark, and some look too light. "Why is this?" you may ask. This, is gamma correction (or the lack of it). Why do we need gamma correction at all? --------------------------------------- Gamma correction is needed because of the nature of CRTs (cathode ray tubes - the monitors usually used for viewing images). If you have some sort of real live scene and turn it into a computer image by measuring the amount of light coming from each point of the scene, then you have created a "linear" or un-gamma-corrected image. This is a good thing in many ways because you can manipulate the image as if the values in the image file were light (i.e. adding and multiplying will work just like real light in the real world). Now if you take the image file and turn each pixel value into a voltage and feed it into a CRT, you find that the CRT _doesn't_ give you an amount of light proportional to the voltage. The amount of light coming from the phosphor in the screen depends on the the voltage something like this: Light_out = voltage ^ crt_gamma So if you just dump your nice linear image out to a CRT, the image will look much too dark. To fix this up you have to "gamma correct" the image first. You need to do the opposite of what the CRT will do to the image, so that things cancel out, and you get what you want. So you have to do this to your image: gamma_corrected_image = image ^ (1/crt_gamma) For most CRTs, the crt_gamma is somewhere between 1.0 and 3.0. If that is all it is, why does it seem so complicated? ------------------------------------------------------ The problem is that not all display programs do gamma correction. Also not all sources of images give you linear images (Video cameras or video signals in general). Because of this, a lot of images already have some gamma correction done to them, and you are rarely sure how much. If you try and display one of those images with a program that does gamma correction for you, the image gets corrected twice and looks way to light. If you display one of those images with a program that doesn't do gamma correction, then it will look vaguely right, but not perfect, because the gamma correction is not exactly right for you particular CRT. Whose fault is all this? ------------------------ It is really three things. One is all those display programs out there that don't do gamma correction properly. Another is that most image formats don't specify a standard gamma, or don't have some way or recording what their gamma correction is. The third thing is that not many people understand what gamma correction is all about, and create a lot of images with varying gamma's. At least two file formats do the right thing. The Utah Graphics Toolkit .rle format has a semi-standard way of recording the gamma of an image. The JFIF file standard (that uses JPEG compression) specifies that the image to be encoded must have a gamma of 1.0 (i.e. a linear image - but not everyone obeys the rules). Some image loaders (for instance xli - an X11 image utility) allow you to specify not only the gamma of the monitor you are using, but the individual gamma values of image you are trying to view. Other image viewers (e.g. xv, another X11 image program) and utilities (e.g. the pbm toolkit) provide ways of changing the gamma of an image, but you have to figure out the overall gamma correction yourself, allowing for undoing any gamma correction the image has, and then the gamma correction you need to suite your CRT monitor. [Note that xv 2.21 doesn't provide an easy way of modifying the gamma of an image. You need to adjust the R, G and B curves to the appropriate gamma in the ColEdit controls. Altering the Intensity in the HSV controls doesn't do the right thing, as it fails to take account of the effect gamma has on H and S. This tends to give a tint to the image.] How can I figure out what my viewer does, or what gamma my screen has? ---------------------------------------------------------------------- The simplest way to do that is to try loading the file chkgamma.jpg (provided with xli distribution), which is a JFIF jpeg format file containing two grayscale ramps. The ramps are chosen to look linear to the human eye, one using continuous tones, and the other using dithering. If your viewer does the right thing and gamma corrects images, then the two ramps should look symmetrical, and the point at which they look equally bright should be almost exactly half way from the top to the bottom. (To find this point it helps if you move away a little from the screen, and de-focus your eyes a bit.) If your viewer doesn't do gamma correction, then left hand ramp will have a long dark part and a short white part, and the point of equal brightness will be above the center. If your viewer does have a way of setting the right amount of gamma correction for a display, then if the equal brightness point is above center increase the gamma, and decrease it if it is below the center. The value will usually be around 2.2. [with xli for instance, you can adjust the display gamma with the -dispgamma flag, and once you've got it right, you can set the DISPLAY_GAMMA environment variable in your .profile] How do I figure out what the gamma of an image is? -------------------------------------------------- This is the most tricky bit. As a general rule it seems that a lot of true color (i.e. 24 bit, .ppm .jpg) images have a gamma of 1.0 (linear), although there are many about that have some gamma correction. It seems that the majority of pseudo color images (i.e. 8 bit images with color maps - .gif etc.) are gamma corrected to some degree or other. If your viewer does gamma correction then linear images will look good, and gamma corrected images will look too light. If your viewer doesn't do gamma correction, then linear images will look too dark, and gamma corrected images will ok. Why Linear images are sometimes not such a good thing ----------------------------------------------------- One of the reason that many high quality formats (such as Video) use gamma correction is that it actually makes better use of the storage medium. This is because the human eye has a logarithmic response to light, and gamma correction has a similar compression characteristic. This means images could make better use of 8 bits per color (for instance), if they used gamma correction. The implication, though, is that every time you want to do any image processing you should convert the 8 bit image to 12 or so linear bits to retain the same accuracy. Since little popular software does this, and none of the popular image formats can agree on a standard gamma correction factor, it is difficult to justify gamma corrected images at the popular level. If some image formats can standardize on a particular gamma, and if image manipulation software takes care to use extra precision when dealing with linearized internal data, then gamma corrected distribution of images would be a good thing. (I am told that the Kodak PhotoCD format for instance, has a standard gamma correction factor that enables it to get the highest quality out of the bits used to hold the image). ------------------------------------------------------------------------------- 3D Studio Rendering, by Chris Williams (chrisw@fciad2.bsd.uchicago.edu) > I've read numerous times in this newsgroup that Autodesk 3d Studio v2 >doesn't support ray-tracing. I'm just wondering how one renders images >with lights/objects casting shadows as well as reflection mapping materials >without raytracing. Can someone tell me what I'm missing here? Shadows are done via Z-buffering. Imagine that you wish to have an object cast a shadow on a floor. Render the scene once from the point of view of the shadow-casting spotlight. The areas that are obscured in that image (the underside of the object and part of the floor) will be in shadow when rendered from the regular camera. When the scene is actually rendered that image (which also contains depth information i.e. how far each surface was from the shadow-spot) is used to to determine what is and isn't in shadow. Reflections are done with reflection maps or cubic environment maps. Take the example of a chrome ball on a checkered floor (please). Place the camera *inside* the chrome ball. Render six images, one in each of the cardinal directions, square. These six (pos X, neg X, pos Y, neg Y, pos Z and neg Z) are combined into one image that is "wrapped around" the ball. It usually works pretty well. Frankly, most people pay little attention to the content of a reflection, and it's possible to cheat like a professional wrestling villian. One other advantage of reflection maps, once the reflected items are in the map, if they aren't otherwise visible in the scene, they no longer need to be in the scene. In raytracing, every reflected object has to be there, and costs quite a bit. If your object is a brushed metal, for instance, you can just paint blobs of color and blur the whole thing and use *that* as your reflection map. ------------------------------------------------------------------------------- Ray-Bezier Patch Intersection, by Chuck McKinley, Max Froumentin (mckinley@fed3005.ne1300.ingr.com, froument@lifl.lifl.fr) Chuck McKinley writes: If some kind person has access to a mathematical package such as Mathematica, Maple,... I would like to ask you for the solution to the following problem. I sometimes have algebra problems like this where I would like a simplified symbolic solution. Is there a FTP-able package out there that can handle such beasts? I would like to solve the following ray - Bezier patch intersection for the scalar constant t in: P + t * V = Q(u,w) (origin point in 3D) (dir vector 3D) ----- Max Froumentin replies: Well, there is a formula. But you probably don't want to know it: One usual method is to write the Bezier parametric equation (Q(u,v)=...) in the form of an implicit surface (f(x,y,z)=0 where f is a polynomial). You can then insert the parametric equations of your ray and get a equation in t, giving you the intersection points. That's all right for low degree surfaces like planes or quadrics. But for a Bezier patch of parametric degree n, the resulting implicit equation is of degree 2n^2. As you use degree 3 Bezier patches, you will get an implicit equation of degree 18! Even if you type the whole formula in your program, you probably know of the extremely low accuracy of high-degree polynomials in computers... Instead, people use approximation methods, like two-dimensional Newton iteration. See the book by Glassner on ray-tracing for further details, or look at the POV source code. ------------------------------------------------------------------------------- Turbulence and Noise, by Ken Perlin [Since course notes are so hard to get, I thought I would reprint this. Bernie Kirby sent this to Thomas Setzer, who posted it, and now it's here.] EXCERPTED FROM SIGGRAPH 92, COURSE 23 PROCEDURAL MODELING Ken Perlin New York University 3.6 TURBULENCE AND NOISE 3.6.1 The turbulence function The turbulence function, which you use to make marble, clouds, explosions, etc., is just a simple fractal generating loop built on top of the noise function. It is not a real turbulence model at all. The key trick is the use of the fabs() function, which makes the function have gradient discontinuity "fault lines" at all scales. This fools the eye into thinking it is seeing the results of turbulent flow. The turbulence() function gives the best results when used as a phase shift, as in the familiar marble trick: sin(point + turbulence(point) * point.x); Note the second argument below, lofreq, which sets the lowest desired frequency component of the turbulence. The third, hifreq, argument is used by the function to ensure that the turbulence effect reaches down to the single pixel level, but no further. I usually set this argument equal to the image resolution. float turbulence(point, lofreq, hifreq) float point[3], freq, resolution; { float noise3(), freq, t, p[3]; p[0] = point[0] + 123.456; p[1] = point[1]; p[2] = point[2]; t = 0; for (freq = lofreq ; freq < hifreq ; freq *= 2.) { t += fabs(noise3(p)) / freq; p[0] *= 2.; p[1] *= 2.; p[2] *= 2.; } return t - 0.3; /* readjust to make mean value = 0.0 */ } 3.6.2 The noise function noise3 is a rough approximation to "pink" (band-limited) noise, implemented by a pseudorandom tricubic spline. Given a vector in 3-space, it returns a value between -1.0 and 1.0. There are two principal tricks to make it run fast: - Precompute an array of pseudo-random unit length gra- dients g[n]. - Precompute a permutation array p[] of the first n integers. Given the above two arrays, any integer lattice point (i,j,k) can be quickly mapped to a pseudorandom gradient vector by: g[ (p[ (p[i] + j) % n ] + k) % n] By extending the g[] and p[] arrays, so that g[n+i]=g[i] and p[n+i]=p[i], the above lookup can be replaced by the (somewhat faster): g[ p[ p[i] + j ] + k ] Now for any point in 3-space, we just have to do the following two steps: (1) Get the gradient for each of its surrounding 8 integer lattice points as above. (2) Do a tricubic hermite spline interpolation, giving each lattice point the value 0.0. The second step above is just an evaluation of the hermite derivative basis function 3 * t * t - 2 * t * t * t in each by a dot product of the gradient at the lattice. Here is my implementation in C of the noise function. Feel free to use it, as long as you reference where you got it. :-) /* noise function over R3 - implemented by a pseudorandom tricubic spline */ #include #include #define DOT(a,b) (a[0] * b[0] + a[1] * b[1] + a[2] * b[2]) #define B 256 static p[B + B + 2]; static float g[B + B + 2][3]; static start = 1; #define setup(i,b0,b1,r0,r1) \ t = vec[i] + 10000.; \ b0 = ((int)t) & (B-1); \ b1 = (b0+1) & (B-1); \ r0 = t - (int)t; \ r1 = r0 - 1.; float noise3(vec) float vec[3]; { int bx0, bx1, by0, by1, bz0, bz1, b00, b10, b01, b11; float rx0, rx1, ry0, ry1, rz0, rz1, *q, sy, sz, a, b, c, d, t, u, v; register i, j; if (start) { start = 0; init(); } setup(0, bx0,bx1, rx0,rx1); setup(1, by0,by1, ry0,ry1); setup(2, bz0,bz1, rz0,rz1); i = p[ bx0 ]; j = p[ bx1 ]; b00 = p[ i + by0 ]; b10 = p[ j + by0 ]; b01 = p[ i + by1 ]; b11 = p[ j + by1 ]; #define at(rx,ry,rz) ( rx * q[0] + ry * q[1] + rz * q[2] ) #define surve(t) ( t * t * (3. - 2. * t) ) #define lerp(t, a, b) ( a + t * (b - a) ) sx = surve(rx0); sy = surve(ry0); sz = surve(rz0); q = g[ b00 + bz0 ] ; u = at(rx0,ry0,rz0); q = g[ b10 + bz0 ] ; v = at(rx1,ry0,rz0); a = lerp(sx, u, v); q = g[ b01 + bz0 ] ; u = at(rx0,ry1,rz0); q = g[ b11 + bz0 ] ; v = at(rx1,ry1,rz0); b = lerp(sx, u, v); c = lerp(sy, a, b); /* interpolate in y at lo x */ q = g[ b00 + bz1 ] ; u = at(rx0,ry0,rz1); q = g[ b10 + bz1 ] ; v = at(rx1,ry0,rz1); a = lerp(sx, u, v); q = g[ b01 + bz1 ] ; u = at(rx0,ry1,rz1); q = g[ b11 + bz1 ] ; v = at(rx1,ry1,rz1); b = lerp(sx, u, v); d = lerp(sy, a, b); /* interpolate in y at hi x */ return 1.5 * lerp(sz, c, d); /* interpolate in z */ } static init() { long random(); int i, j, k; float v[3], s; /* Create an array of random gradient vectors uniformly on the unit sphere */ srandom(1); for (i = 0 ; i < B ; i++) { do { /* Choose uniformly in a cube */ for (j=0 ; j<3 ; j++) v[j] = (float)((random() % (B + B)) - B) / B; s = DOT(v,v); } while (s > 1.0); /* If not in sphere try again */ s = sqrt(s); for (j = 0 ; j < 3 ; j++) /* Else normalize */ g[i][j] = v[j] / s; } /* Create a pseudorandom permutation of [1..B] */ for (i = 0 ; i < B ; i++) p[i] = i; for (i = B ; i > 0 ; i -= 2) { k = p[i]; p[i] = p[j = random() % B]; p[j] = k; } /* Extend g and p arrays to allow for faster indexing */ for (i = 0 ; i < B + 2 ; i++) { p[B + i] = p[i]; for (j = 0 ; j < 3 ; j++) g[B + i][j] = g[i][j]; } } ------------------------------------------------------------------------------- Ray Tracing Research Ideas, by Klaus Lisberg Kristensen & Christian Gautier [Some of these ideas have already been researched a bit, some ideas I don't understand, but I thought I'd pass on the list. -EAH] We put a request out for research topics in ray tracing. We have received a lot of good ideas, articles etc., and we are now going through all of them. The areas suggested are (in very short terms): - Methods to model the colors using spectral curves for the light sources. This could help problems like color-aliasing and machine dependency. - Modelling reflections from oil in a water puddle, turbulent water stream, human bodies(or dinosaurs :)) by modelling every muscle. - Modelling dirt was suggested by several people. - Alternative ray-tracing methods. - Non-realistic rendering. - Don Mitchell's interval arithmetic approach to intersection. - A memory-efficient algorithm for discrete ray-tracing. - Radiosity simulation by stochastic ray-tracing. - Optically correct lens emulators. - Modelling clouds, misty nights or a river in the mountains. ------------------------------------------------------------------------------- POV-Ray Utilities, by Dan Farmer (70703.1632@CompuServe.COM) (This listing is about a year out-of-date) [I thought I would include this old list to give a sense of the support out there for POV. There's lots more out there than just this - anyone with a current list, please do send it on. -EAH] Object Creation Utilities ------------------------- CHAIN101.ZIP = Chain generator. CHEMCONV.ZIP = Convert data from Larry Puhl's CHEM molecular modeller. CM.ZIP = CircleMaster - Truman Brown - allows you to create clipped spheres and ellipses that can cap your hyperboloids of two sheets perfectly giving the illusion of quartic blobs. WORM02.ZIP = Paint with spheres to generate points for CTDS. CTDS.ZIP = Connect The Dots Smoother - Truman Brown. Raytrace sources. makes your WORM output POV compatible. Writes a file using the WORM data, with your choice of spheres or ellipsoids, and will either connect the spheres with cones and cylinders, or just output the "dots." FONT2DAT.ZIP = Converts GRASP .fnt and .set font files to POV-Ray text. Fonts included. FRGEN13.ZIP = Midsection triangular displacement fractal surface generator. LISS152.ZIP = Generate 3D Lissajous traces with spheres. LISSAJ.ZIP = Another Lissajous path generator, w/graphics preview. PICKSHEL.ZIP = Make snail shells from spheres. POVCOIL2.ZIP = Hard to describe twisted coil objects. POV Sources POVTORUS.ZIP = Makes torus-like objects using cylindrical sections. SHADE1.ZIP = "Lampshade" generator. SPIKE.ZIP = Generate shapes with radial projection. SPRING12.ZIP = Generates and animates springs. SUDS.ZIP = Generates a "glob" of tangent spheres, rather like suds. TTG.ZIP = Creates POV-Ray torus data, the easy way - Truman Brown TWISTER.ZIP = Twisted objects such as Archimedes spirals. SWOOP.ZIP = Hard to describe extrusion generator. Very versatile. Miscellaneous Utilities ----------------------- CRNDR = CRENDER allows you to drop in and design that elusive color/lighting combination that you are looking for - it shines when it comes to designing just the right surface qualities. Lets you interactively play with many texture variables and see them rendered almost instantly on screen, then dump the texture to a POV file. Highly recommended for learning about textures. POV sources. MAKETILE.ZIP = Actually a PICLAB script. Great for making imagemaps. SPLITPOV.ZIP = Run a POV-Ray image in sections on multiple computers and glue them back together automatically. Best for use over a network. Generates batchfiles. TCE201 .ZIP = The Color Editor - Dan Farmer. A color viewer/editor. Create/edit your colors.inc file. Animation Utilities ------------------- ACCEL.ZIP = Generate acceleration data for use in an animation. ANIMK05B.ZIP = Excellent animation generator. CAMPATH1.ZIP = Generate circular, lemniscate, polar, and other camera path data. RTAG.ZIP = Special animation language (shareware) ANIBATCH.ZIP = Simple linear motion, generates a single batch file that creates frame data at runtime. AWK scripts for various data conversion and object generation ------------------------------------------------------------- AWKBLOB.AWK = Converts raw sphere data in the form of x y z r into blob components for POV-Ray. HSM2POV.AWK = Convert data from Mira Imaging's "Hyperspace" format to POV-Ray triangle data. HSM2RAW.AWK = Convert data from Mira Imaging's "Hyperspace" format to raw triangle data. By adding a sphere radius to the output vector and running the output through AWKBLOB.AWK, you could also convert "Hyperspace" data to blobs. Data Conversion Utilities ------------------------- RAW2POV.ZIP = Steve Anger - raw triangle vector data to well-bounded POV-Ray format as either normal, or Phong-shaded triangles. Very useful with other programs, but it doesn't really do anything by itself. 3DS2POV.ZIP = AutoDesk 3D-Studio ASCII data to POV-Ray files. 3D2POV15.ZIP = Amiga Sculpt3D to POV-Ray format. 3D2-POV = Cyber Sculpt (Atari) 3D2 files. DXF2POV.ZIP = AutoCAD and other DXF file data to POV-Ray files. SA2POV.ZIP = Sculpt-Animate data to POV-Ray files. SNDPPR.ZIP = raw triangle data to Phong-shaded. VCAD2POV.ZIP = Versa-CAD to POV-Ray. As I mentioned above, this listing is old, and is very definitely only a sampler of what is available. Almost all of these are free, the rest are inexpensive shareware. Most are available on CIS (GO GRAPHDEV), YCCMR BBS (Chicago. (708) 358-5611, or TGA BBS (510) 524-2780 as well as many of the nodes of the PCGNet, of which TGA is a hub. ------------------------------------------------------------------------------- SPD Platform/Compiler Results, by David Hook (dgh@ecr.mu.oz.au) [many thanks to David and Bernie Kirby for running the SPD test on a variety of platforms with various compiler options. Most of you will be bored to tears by this stuff, but I include it mostly so it gets archived somewhere. The things that are most noticeable are how performance varies between machines. Also, Rayshade does everything in doubles and most of the other ray tracers do everything in floats, so machines that can't or don't override the double<->float conversions that C requires tend to take a hit on these others. -EAH] About the benchmarks run: a) The Standard Benchmarks are run using the best available NFF to converter available. For example, this means that the awk script for rayshade was used as it supplied a default grid of 22x22x22, where as the "other" converter didn't. The rational behind this is that if the rayshade people have it in their converter, then it is the preferred option. b) The "tweaked" benchmarks are run with various grids and with the ground or backing polygon removed thus: balls: 20x20x20 - take background out of grid structure. gears: 21x21x21 - take background out of grid structure. mount: 21x21x21 rings: 21x21x21 - take background out of grid structure. teapot: 22x22x22 - The floor IS kept! tetra: 16x16x16 tree: 21x21x21 - take background out of grid structure. These pertain only to the ART/rayshade results, where the tweaking could be easily done. I hate to be the one to say this, but, it looks as if in some cases this actually slows the renderer down. These results are presented in a separate table as it didn't seem realistic (or fair) to compare the different ray tracers by massaging the input files. In any case they are only relevant to balls, gears, rings, and tree. The figures for art using a kdtree, where provided, indicate that taking the backing polygon out results in a nicely distributed data set in the subdivision and using a non-uniform subdivision is more a hindrance than a help (which is basically what you'd expect...). [There are art/kd results, where art uses a KD-tree for efficiency, and art/ug results, where art uses a uniform grid. Both versions of the code are available on the net. -EAH] c) All programs are compiled with Maximum optimization/and appropriate floating point. In the case of Art/Vort/*/dp this means that the -float, -fsingle or whatever was not used but that everything was compiled with -Dfloat=double. d) The Bob/Vivid raytracer had its "robust" memory allocation scheme replaced with "standard" malloc's as the robust scheme caused core dumps on SGI and RS6000 machines. e) All Benchmarks include the time taken to read the scene in. f) All times are in CPU seconds. g) We don't own any SGI, RS6000 or HP machines. The use of these machines was kindly allowed by their respective owners/admins. As such, we couldn't run every raytracer as we were wearing out our welcome as it was. h) All runs were done to completion at 512x512 pixels. i) We DID try to run POV, but as it was taking over 24 hours of CPU time we simply had to stop. Perhaps there is an NFF converter that inserts some bounding boxes automatically? j) Ratios calculated below for the Standard SPDs are done on the basis of Art/Vort/kd == the base line (it's the first in alphabetical order). k) In all cases we used the latest available versions of the software (hence the difference in Rtrace). [I have added "*" after the fastest ratio for easy visual comparison. -EAH] Standard SPDs ------------- Machine: SGI PI. ---------------- balls gears mount rings teapot tetra tree Art/Vort/kd 761.7 2296 414.6 1042 393.6 118.3 640.5 Art/Vort/ug 5958 1093 312.4 620.1 235.2 68 5761 Rayshade 2847 1950 899.5 1228 464 116 5602 Bob/Vivid 811 1369 446 1854 495 93.5 511 Rtrace8 1779 6236 2957 4840 1199 291 933 Ratios: ------ Art/Vort/kd 1.0 * 1.0 1.0 1.0 1.0 1.0 1.0 Art/Vort/ug 7.8 0.47 * 0.75 * 0.6 * 0.6 * 0.57 * 8.99 Rayshade 3.7 0.85 2.17 1.18 1.18 0.98 8.75 Bob/Vivid 1.06 0.6 1.08 1.78 1.26 0.79 0.79 * Rtrace8 2.33 2.71 7.13 4.64 3.05 2.45 1.46 Machine: IBM RS6000 ------------------- balls gears mount rings teapot tetra tree Art/Vort/kd 591.7 1847 325 812 334 107 534 Art/Vort/ug 3537 815 234 454 187 55 3215 Rayshade 1410 846 406 548 230 70 2418 Bob/Vivid 506 909 309 1095 323 68 348 Rtrace8 861 4684 1414 2267 587 145 469 Ratios: ------ Art/Vort/kd 1.0 1.0 1.0 1.0 1.0 1.0 1.0 Art/Vort/ug 5.98 0.44 * 0.72 * 0.56 * 0.56 * 0.51 * 6.02 Rayshade 2.38 0.46 1.25 0.67 0.68 0.65 4.53 Bob/Vivid 0.86 * 0.49 0.95 1.35 0.97 0.64 0.65 * Rtrace8 1.45 2.54 4.35 2.79 1.76 1.35 0.88 Machine: SUN SPARCstation2 -------------------------- balls gears mount rings teapot tetra tree Art/Vort/kd 705 1900 389 951 369 112 574 Art/Vort/ug 5768 974 319 570 231 71 5327 Rayshade 2422 1309 671 940 366 106 4473 Bob/Vivid 715 1181 392 1419 412 87 429.6 Rtrace8 1084 3151 1991 2950 765 204 573 Ratios: ------- balls gears mount rings teapot tetra tree Art/Vort/kd 1.0 * 1.0 1.0 1.0 1.0 1.0 1.0 Art/Vort/ug 8.18 0.51 * 0.82 * 0.6 * 0.62 * 0.63 * 9.28 Rayshade 3.43 0.69 1.72 0.99 0.99 0.95 7.8 Bob/Vivid 1.01 0.62 1.01 1.49 1.11 0.78 0.75 * Rtrace8 1.54 1.66 5.12 3.10 2.07 1.82 0.99 Machine: HP 720 --------------- balls gears mount rings teapot tetra tree Art/Vort/kd 308 915 156 400 155 58.1 252 Rayshade 870 507 203 292 122 41.7 2079 Ratios: ------- balls gears mount rings teapot tetra tree Art/Vort/kd 1.0 * 1.0 1.0 * 1.0 1.0 1.0 1.0 * Rayshade 2.82 0.55 * 1.3 0.73 * 0.78 * 0.72 * 8.25 Tweaked SPDs ------------ In cases where xxx appears, for one reason or another, we were unable to run the benchmark. Machine: SGI PI. ---------------- balls gears mount rings teapot tetra tree Art/Vort/ug/twk 208.4 1259 312.3 478.3 334.1 67.9 97.8 Rayshade/twk 377.7 2647 937 877 548 141 171 Ratios: ------ Art/Vort/ug/twk 1.0 * 1.0 * 1.0 * 1.0 * 1.0 * 1.0 * 1.0 * Rayshade/twk 1.8 2.1 3.00 1.83 1.64 2.07 1.75 Machine: IBM RS6000 ------------------- balls gears mount rings teapot tetra tree Art/Vort/kd/twk 353 1970.5 333.7 739.6 423.7 56.5 111.1 Art/Vort/ug/twk 153.4 887 238 352 269 56 75 Rayshade/twk 183 1078 407 428 292 88 88 Ratios: ------ Art/Vort/kd/twk 1.0 1.0 1.0 1.0 1.0 1.0 1.0 Art/Vort/ug/twk 0.43 * 0.45 * 0.71 * 0.48 * 0.63 * 1.0 * 0.67 * Rayshade/twk 0.52 0.55 1.22 0.58 0.68 1.56 0.79 Machine: SUN SPARCstation2 ------------------- balls gears mount rings teapot tetra tree Art/Vort/kd/twk 417 2130 389 846 369 112 128 Art/Vort/ug/twk 202 1081 319 436 366 72 103 Rayshade/twk 293 1635 675 750 467 130 148 Ratios: ------- balls gears mount rings teapot tetra tree Art/Vort/kd/twk 1.0 1.0 1.0 1.0 1.0 1.0 1.00 Art/Vort/ug/twk 0.48 * 0.51 * 0.89 * 0.51 * 0.99 * 0.64 * 0.80 * Rayshade/twk 0.70 0.77 1.74 0.89 1.27 1.16 1.16 Machine: HP 720 --------------- balls gears mount rings teapot tetra tree Art/Vort/kd/twk 186 1029 156 xxx 155 58.1 91 Art/Vort/ug/twk 89 527 xxx 168 138.7 41.4 39.7 Rayshade/twk 99 676 202 237 161 51.4 51.2 Ratios: ------- balls gears mount rings teapot tetra tree Art/Vort/kd/twk 1.0 1.0 1.0 xxx 1.0 1.0 1.0 Art/Vort/ug/twk 0.48 * 0.51 * xxx 1.0 * 0.89 * 0.70 * 0.42 * Rayshade/twk 0.53 0.65 1.29 1.41 0.96 0.88 0.56 [My figures do not seem to match these that well: in my tests on the HP 720 Rayshade seemed to always outperform art. We're not sure why there's a mismatch. -EAH] * * * * * * * * * A comparison of float vs. doubles where float promotion to double can be disabled. As art seems to be the only one that declares most things as floats, this is the subject of these runs. Machine: SGI PI. ---------------- Option: Single precision -float Double precision -Dfloat=double balls gears mount rings teapot tetra tree Art/Vort/kd 761.7 2296 414.6 1042 393.6 118.3 640.5 Art/Vort/kd/dp 978 3000 xxxx 1365 520 152 777 Art/Vort/ug/twk 208.4 1259 312.3 478.3 334.1 67.9 97.8 Art/Vort/ug/twk/dp 295 1882 449 681 514 109 141 Ratios: ------ Art/Vort/kd 1.0 1.0 1.0 1.0 1.0 1.0 1.0 Art/Vort/kd/dp 1.28 1.3 .... 1.3 1.32 1.27 1.21 Art/Vort/ug/twk 1.0 1.0 1.0 1.0 1.0 1.0 1.0 Art/Vort/ug/twk/dp 1.4 1.49 1.43 1.42 1.53 1.6 1.44 Machine: IBM RS6000 ------------------- No such option. The times were much the same. Machine: SUN SPARCstation2 ------------------- Option: Single precision -fsingle Double precision -Dfloat=double balls gears mount rings teapot tetra tree Art/Vort/kd 705 1900 389 951 369 112 574 Art/Vort/kd/dp 791 xxx 413 1034 428 127 625 Art/Vort/ug/twk 202 1081 319 436 366 72 103 Art/Vort/ug/twk/dp 214 1219 341 476 1027 78 114 Ratios: ------- balls gears mount rings teapot tetra tree Art/Vort/kd 1.0 1.0 1.0 1.0 1.0 1.0 1.0 Art/Vort/kd/dp 1.12 xxx 1.06 1.08 1.16 1.13 1.08 Art/Vort/ug/twk 1.0 1.11 1.0 1.0 1.58 1.01 1.0 Art/Vort/ug/twk/dp 1.06 1.13 1.07 1.09 2.8 1.08 1.1 Machine: HP 720 --------------- Option: Single precision +f Double precision -Dfloat=double balls gears mount rings teapot tetra tree Art/Vort/kd 308 915 156 400 155 58.1 252 Art/Vort/kd/dp 300 926 138 390 155 60.3 244 Art/Vort/ug/twk 89 527 xxx 168 139 41.4 39.7 Art/Vort/ug/twk/dp 117 560 xxx 234 168 43.1 46 Ratios: ------- balls gears mount rings teapot tetra tree Art/Vort/kd 1.0 1.0 1.0 1.0 1.0 1.0 1.0 Art/Vort/kd/dp 0.97 1.01 0.88 0.975 1.0 1.03 0.97 Art/Vort/ug/twk 1.0 1.0 xxx 1.0 1.0 1.0 1.0 Art/Vort/ug/twk/dp 1.31 1.06 xxx 1.39 1.2 1.04 1.15 ------------------------------------------------------------------------------- END OF RTNEWS