Path: utzoo!attcan!uunet!snorkelwacker!bloom-beacon!eru!hagbard!sunic!uupsi!eye!erich From: erich@eye.com ( Eric Haines) Newsgroups: comp.graphics Subject: Ray Tracing News, Volume 3, Number 4 Summary: here 'tis, at last Message-ID: <1990Oct01.153315.16633@eye.com> Date: 1 Oct 90 15:33:15 GMT Sender: Eric Haines Reply-To: erich@eye.com (Eric Haines) Organization: 3D/Eye Inc., Ithaca, NY Lines: 1292 This issue is the longest to date. As such, I've deleted the Usenet postings from this posting (they're about 55K more characters!) - go to the FTP sites sometime after October 5th to get the full issue (sorry it can't be sooner, but my FTP usage is limited). -EAH _ __ ______ _ __ ' ) ) / ' ) ) /--' __. __ , --/ __ __. _. o ____ _, / / _ , , , _ / \_(_/|_/ (_/_ (_/ / (_(_/|_(__<_/ / <_(_)_ / (_ 0 ) /* ray is outside half-space */ return MISSED Else /* ray not parallel */ T = do / dp If ( dp < 0 ) /* front face - T is a near point */ If ( T > Maxdist ) return MISSED If ( T > Tnear ) Tnear = T Normal = plane.normal Else /* back face - T is a far point */ If ( T < 0.0 ) return MISSED If ( T < Tfar ) Tfar = T If ( Tnear > Tfar ) return MISSED endfor return HIT At the end, Tnear is the intersection distance and Normal is the surface normal. Tfar is the exit distance, if needed. That's it: instead of laborious inside/outside testing of the polygon on each face (and storing all those vertices), we have a quick plane test for each face. If the number of planes is large, it might have been better to store the polygons and use an efficiency scheme. However, the method above is certainly simpler to code up and is pretty efficient, compact, and robust: for example, there are no special edge intersection conditions, as there are no edges! An aside: One thing that I hadn't mentioned is how we can better initialize the near and far hit distances before the slab tests. It turns out that when testing bounding volumes we can set Tnear (the near distance) to 0 and Tfar to the maximum ray distance (if any - else set it to "infinity"). This corresponds to the segment formed by the ray: we consider points between 0 and the maximum ray distance to be valid points on the ray, and so want to find slab segments that overlap this segment. Note that these initial conditions gets rid of some complication for the algorithm: we now don't have to test our slab segment against the ray's segment and the previous bounding volume segment, but rather are always testing against a single segment which represents the intersection of both of these. This idea is not in Kay & Kajiya's presentation, by the way. Note that there is one change that occurs if you initialize the near and far distances in this way: the near and far distances computed when a volume is hit will not yield the true surface intersections, but rather will give the first and last points inside the volume. This is useful for bounding volumes, since we usually just want to know if we hit them and have some idea of the distance. ------------------------------------------------------------------------------- New Radiosity Bibliography Available, by Eric Haines A bibliography of publications related to radiosity is now available at: freedom.graphics.cornell.edu [128.84.247.85]: /pub/Radiosity It's a compressed package using "refer" format. Articles related to radiosity or "non-classical" rendering (soft shadows, caustics, etc) are included here. This version is significantly improved from the version I posted some months ago. Many thanks to all who helped update it. ------------------------------------------------------------------------------- A Suggestion for Speeding Up Shadow Testing Using Voxels, by Andrew Pearce Requirements: ------------ This method is applicable to any type of spatial subdivision. It is probably best suited to those of us who tessellate our objects to ray trace them. Method: ------ I've expanded on Eric Haines' method of storing the last object hit by a shadow ray with each light source, I now save a pointer to the voxel which contains the last object hit (or at least the voxel the intersection occurred in if the object spans multiple voxels). My rationale is that if the shadow ray does NOT intersect the "last object" which shadowed that light source, then the likelihood of it hitting something in the neighborhood of that same object is pretty good. If we save the voxel which the shadowing occurred in for the previous ray, we can examine the other objects in that voxel for possible light source occlusion WITHOUT the ray startup and voxel traversal costs. Now this assumption is likely untrue if you're just tracing spheres and checker boards (some slight intended :^) but it works quite well for tessellated objects (NURBS patches in my case). I NULL my pointers to both the last object and last voxel if no shadow intersection was found on the last shadow ray to this light. I store a ray_id with every object to insure that any given ray is tested for intersection with an object ONLY ONCE even if it spans multiple voxels. Each ray has a unique id. (I thought, as did David Jevans, that this was a well known technique). So, even if the shadow ray misses all of the objects in "last voxel" and must be traced like a regular shadow ray, we are likely not losing much since if the shadow ray enters the "last voxel" during it's traversal of the voxels, the ray will see that it has already been intersected with all of the objects in that voxel, and that voxel will be skipped relatively quickly (slightly slower than an empty voxel; the time it takes to compare the ray ID against the ray ID stored with each object). Pseudo-code: ----------- /****************************************************************************/ /* Obviously we cannot use the "last object hit" for transparent */ /* objects since multiple objects may be involved in the shadowing process. */ /* The code outlined below assumes that we only store the "last object" and */ /* "last voxel" for shadow rays generated from a primary ray intersection. */ /* What we really should have is a tree indicating what was hit at each */ /* level of recursion. Ie. What object shadowed the intersection point */ /* generated by the last refraction ray, generated from a reflection ray */ /* generated by a primary ray? */ /****************************************************************************/ float check_shadowing(ray, light) RAY_REC ray; /* ray from shading point to light source */ LIGHT_REC light; /* the light source we are interested in */ { if (light.last_object != NULL) { /* intersect_object() marks object as having been */ /* intersected by this ray. */ hit = intersect_object( ray, light.last_object, &object); if (hit) { return(1.0); /* full shadowing */ } if (light.last_voxel != NULL) { /* implied !hit */ /* intersect_object_in_voxel_for_shadows() returns hit = TRUE */ /* on first affirmed intersection with a non-transparent * object. */ /* It ignores transparent objects altogether. */ hit = intersect_objects_in_voxel_for_shadows( ray, light.last_voxel, &object); if (hit) { light.last_object = object; return(1.0); } } } /* traverse_voxels_for_shadows() DOES intersect transparent objects and */ /* sorts the intersections for proper attenuation of the light intensity. */ /* If it hits multiple objects, the object returned is the transparent one. */ hit = traverse_voxels_for_shadows(ray, &object, &voxel, &shadow_percent); if (!hit) { light.last_object = light.last_voxel = NULL; return(0.0); } if (object.transparency_value > 0.0) { /* the object is transparent */ light.last_object = light.last_voxel = NULL; } else { light.last_object = object; light.last_voxel = voxel; } return ( shadow_percent ); } Results: ------- (For the discussion below, "positive occlusion" means we have guaranteed that the point we are shading is shadowed from the light source.) The "last object hit" method provided a positive occlusion 52% of the time, and if the "last object hit" method did not provide positive occlusion, the "last voxel" method provided a positive occlusion 76% of the time. I performed a "pixie" of the code with and without this opt. on an SGI Personal Iris with no other code changes or scene changes, there is ONE light source in the scene which is casting shadows. The ray tracer with the "last voxel" optimization used 2% fewer cycles. (Actual system times vary wildly based on load, but the last voxel version did run about 10% faster using the UNIX "times()" system call, but I don't trust "times()"). Two percent doesn't seem like an awful lot, but this is just a quick and dirty hack, and I would expect to save 2% on EACH light source which casts shadows. The test scene I'm using is a snare drum with a shadow casting spotlight on it. See IEEE Computer Graphics & Applications, Sept. 1988, the cover story includes a tiny reproduction of the image should you wish to see what I'm playing with, although the image in CG&A was done with a 2D projective renderer (ray casting), not ray tracing. The reflections in the floor and on the chrome in that image were realised using two separate cubic environment maps, the shadows were done with a depth map, the wallpaper is a simple parametric map and the floor boards have 6 separate solid wood textures randomly assigned to them. The test scene contains approximately 60,000 triangles and I'm rendering at 512x512 resolution with no anti-aliasing, and a limit of one recursion level for both shadow and reflection rays for a total of 638,182 rays. There is only one light in the scene which casts shadows. I'll be doing tests on more scenes with various levels of voxel subdivision, and object distribution. I'll let you know the results, even if they're negative! (The above results did surprise me a little). Additional Note: I urge anyone doing ray/triangle intersections to use Didier Badouel's "An Efficient Ray-Polygon Intersection" (Graphics Gems pp. 390-393). I have implemented both Badouel's method and Snyder/Barr's barycentric method, and Badouel's method is about 19% faster (I optimized the snot out of my implementation of the barycentric method, but I used most of those same opts in Badouel's method as well). This result is from comparing the same scene ray traced with the two versions. _________________________________________________________________________ [A second article followed some days later - EAH] More results from the voxel/shadow optimization: ----------------------------------------------- One thing I neglected to mention in the previous message was that you should be sure to NULL out your last object and last voxel hit pointers at the end of each scanline. NEW TEST SCENES: --------------- The test scenes producing the results below are 40x40x40 arrays of polygons (each polygon is broken down into 8 triangles). The polygons are distributed at unit distances from each other, and then their orientations are jittered (rotations) and their positions are jittered (translate of -1. to +1.). Each polygon is roughly a unit in width and height. The polygons are inside of a larger box (the room) with 15 shadow casting lights in a 5x3 array just below the "ceiling". There were no reflection or refraction rays generated. All images were computed at 645x486 pixels with 4 supersamples per pixel. Every intersection generated 15 shadow rays. The "sparse" scene had every polygon scaled by 0.2 in all dimensions. The resulting sparse image looks like an exploding particle system (due mainly to the 145 degree field of view). In the dense image, almost no background can be seen. CHART DESCRIPTION: ----------------- "Last Voxel" speed up refers to the percentage fewer cycles the "last voxel" method took to compute the same image. Since this percentage is calculated based on the number of cycles the entire ray trace took, it is an exact measure of the speed up. Negative numbers mean that the "last voxel" method was slower. It is important to note that file read, tessellation and spatial subdivision time is included in the count of the cycles, so the actual speed up to the ray tracing alone may be greater than is stated, depending on how you want to measure things. Average Hits Per Ray is included as a general measure of the density of the scene, it is the number of confirmed ray/triangle intersections divided by the total number of rays (shadow rays included). In the sparse scene it is less than one since most of the shadow rays made it to the light sources without hitting anything. The dense scene is greater than one because some confirmed intersections are abandoned due to nearer intersections being found in the same voxel. Average Hits Per Primary Ray is the number of confirmed ray/triangle intersections divided by the number of primary (eye) rays. --------------+-----------------+-----------------+ Scene | 64,000 jittered | 64,000 jittered | Description | polygons (0.2) | polygons (1.0) | | (sparse) | (dense) | --------------+-----------------+-----------------+ Number of | 551,408 | 551,408 | Triangles | | | --------------+-----------------+-----------------+ Number of | | | Shadow Casting| 15 | 15 | Lights | | | --------------+-----------------+-----------------+ Number of Rays| 11,324,318 | 8,427,904 | --------------+-----------------+-----------------+ "Last Object" | | | Success Rate | 50.7% | 90.9% | --------------+-----------------+-----------------+ "Last Voxel" | | | Success Rate | 23.4% | 39.3% | --------------+-----------------+-----------------+ "Last Voxel" | | | Speed Up | 1.04% | 3.6% | --------------+-----------------+-----------------+ Average Hits | | | Per Ray | 0.265 | 1.001 | --------------+-----------------+-----------------+ Average Hits | | | Per Primary | 2.363 | 6.638 | Ray | | | --------------+-----------------+-----------------+ It is encouraging that there is a speedup even in very sparse scenes (however slight a speed-up it is). These "random" scenes are not very indicative of the type of scenes we are generally interested in ray tracing. (Really, these scenes look like particle systems, I can think of much better ways to render them with to produce similar images :^). So, here's the same chart for the snare drum with increasing numbers of lights. The extra lights are scattered around the "room" and all point towards "Spanky" the snare drum. --------------+---------+---------+---------+ Scene | Snare 1 | Snare 3 | Snare 6 | Description | Shadow | Shadow | Shadow | | Light | Lights | Lights | --------------+---------+---------+---------+ Number of | 59,692 | 59,692 | 59,692 | Triangles | | | | --------------+---------+---------+---------+ Number of | | | | Shadow Casting| 1 | 3 | 6 | Lights | | | | --------------+---------+---------+---------+ Number of Rays| 638,182 |1,097,569|1,737,021| --------------+---------+---------+---------+ "Last Object" | | | | Success Rate | 52.6% | 89.0% | 88.7% | --------------+---------+---------+---------+ "Last Voxel" | | | | Success Rate | 76.3% | 77.0% | 76.9% | --------------+---------+---------+---------+ "Last Voxel" | | | | Speed Up | 1.97% | 3.37% | 4.39% | --------------+---------+---------+---------+ Average Hits | | | | Per Ray | 0.75 | 0.67 | 0.59 | --------------+---------+---------+---------+ Average Hits | | | | Per Primary | 1.84 | 2.84 | 3.94 | Ray | | | | --------------+---------+---------+---------+ Well, the speed-up isn't quite 2% per light as I said in my previous article, but it is there. The "last voxel" trick has not slowed down the ray tracing process in any of these tests which is quite encouraging. ------------------------------------------------ Another helpful hint if you are ray tracing tessellated or planar surfaces: In general when spawning a shadow ray, one must be careful to avoid intersecting the object just struck. Usually this is done by adding some small epsilon to the origin of the shadow ray along it's direction of travel. However, if you store a ray id with every object (triangle) to record if that object has been tested against the current ray, then you can use that id to avoid testing your shadow ray against the intersected object which generated the shadow ray. Before spawning the shadow ray, place the id number of the shadow ray into the ray id field of the object which has just been intersected. This method won't work for objects which can self shadow (eg. parametric or implicit surfaces), but it works fine for planar surfaces (eg. triangles from surface tessellations). -------------------------------------------------------- - Andrew Pearce, Alias Research, Toronto, like Downtown - pearce%alias@csri.utoronto.ca | pearce@alias.UUCP ------------------------------------------------------------------------------- Real3d, passed on by Juhana Kouhia (jk87377@tut.fi) and "Zap" Andersson [This was an advertisement on some amiga board.] Real 3D FEATURES ---------------- Real 3D is design and animation program for producing high quality, realistic pictures of three dimensional objects. It provides an impressive set of advanced features including: Ray Tracing A ray tracing of Real 3D is strongly based on the physical reality of the real world. Real 3D produces pictures by simulating the laws of physics, and consequently they represent reality with astonishing accuracy. Speed Innovative methods and new ray tracing algorithms make Real 3D really fast. When using fastest ray tracing mode, rendering time is typically from 1 to 15 minutes. Hierarchical With Real 3D you can create hierarchical objects. Object This means that objects you create can be made of Oriented subobjects, and these subobjects may have their Construction own substructure and so on. This kind of a tree of Objects structure is well known in the context of disk operating systems, in which you can create directories inside directories. In Real 3D counterparts of these directories are used to collect objects into logical groups. This kind of approach makes for example object modifications extremely easy, because it is possible to perform operations to logical entities. If you want to copy a DOS directory, you don't have to take care of the files and directories inside it. In the same manner, you can stretch a complex object in Real 3D as easily as one part of it. True Solid Real 3D includes a true solid modeler. Solid model is the Model most sophisticated way to represent three dimensional objects. This modeling technique requires much computing power and therefore it has earlier been used only in environments, which are many times faster than Amiga. Now it is possible to Amiga owners to reach all the advantages of solid model, thanks to ultimate optimizations carried out when developing Real 3D. Smoothly Curved In addition to plane surfaces, Real 3D includes several Surfaces curved surfaces, such as ball, cylinder, cone and hyperboloid. This means that no matter how much you enlarge a ball created by Real 3D, you don't find any edges or corners on its surface. Furthermore, this makes the program much faster. And what is most important, the produced pictures look really good. Boolean Solid model allows Boolean operations between objects. Operations It is possible, for example, to split an object into two pieces and move the pieces apart so that the inner structure of the object is revealed. Operations can also be done so that the properties of the material of the target object are changed. By using a brilliant cylinder one can drill a brilliant hole into a matt object. Operations are a powerful way to create and modify objects. Especially in modeling technical objects these Boolean operations are indispensable. Properties of A user of Real 3D is not restricted to use some basic Surfaces surface brilliancies such as matt or shiny. Instead, the light reflection properties can be freely adjusted from absolute matt to totally mirrorlike, precisely to the desired level. Properties of Due to solid model, it is possible to create objects Materials from different materials, which have suitable physical properties. Just as surface brilliancy, also transparency of a material can be adjusted without any restrictions. Even light refraction properties are freely adjustable so that it is possible to create optical devices from glass lenses. These devices act precisely as their real counterparts: a magnifying glass in Real 3D world really magnifies! Texture Mapping The texture mapping properties of Real 3D are not restricted to a typical chequered pattern: Any IFF picture can be used to paint objects. You can create pictures with your favorite painting program as well as with a video digitizer or a scanner. For example, by digitizing a wood filament pattern, it is easy to create wooden objects looking very realistic. Pictures can be located precisely to desired places, with desired sizes and directions. Real 3D offers as many as seven texture mapping methods, including parallel, cylinder, ball and spiral projections. Light Sources Unlimited number of light sources of desired color and brightness. The only restriction is amount of memory. Animation As well as you can create single pictures, you can Support create series of pictures, animations. Real 3D includes also software for representing these animations interactively. Animation representation can be directed by a script language from ascii files or even from keyboard. Instead of looping animations you can define infinitely many ways to represent your pictures. Therefore you can create animations from a small number of pictures by displaying them various ways. Rendering Real 3D includes several different rendering techniques: Techniques a real time wireframe model, a hidden line wireframe model, a high speed one light source ray tracing model, a non-shadow-casting ray tracing model and a perfect ray tracing model. You can select either a HAM display mode with 4096 colors or a grey scale display mode offering higher resolution. Also version with 16 million color rendering (24 bits output) will become available during November 1990. Availability When writing this document (6.9.1990), marketing of Real 3D is already started in Europe with a little lower price than that of Sculpt 4D. The distribution in the USA is not yet arranged. For further information of Real 3D, please contact: REALSOFT KY KP 9, SF-35700 VILPPULA FINLAND Tel. +358-34-48390 -------- from "Zap" Andersson: REAL3d ('member that?) is available (in Sweden at least) from: KARLBERG & KARLBERG AB FLADIE KYRKOVAEG S-23700 BJARRED SWEDEN Phone: +46(0)46-47450 Phax: +46(0)46-47120 ------------------------------------------------------------------------------- Utah Raster Toolkit Patch, by Spencer Thomas The first patch for the Utah Raster Toolkit version 3.0 is now available. The patch file is urt-3.0.patch1, and is currently available from cs.utah.edu and freebie.engin.umich.edu, and will soon be available from our other archive sites (depending on how quickly the archive maintainers grab the patch file). There are also slight changes to the files urt-img.tar and urt-doc.tar (in particular, if you had trouble printing doc/rle.ps, this is fixed). [p.s. there was also a fix to a getx11 bug for the Sun 4, which is pub/urt-SUNOS4.1-patch.tar.Z on freebie and weedeater. --EAH] Here is the description from the patch file: Fixed core dump in rletogif, compile warnings in giftorle. Minor update bug in getx11 fixed. getx11 now exits if all its input files are bogus. New program: rlestereo, combines two images (left and right eye) into a red-blue (or green) stereo pair. Configuration file for Interactive Systems 386/ix. Minor fix to rleskel: ignore trailing garbage in an input image. And the list of the current archive sites, from the urt.README file in the ftp directory: North America East coast weedeater.math.yale.edu 130.132.23.17 (pub/*) Midwest freebie.engin.umich.edu 35.2.68.23 (pub/*) West cs.utah.edu 128.110.4.21 (pub/*) Europe Sweden alcazar.cd.chalmers.se 129.16.48.100 (pub/urt/urt-3.0.tar.Z) maeglin.mt.luth.se 130.240.0.25 (pub/Utah-raster/*) Australia ftp.adelaide.edu.au 129.127.40.3 (pub/URT/*) or, if you know what this means: Fetchfile: sirius.ua.oz in URT =Spencer W. Thomas EECS Dept, U of Michigan, Ann Arbor, MI 48109 spencer@eecs.umich.edu 313-936-2616 (8-6 E[SD]T M-F) ------------------------------------------------------------------------------- NFF Shell Database, by Thierry Leconte (Thierry.Leconte@irisa.fr) [Below is Thierry Leconte's code for an NFF version of the seashell generator I listed last issue. He added some reasonable lights and a view (which I was too lazy to do). I'll probably add it to the 3.0 version of the SPD. Setting "steps" is similar to an SPD SIZE_FACTOR type control. You'll need the SPD to compile and link this program. -- EAH] #include #include #include "def.h" #include "lib.h" main(argc,argv) int argc; char *argv[]; { static double gamma = 1.0 ; /* 0.01 to 3 */ static double alpha = 1.1 ; /* > 1 */ static double beta = -2.0 ; /* ~ -2 */ static int steps = 600 ; /* ~number of spheres generated */ static double a = 0.15 ; /* exponent constant */ static double k = 1.0 ; /* relative size */ double r,x,y,z,rad,angle ; int i ; COORD4 back_color, obj_color ; COORD4 center, light ; COORD4 from, at, up ; COORD4 sphere; #define OUTPUT_FORMAT OUTPUT_CURVES /* output viewpoint */ SET_COORD( from, 6, 60, 35 ) ; SET_COORD( at, 0.0, 8.0, -15.0 ) ; SET_COORD( up, 0.0, 0.0, 1.0 ) ; lib_output_viewpoint( &from, &at, &up, 45.0, 0.5, 512, 512 ) ; /* output background color - UNC sky blue */ SET_COORD( back_color, 0.078, 0.361, 0.753 ) ; lib_output_background_color( &back_color ) ; /* output light sources */ SET_COORD( light, -100.0, -100.0, 100.0 ) ; lib_output_light( &light ) ; /* set up sphere color */ SET_COORD( obj_color, 1.0, 0.8, 0.4 ) ; lib_output_color( &obj_color, 0.8, 0.2, 100.0, 0.0, 1.0 ) ; for ( i = -steps*2/3; i <= steps/3 ; ++i ) { angle = 3.0 * 6.0 * M_PI * (double)i / (double)steps ; r = k * exp( a * angle ) ; sphere.x = r * sin( angle ) ; sphere.y = r * cos( angle ) ; /* alternate formula: z = alpha * angle */ sphere.z = beta * r ; sphere.w = r / gamma ; lib_output_sphere( &sphere, OUTPUT_FORMAT ) ; } } ------------------------------------------------------------------------------- FTP list update and New Software, by Eric Haines, George Kyriazis I posted my FTP site list for ray tracing related stuff, and a few people were nice enough to write and update this list. The new list is posted after this note from George Kyriazis at RPI (his site has the friendliest login I've ever seen): -------- iear.arts.rpi.edu [128.113.6.10]: There was an article in IEEE CG&A a while ago from Sandia National Labs (the guy's name was Mareda I think) that uses fourier transforms and digital filters to create wave height fields from white noise. What I have in the directory is an implementation of this algorithm and a program that raytraces it on the AT&T Pixel Machine. A list of what exists in there follows: graphics-gems: source code to Glassner's Graphics Gems book. ray-tracing-news:What else? wave: Rendering of ocean waves using fft. (Mareda, et. al.) coldith: conversion from my image format to sun rasterfiles and dithering from 32 or 24 bit -> 8 bit rasterfiles. drt: A ray-tracer from the Netherlands by Marinko Laban gk: A distributed raytracer by me. microray: DBW_uRAY by David Wecker mtv: Well, you know what this is. It probably is an old version. non-completed-OO-modeler: Something I was working on. It barely works, but I put it out there just for the fun of it. ohta: Masataka Ohta's constant time ray-tracer; with a few improvements. pxm-and-vmpxm-ray.etc: Two raytracers for the AT&T Pixel Machine. The second one uses some virtual memory code to store more objects. The VM source is included also. qrt: Well, QRT! rayshade: Rayshade 2.21 by Craig Kolb. I hope I'll have a few anonymous ftp sessions after this.. :-) -------- Corrected FTP site list for ray tracing related material: weedeater.math.yale.edu [130.132.23.17]: /pub - *Rayshade 3.0 ray tracer*, *color quantization code*, RT News, *new Utah raster toolkit*, newer FBM, *Graphics Gems code*. Craig Kolb cs.uoregon.edu [128.223.4.13]: /pub - *MTV ray tracer*, *RT News*, *RT bibliography*, other raytracers (including RayShade, QRT, VM_pRAY), SPD/NFF, OFF objects, musgrave papers, some Netlib polyhedra, Roy Hall book source code, Hershey fonts, old FBM. Mark VandeWettering hanauma.stanford.edu [36.51.0.16]: /pub/graphics/Comp.graphics - best of comp.graphics (very extensive), ray-tracers - DBW, MTV, QRT, and more. Joe Dellinger freedom.graphics.cornell.edu [128.84.247.85]: *RT News back issues, source code from Roy Hall's book "Illumination and Color in Computer Generated Imagery", SPD package, Heckbert/Haines ray tracing article bibliography, Muuss timing papers. [CURRENTLY NOT AVAILABLE] alfred.ccs.carleton.ca [134.117.1.1]: /pub/dkbtrace - *DKB ray tracer*. David Buck uunet.uu.net [192.48.96.2]: /graphics - RT News back issues (not complete), other graphics related material. iear.arts.rpi.edu [128.113.6.10]: /pub - *Kyriazis stochastic Ray Tracer*. qrt, Ohta's ray tracer, other RT's (including one for the AT&T Pixel Machine), RT News, Graphics Gems, wave ray tracing using digital filter method. George Kyriazis life.pawl.rpi.edu [128.113.10.2]: /pub/ray - *Kyriazis stochastic Ray Tracer*. George Kyriazis xanth.cs.odu.edu [128.82.8.1]: /amiga/dbw.zoo - DBW Render for the Amiga (zoo format). Tad Guy munnari.oz.au [128.250.1.21]: */pub/graphics/vort.tar.Z - CSG and algebraic surface ray tracer*, /pub - DBW, pbmplus. David Hook cs.utah.edu [128.110.4.21]: /pub - *Utah raster toolkit*. Spencer Thomas gatekeeper.dec.com [16.1.0.2]: /pub/DEC/off.tar.Z - *OFF objects*, /pub/misc/graf-bib - *graphics bibliographies (incomplete)*. Randi Rost abcfd20.larc.nasa.gov [128.155.23.64]: /amiga - DBW, /usenet/comp.{sources|binaries}.amiga/volume90/applications - DKBTrace 2.01. Tad Guy expo.lcs.mit.edu [18.30.0.212]: contrib - *pbm.tar.Z portable bitmap package*, *poskbitmaptars bitmap collection*, *Raveling Img*, xloadimage. Jef Poskanzer venera.isi.edu [128.9.0.32]: */pub/Img.tar.z and img.tar.z - some image manipulation*, /pub/images - RGB separation photos. Paul Raveling ftp.ee.lbl.gov [128.3.254.68]: *pbmplus.tar.Z*. ucsd.edu [128.54.16.1]: /graphics - utah rle toolkit, pbmplus, fbm, databases, MTV, DBW and other ray tracers, world map, other stuff. Not updated much recently. okeeffe.berkeley.edu [128.32.130.3]: /pub - TIFF software and pics. Sam Leffler irisa.fr [131.254.2.3]: */iPSC2/VM_pRAY ray tracer*, /NFF - many non-SPD NFF format scenes. Didier Badouel surya.waterloo.edu [129.97.129.72]: /graphics - FBM, ray tracers vega.hut.fi [128.214.3.82]: /graphics - RTN archive, ray tracers (MTV, QRT, others), NFF, some models netlib automatic mail replier: UUCP - research!netlib, Internet - netlib@ornl.gov. *SPD package*, *polyhedra databases*. Send one line message "send index" for more info. UUCP archive: avatar - RT News back issues. For details, write Kory Hamzeh ======== USENET cullings follow =============================================== [deleted from USENET, since you've probably seen them. Actually, I've added some anecdotes, some comments, etc etc, so feel free to FTP the full issue from one of the sites above (the issue is called RTNv3n4) sometime after October 5th. -EAH]