beilke@puff.UUCP (04/15/87)
In article <2985@sdcsvax.UCSD.EDU>, hutch@sdcsvax.UCSD.EDU (Jim Hutchison) writes: >In article <629@puff.WISC.EDU> upl@puff.WISC.EDU (Future Unix Gurus) writes: >>Has anyone else bothered to read the article in the latest Amiga World >>written by the guy who did juggler? [...] >It displays in 640x480 12 bit color. Make that 320X400 6-bit H.A.M. The Amiga doesn't have the capability to display > 6 bit planes. ><Fire hose on sprinkle> >[...] >> and figuring the 24fps of standard film, I get a 14400 hours of >> continous calculation for a ten minute film, or about 2 YEARS of continous >> calculation!!!! > >Hmmm, my Amiga 1000 cost $1200 with 512k and an extra drive, now I could use >the new A500 but figures are shaky on it so lets continue. > >A Cray will run you a minimum greater than $120,000, that's 100 Amigas with >an *extremely* conservative estimate on the cost of Crays. What Apollo did >with 22 days (or was it 23?) of Apollo cpu on ~100 Apollos. I presume that >we will consider the staff to maintain both setups to be of equivalent cost >favoring the Amiga staff on being able to still afford beer and chinese food. Where did you get your price estimate of the Cray? I guess you weren't kidding when you said extremely conservative. Crays cost in the 7-8 figure range, not 6. Tell me the truth now, would you really rather have >> 100 amigas or just one Cray? Come on now, tell me the truth. Besides, where would you put all of them. :-) Don't get me wrong, I have an Amiga, and love it, but well, if I had access to a Cray, it would probably see a lot less use. - - - ---> Matt Beilke <--- - - - ============================================================================== | | | // ARPA: beilke@puff.wisc.edu | | // CSNET: beilke%puff.wisc.edu@csnet-relay | | \\ // AMIGA UUCP: ...!{ihnp4,hplabs,seismo,topaz,etc.}!uwvax!puff!beilke | | \// RULES!! SNAIL: 451 Witte B, Madison, WI, 53706, USA | | | ==============================================================================
ali@rocky.UUCP (04/16/87)
In article <647@puff.WISC.EDU> beilke@puff.WISC.EDU (Matthew Beilke) writes: >Make that 320X400 6-bit H.A.M. The Amiga doesn't have the capability to >display > 6 bit planes. Despite that (just to set the record straight for comp.graphics readers not familiar with the Amiga), the Amiga can display 4096 colors at once, using 6 bit planes. How many other computers that cost under $1k can display 4096 colors at once? For that matter, how many computers that cost under $10k can display 4096 colors at once? True, programming in this mode is a bit difficult, but is possible --- There are even paint programs that allow editing in 4096 colors at once. Some of the better ray-traced images out there (like Dave Wecker's "glass") use this mode so well that you get none of the "color-banding" problems that appear in most computer generated images. > Tell me the truth now, would you really rather have >> 100 amigas or just >one Cray? Come on now, tell me the truth. Besides, where would you put >all of them. :-) >Don't get me wrong, I have an Amiga, and love it, but well, if I had access >to a Cray, it would probably see a lot less use. Now, if I had access to a Cray, it would be nice, but still, so what? You could create ray traced images at a rate of one every few minutes, but you would still need your Amiga to display them, especially if you want to see all 4096 colors. Also, for personal uses (Word Processing, etc), I would still use my Amiga. And thanks to multitasking you do not need to sit and watch your Amiga grind away on ray-traced images. Besides, the Cray could not sit at my home (I don't think my house wiring could handle the electricity required for cooling!), so it would have to be somewhere remote, and how much fun is that? Of course, there is still the problem of taking 2 years to create a movie. Oh well, I guess I can't use my Amiga to create a full ray-traced movie. But, the Amiga is still a wonderful machine for desktop video and for creation of home videos/movies. Using deluxe video, for instance, it is possible to create fairly long animation sequences (15-20 minutes) within a several hours. The film isn't ray traced, but it can be put on a video tape and used effectively for class/business demos nonetheless... Ali Ozer, ali@rocky.stanford.edu
eugene@pioneer.arpa (Eugene Miya N.) (04/16/87)
This is great! All this discussion prior to our meeting. Come one come
all.
From the Rock of Ages Home for Retired Hackers:
--eugene miya
NASA Ames Research Center
eugene@ames-aurora.ARPA
"You trust the `reply' command with all those different mailers out there?"
"Send mail, avoid follow-ups. If enough, I'll summarize."
{hplabs,hao,ihnp4,decwrl,allegra,tektronix,menlo70}!ames!aurora!eugenejbm@aurora.UUCP (04/17/87)
in article <239@rocky.STANFORD.EDU>, ali@rocky.STANFORD.EDU (Ali Ozer) says: + + In article <647@puff.WISC.EDU> beilke@puff.WISC.EDU (Matthew Beilke) writes: +>Make that 320X400 6-bit H.A.M. The Amiga doesn't have the capability to +>display > 6 bit planes. + + Despite that (just to set the record straight for comp.graphics + readers not familiar with the Amiga), the Amiga can display 4096 + colors at once, using 6 bit planes. Could you elaborate a bit on how they achieve this remarkable feat? (No sarcasm intended.) With the systems I have used (a set not including the Amiga): # colors that can be displayed AT ONCE = 2 ** ( # of bit planes ) # of "distinct" colors = 2 ** ( r_DAC_bits + g_DAC_bits + b_DAC_bits ) The word distinct is quoted since rgb triples which are distinct from a programming standpoint may not be perceptually distinct. -- Jeff Mulligan (jbm@ames-aurora.arpa) NASA/Ames Research Ctr., Mail Stop 239-3, Moffet Field CA, 94035 (415) 694-5150
upl@puff.UUCP (04/17/87)
In article <662@aurora.UUCP> jbm@aurora.UUCP (Jeffrey Mulligan) writes: >in article <239@rocky.STANFORD.EDU>, ali@rocky.STANFORD.EDU (Ali Ozer) says: >+ >+ In article <647@puff.WISC.EDU> beilke@puff.WISC.EDU (Matthew Beilke) writes: >+>Make that 320X400 6-bit H.A.M. The Amiga doesn't have the capability to >+>display > 6 bit planes. >+ >+ Despite that (just to set the record straight for comp.graphics >+ readers not familiar with the Amiga), the Amiga can display 4096 >+ colors at once, using 6 bit planes. > >Could you elaborate a bit on how they achieve this remarkable feat? >(No sarcasm intended.) > >With the systems I have used (a set not including the Amiga): > ># colors that can be displayed AT ONCE = 2 ** ( # of bit planes ) > ># of "distinct" colors = 2 ** ( r_DAC_bits + g_DAC_bits + b_DAC_bits ) I can answer this one. The Amiga uses a cleaver dodge called Hold And Modify (or HAM) mode. What it does is to take the 6 bits it can have for a given pixel and devided into two fields like so: xx xxxx / \ Control Data The top 2 bits define how the bottom 4 bits are interpreted. Your four choices are: New Red Value, New Blue Value, New Green Value, or an offset in a 16 entry color table. If you use any of the first three choices, it takes the value of the previous pixel and substitutes in the new red, green, or blue value. Obviously, if these were your only choices, it would take up to 3 pixels to change from one color to another (depending on whether they share any common red, green or blue values). In order to smooth this out, you can allocate a pallete of 16 absolute colors, accessed through the foourth mode.. In any case, the pixel color generated is a 12 bit value (4096 combinations). Clever people, those Amiga developers...... Jeff Kesselman upl@puff.cs.wisc.edu
ranger@ecsvax.UUCP (Rick N. Fincher) (04/18/87)
The Amiga can get 4096 color on the screen at once in the Hold And Modify mode (HAM) by using the number associated with a pixel to represent a change in color from the pixel to its left. One of the six bits is used to flag whether the pixel is to use an offset into the color table or a relative change in color from that of the pixel on its immediaterO left. This allows a gradual shift of colors for shading, yet still allows abrupt changes from one color to another. This rather clever method of rendering colors allows smooth shading by taking advantage of the fact that in a shaded image, a pixel is very similar to the ones around it. As long as a color is either in the color table or within 5 bits of the color to the left there is no problem. Shading in the vertical direction can be done by using different color tables for each scan line. The programming gets complicated for these images and there are some limitations, but it allows some interesting effects. Rick Fincher ranger@ecsvax
ali@rocky.STANFORD.EDU (Ali Ozer) (04/18/87)
In article <662@aurora.UUCP> jbm@aurora.UUCP (Jeffrey Mulligan) writes: >in article <239@rocky.STANFORD.EDU>, ali@rocky.STANFORD.EDU (I) say: >+ Despite that (just to set the record straight for comp.graphics >+ readers not familiar with the Amiga), the Amiga can display 4096 >+ colors at once, using 6 bit planes. >Could you elaborate a bit on how they achieve this remarkable feat? >(No sarcasm intended.) >With the systems I have used (a set not including the Amiga): ># colors that can be displayed AT ONCE = 2 ** ( # of bit planes ) ># of "distinct" colors = 2 ** ( r_DAC_bits + g_DAC_bits + b_DAC_bits ) The Amiga has a palette of 4096 colors --- Thus, 4 bits for R, 4 bits for G, and 4 for B. The HAM (Hold and Modify) mode, uses 6 bit planes to display all 4096 colors on the screen at once. Six bit planes effectively give you 64 colors (2 ** 6) to choose from, so here's how they get all 4096: - You first load 16 color values (ie, 12 bit RGB values) into the low sixteen color registers. (The Amiga has 32 color registers.) Whenever you set a pixel to one of the colors 0..15, the color value from the corresponding register is used at that pixel location. This gives you a way to arbitrarily set any pixel to any one of 16 colors. Thus, 00xxxx means use color in color register xxxx. - If you use a color between 16 and 31, the system gets the color of the pixel immediately to the left of the pixel you are modifying and changes its RED component to the low order 4 bits of the "color". Thus, setting a pixel color to 01xxxx means to set the color of pixel to xxxxggggbbbb, where gggg and bbbb are the blue and green values of the previous pixel. - Using a color between 32 and 47 does the same for the GREEN component, and a color between 48 and 63 does the same for the BLUE component. Thus, if you do not make clever use of the 16 color registers, then going from one color to another can take as many as 3 pixels --- Ie, you could not represent sharp edges very nicely. BUT, amazingly enough, there are plenty of products out there that make good use of the HAM mode. You just have to "analyze" the picture and determine the best values to put in the 16 color registers available to you in this mode. For instance, DigiPaint lets you paint using 4096 colors at once. There are digitizers that digitize pictures into 4096 colors (but not in real time). A ray tracer program posted by Dave Wecker comes with a post processor that takes the "color" information generated by the ray tracer and converts it into a HAM picture. The results are stunning --- You get no "color banding" problems, for instance. (If you somehow get a chance, take a look at the picture entitled "glass." The picture appeared in PD, so anybody with an Amiga should have it...) The other modes of the Amiga are pretty straightforward and work normally --- using n bit planes to display 2**n colors chosen out of the palette of 4096. You can use upto 5 bit planes (32 color registers) in low-res modes (320 by 200 and 320 by 400) and upto 4 bit planes (16 color registers) in hi-res modes (640 by 200 and 640 by 400). (The 400 line modes are interlaced, and will flicker with "bad" choice of colors or in heavy flourescent light. I use the 640 x 400 mode with 4 colors "development" environment and with the right colors have no problem with flicker. Also you can actually expand the screen to 704 x 470 with no problems except the monitor display area.) Hope this was helpful. Ali Ozer, ali@rocky.stanford.edu ...!decwrl!rocky.stanford.edu!ali
kent@xanth.UUCP (04/18/87)
In article <662@aurora.UUCP> jbm@aurora.UUCP (Jeffrey Mulligan) writes: >in article <239@rocky.STANFORD.EDU>, ali@rocky.STANFORD.EDU (Ali Ozer) says: >+ >+ In article <647@puff.WISC.EDU> beilke@puff.WISC.EDU (Matthew Beilke) writes: >+>Make that 320X400 6-bit H.A.M. The Amiga doesn't have the capability to >+>display > 6 bit planes. >+ >+ Despite that (just to set the record straight for comp.graphics >+ readers not familiar with the Amiga), the Amiga can display 4096 >+ colors at once, using 6 bit planes. > >Could you elaborate a bit on how they achieve this remarkable feat? >(No sarcasm intended.) > >With the systems I have used (a set not including the Amiga): > ># colors that can be displayed AT ONCE = 2 ** ( # of bit planes ) > ># of "distinct" colors = 2 ** ( r_DAC_bits + g_DAC_bits + b_DAC_bits ) > >The word distinct is quoted since rgb triples which are distinct >from a programming standpoint may not be perceptually distinct. I'll take a shot at this one, I think it's neat! First, the Amiga has 4 bits per color gun, so it is capable of producing 4096 (2**(4+4+4)) colors on the color monitor. Second, the Amiga's usual mode is 1, 2, 3, 4, or 5 bits through a color look up table which translates these into any 2, 4, 8, 16, or 32 of those 4096 colors, depending upon which sets of 12 bits are loaded into the output side of the color look-up table. Third, the Amiga has the bandwith to memory to pull out and translate up to 6 bits per pixel at the monitor's display rate, so the designers took the opportunity to do something really flashy. (As an aside, in the Amiga's memory, each bit plane is stored in a separate string of bits, rather than putting the 1, 2, 3, 4, 5, or 6 bits per pixel together in the memory.) (Here comes the H.A.M - Hold And Modify) Fourth, using six bits, the Amiga in HAM mode is working with a 4 bit deep (16 color) color lookup table. So, what are the other (top) two bits for? They form a code telling what to do with the bottom 4 bits. I don't remember which is which, but it doesn't matter...the codes are 0 to 3. 0 : use the bottom four bits as the address of the color look up table, with which to pull out one of the 16 colors, and assign that color to this pixel. Remember which 12 bits came out of the color lookup table (the Hold part). 1 : use the bottom 4 bits to replace the 4 red bits in the held color, assign that color to this pixel (the Modify part). Remember the new 4 red bits and the old 8 green and blue bits (the Hold part again). 2 : use the bottom 4 bits to replace the 4 green bits in the held color, assign that color to this pixel (the Modify part). Remember the new 4 green bits and the old 8 red and blue bits (the Hold part again). 3 : use the bottom 4 bits to replace the 4 blue bits in the held color, assign that color to this pixel (the Modify part). Remember the new 4 blue bits and the old 8 red and green bits (the Hold part again). The result is that you can't get an arbitrary assortment of 4096 colors at each pixel, but, since real scenery (TV stuff) has lots of spatial coherence, with a suitable choice of the base 16 colors in the lookup table, you can get pictures of near photographic quality, with just a bit of fringing at very sharp color borders. Since it can take up to 4 pixels = 24 bits to fully specify an arbitrary color, the previous poster's no free lunch note is completely correct, and the Amiga doesn't violate it; just in the real world, most pictures are much better behaved than the worst case, and so this is a pretty efficient encoding for normal pictures. I'd brag about on how clever they were a bit more, but I liked my Amiga so much I put my IRA in Commodore stock, so I'm not an unbiased observer any more. ;-) I hope that was clear enough to help. Kent. -- The Contradictor Member HUP (Happily Unemployed Programmers) // Also // A Back at ODU to learn how to program better (after 25 years!) \\ // Happy \// Amigan! UUCP : kent@xanth.UUCP or ...{sun,cbosgd,harvard}!xanth!kent CSNET : kent@odu.csnet ARPA : kent@xanth.cs.odu.edu Voice : (804) 587-7760 USnail: P.O. Box 1559, Norfolk, Va 23501-1559 Copyright 1987 Kent Paul Dolan. How about if we keep the human All Rights Reserved. Author grants free race around long enough to see retransmission rights, recursively only. a bit more of the universe?
buchanan@utcsri.UUCP (04/18/87)
In article <239@rocky.STANFORD.EDU> ali@rocky.UUCP (Ali Ozer) writes: >still use my Amiga. And thanks to multitasking you do not need to sit and >watch your Amiga grind away on ray-traced images. Besides, the Hmmm Last starfighter ship = 250000 polygons. Amiga memory = 512000 bytes 2 bytes per polygon = 500000 bytes. ( it seems that under estimating is the name of the game.) =============== Memory available for raytracer. = 12000 bytes. I fail to see where the multitasking system will reside. I'd also like to see at least 24 bits per pixel. These opinions are mine mine! you hear. Don't blame any body else. -- John W. Buchanan Dynamic Graphics Project Computer Systems Research Institute (416) 978-6619 University of Toronto buchanan@toronto.CSNET {allegra,cornell,decvax,ihnp4,linus,utzoo}!utcsri!buchanan
farren@hoptoad.UUCP (04/19/87)
In article <662@aurora.UUCP> jbm@aurora.UUCP writes: >in article <239@rocky.STANFORD.EDU>, ali@rocky.STANFORD.EDU (Ali Ozer) says: > >+ Despite that (just to set the record straight for comp.graphics >+ readers not familiar with the Amiga), the Amiga can display 4096 >+ colors at once, using 6 bit planes. > >Could you elaborate a bit on how they achieve this remarkable feat? >(No sarcasm intended.) > There are sixteen "base" colors in a color table. The 6 bit planes are divided into two functional groups: the low-order 4 bits are used for color selection, and the high-order 2 bits are used for function selection. If the high order bits are both zero, then that pixel will be displayed in the color selected from the color table by the low-order bits (1 of 16, of course). If the high-order bits are NOT both zero, then the color of the pixel is selected by taking the color of the previously displayed pixel (usually the one directly before this pixel) and substituting the low-order 4 bits for either the R, G, or B value previously used. The color which is changed is determined by which of the high-order bits is set. The mode is called Hold and Modify (HAM), because the preceding pixel's color is held and then modified to produce the current pixel's color. The net result of this is to allow display of all 4096 possible colors on one screen, but the screen's real color resolution will depend on the exact arrangement of the colors. To go from full black to full white, for example, will require intermediate steps of, say, red and purple before the full white appears. Unless carefully managed, this can produce significant "fringing" effects. These can be minimized by careful selection of the sixteen base colors. -- ---------------- "... if the church put in half the time on covetousness Mike Farren that it does on lust, this would be a better world ..." hoptoad!farren Garrison Keillor, "Lake Wobegon Days"
ali@rocky.STANFORD.EDU (Ali Ozer) (04/19/87)
In article <4612@utcsri.UUCP> buchanan@utcsri.UUCP (John Buchanan) writes: >Hmmm Last starfighter ship = 250000 polygons. > Amiga memory = 512000 bytes > 2 bytes per polygon = 500000 bytes. ( it seems that under estimating > is the name of the game.) > =============== > Memory available for > raytracer. = 12000 bytes. > > I fail to see where the multitasking system will reside. I'd also > like to see at least 24 bits per pixel. The multitasking system resides in 256K of "kickstart" RAM (or ROM, in the Amiga 500 and Amiga 2000) which is seperate from the 512K of "user" RAM. And, besides, my Amiga has 1M of RAM, and Monday or Tuesday I plan on expanding to 2.5M, with future plans for upto 8.5 megabytes. That should be enough for one or two last starfighter ships in addition to Emacs and several other programs... But I have no plans for remaking the last starfighter on my Amiga anyway! 8-) In any case, I do agree that you cannot use the Amiga for making full length ray traced movies. But, as the "juggler" demonstrates, you can use it to make short ray traced animations. Or, using programs like "deluxe video," or the new "videoscape 3d," along with real time digitizers like "live!" and the Genlock device, you can make pretty impressive (and long) animations and movies at a small fraction of the cost required for any other methods. Ali Ozer, ali@rocky.stanford.edu ...!decwrl!rocky.stanford.edu!ali
josh@hi.uucp (Josh Siegel ) (04/19/87)
In article <4612@utcsri.UUCP> buchanan@utcsri.UUCP (John Buchanan) writes: >In article <239@rocky.STANFORD.EDU> ali@rocky.UUCP (Ali Ozer) writes: >>still use my Amiga. And thanks to multitasking you do not need to sit and >>watch your Amiga grind away on ray-traced images. Besides, the > >Hmmm Last starfighter ship = 250000 polygons. > Amiga memory = 512000 bytes > 2 bytes per polygon = 500000 bytes. ( it seems that under estimating > is the name of the game.) I think it will be far more then 2 bytes... > =============== > Memory available for > raytracer. = 12000 bytes. > > > I fail to see where the multitasking system will reside. I'd also > like to see at least 24 bits per pixel. > >John W. Buchanan Dynamic Graphics Project Gads! What are you trying to prove? That a amiga is NOT a cray? We know this! The point is that for what we pay $800.00, we have a computer that runs very nicely and can do some real number crunching. Also, lets look at DPW render system. How much does it cost? $18.00?!?!? How much does WaveFront cost? $75,000!!!! How much does a Cray cost? Oh... $5,000,000 for the cray (that uses human blood) and $5,000,000 for the room. (A generalization from a Los Alamos friend) Lets sum it up... Cray: 30 seconds Software: $75,000 for something optimised for a Cray $5,000,000 for the computer (maybe more) (with vt100) NO colors Amiga: 1 hour $18.00 for something optimised for a Amiga $1500.00 for the computer (with display) 4096 colors You may say... The cray can feed another computer to display the works of art... SO CAN THE AMIGA!!!! Lets try to keep this in perspective.... --Josh Siegel -- Josh Siegel (siegel@hc.dspo.gov) (505) 277-2497 (Home) I'm a mathematician, not a programmer!
josh@hi.uucp (Josh Siegel ) (04/19/87)
Actually... to continue this whole foolishness....
~$14,000,000 for a Cray XMP
at a $800 for a Amiga and a $800 for equipment to link them together...
thats 8750 amigas for the cost of a cray... Hmm... I'll put them
in my dorm room... Hmm.. thats a larger pet then a goldfish...
Back to the point...
at 512x512 we have a quarter mill pixels. That means that each
amiga could do.. Hmm... roughly 32 pixels (actually, 29.959314 pixels).
I bet that we could do a VERY COMPLICATED image in FAR less time then
a Cray...
You say, but it is going to cost money to get all these things comunicating
(and paying the poor dumb f*cks who set it up...) but whats the overhead
with buying a Cray....
Again... Lets keep this in perspective.... WHO THE HELL WANTS
8750 AMIGAS and HOW MANY STUDENTS CAN AFFORD A CRAY?
--Josh Siegel
--
Josh Siegel (siegel@hc.dspo.gov)
(505) 277-2497 (Home)
I'm a mathematician, not a programmer!philip@dalcsug.UUCP (04/20/87)
In article <4612@utcsri.UUCP> buchanan@utcsri.UUCP (John Buchanan) writes: >In article <239@rocky.STANFORD.EDU> ali@rocky.UUCP (Ali Ozer) writes: >>still use my Amiga. And thanks to multitasking you do not need to sit and >>watch your Amiga grind away on ray-traced images. Besides, the > >Hmmm Last starfighter ship = 250000 polygons. > Amiga memory = 512000 bytes > 2 bytes per polygon = 500000 bytes. ( it seems that under estimating > is the name of the game.) > =============== > Memory available for > raytracer. = 12000 bytes. (on standard amiga) Add maximum expansion memory available 8000000 bytes ================== memory available for raytacer. 8,012,000 bytes I think that might be *just* enough! :-) > > > I fail to see where the multitasking system will reside. I'd also Not that you would get much done if you were multitasking while ray-tracing unless of course you happen to also have a TURBO-Amiga. > like to see at least 24 bits per pixel. Can't argue with you there but then again, I would like to see 24 bits per pixel on every system I use ... yea, and 2048*2048 resolution, and .... Peter Philip Dalhousie University Halifax, Nova Scotia
papa@bacall.UUCP (Marco Papa) (04/20/87)
> in article <239@rocky.STANFORD.EDU>, ali@rocky.STANFORD.EDU (Ali Ozer) says: > + > + In article <647@puff.WISC.EDU> beilke@puff.WISC.EDU (Matthew Beilke) writes: > +>Make that 320X400 6-bit H.A.M. The Amiga doesn't have the capability to > +>display > 6 bit planes. > + > + Despite that (just to set the record straight for comp.graphics > + readers not familiar with the Amiga), the Amiga can display 4096 > + colors at once, using 6 bit planes. > Jeff Mulligan replys: > Could you elaborate a bit on how they achieve this remarkable feat? > (No sarcasm intended.) I am quoting from the Amiga Hardware Manual: "Hold and Modify Mode. In this mode you can display up to 4,096 colors on the screen at the same time. ... Hold and Modify allows very fine gradients of color or shading to be produced on the screen. ... In Hold and Modify mode, you use all 6 bitplanes. Planes 5 and 6 are used to modify the way bits from planes 1 - 4 are treated, as follows: * if the 6-5 bit combination from planes 6 and 5 for any given pixel is 00, normal color selecton procedure is followed. Thus, the bit combinations from planes 4-1, in that order of significance, are used to choose one of 16-color registers (registers 0 -15). if only 5 bit-planes are used, the data from the 6-th plane is automatically supplied with the value as 0. * if the 6-5 combination is 01, the color of the pixel immediately to the left of this pixel is duplicated and then modified. The bit combinations from planes 4 - 1 are used to replace the 4 "BLUE" bits in the corresponding color registers. * if the 6-5 bit combination is 10, [same as the previous one except that ] we replace the 4 "RED" bits. * if the 6-5 bit combination is 11, [same as the previous one except that] we replace the 4 "GREEN' bits." Note that this is not that complex to handle. There are now a variety of programs for the AMIGA that use hold and modify. Some great demos, like the 3-D ray-traced real-time juggler (see it on the cover of AmigaWorld), a "freeware" ray-tracing program by Dave Wecker, and a 4096-color paint program called Digi-View by NewTek, for example. Dave's program comes with source-code, so you can even see how it is done. Rumour has it that Jay Miner, the designer of the Amiga graphics chips, almost left out "Hold and Modify" since "nobody would use it". -- Marco -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Marco Papa 3175 S. Hoover St., Ste. 275 (213)747-8498 Los Angeles, CA 90007 USC: (213)743-3752 F E L S I N A Now working for ::::::: BIX: papa But in no way :: :: Officially representing ::::::: ...!usc-oberon!bacall!papa S O F T W A R E papa@usc-cse.usc.edu -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
ali@rocky.STANFORD.EDU (Ali Ozer) (04/20/87)
In article <72@dalcsug.UUCP> philip@dalcsug.UUCP (Peter Philip) writes: >Not that you would get much done if you were multitasking while ray-tracing >unless of course you happen to also have a TURBO-Amiga. You can simply set the priority of the ray tracer to -1 (with the "cpri" or "changetaskpri" AmigaDOS command). Then you can run Emacs or other user-interface oriented programs without any loss in performance. (Tasks of same priority run in round robin fashion while a task of higher priority will always preempt one of lower priority.) Of course, the ray-tracer will run a bit slower, but not much, as the Amiga is heavily interrupt driven. Of course with a Turbo Amiga things would go several zillion times faster. Yes indeed... Ali Ozer, ali@rocky.stanford.edu
kent@xanth.UUCP (04/20/87)
In article <4612@utcsri.UUCP> buchanan@utcsri.UUCP (John Buchanan) writes: >In article <239@rocky.STANFORD.EDU> ali@rocky.UUCP (Ali Ozer) writes: >>still use my Amiga. And thanks to multitasking you do not need to sit and >>watch your Amiga grind away on ray-traced images. Besides, the > >Hmmm Last starfighter ship = 250000 polygons. > Amiga memory = 512000 bytes > 2 bytes per polygon = 500000 bytes. ( it seems that under estimating > is the name of the game.) > =============== > Memory available for > raytracer. = 12000 bytes. > > > I fail to see where the multitasking system will reside. I'd also > like to see at least 24 bits per pixel. Whoa! The original Amiga 1000 came with 256K bytes of memory, and there was an easy add on for another 256K bytes. (There was also always a "hidden" 256K bytes where the operating system ("Kickstart") was loaded.) However, the available users memory address space included another 8M bytes of memory, making the original machine an 8.5M byte machine, not a 0.5M byte machine. Since then, Commodore has relinquished claim to another megabyte of memory (of the total 16M bytes provided by 24 bit addressing), permitting it also to be used for user expansion memory. This makes the Amiga a 9.5M byte machine from the user's point of view, today. This is a linear address space, a big improvement over the Baby Blue clones' segmented memory. There are lots of third party vendors providing add on memory units from 0.5 to 8.0 meg for the Amiga. I run a 2.5M byte system at home, and I have yet to run out of memory, even after copying a couple of the 880Kbyte floppies into ram disk to save disk access time. As to the 24 bit frame buffer, I'd like one too, and someday I expect to add one as a peripheral. There is no way I want to pay for a home computer with the memory bandwidth to support that from memory to video display, though, at the price of today's fast memory. The Amiga in HAM mode (see other articles) can display pictures with near photographic realism. More would be nice, but more would always be nice; it just takes paying for. On multitasking: this evening, for a lark, I put up 39 demos with graphics output, all on the screen, all running at once, and all obviously doing something. The windows in which they ran were overlapped, nested, a real mess, and yet the Amiga kept up. With this much junk around, moving a window was worth a 20 second pause, but this isn't a realistic way to use the machine. Practically, like the previous author, I have found myself printing one file, downloading another with kermit, unpacking a third with arc, and editing a fourth with micro-emacs, all at once. This is useful, and it does work. Since all but the arc process (which I usually run memory to memory) are I/O limited, the editing procedes at a comfortable pace, even with everything else going on. It isn't a Cray X/MP, and there is an occassional pause, but that is a small price to pay to get away from serial processing. I'm hardly disinterested; I liked the computer so much I went back and bought some of the stock. However, lack of care by publishers of Amiga reviews leave the Amiga with the reputation of being a slow, half megabyte machine. The floppy disk access is slow, but multi-megabyte memory is possible, and, with add on enough memory to dump the contents of a floppy into ram disk (a ram disk driver is standard as part of AmigaDOS), the machine is screamingly swift. For a graphics type like myself, with it's special purpose graphics coprocesser chips, the Amiga is unexcelled anywhere near it's price, and, except for the resolution/pixel depth limitations of slower memory, exceeds the performance of machines for which I paid $50,000 a decade ago. Kent. -- The Contradictor Member HUP (Happily Unemployed Programmers) // Yet // Another Back at ODU to learn how to program better (after 25 years!) \\ // Happy \// Amigan! UUCP : kent@xanth.UUCP or ...{sun,cbosgd,harvard}!xanth!kent CSNET : kent@odu.csnet ARPA : kent@xanth.cs.odu.edu Voice : (804) 587-7760 USnail: P.O. Box 1559, Norfolk, Va 23501-1559 Copyright 1987 Kent Paul Dolan. How about if we keep the human All Rights Reserved. Author grants free race around long enough to see retransmission rights, recursively only. a bit more of the universe?
scott@applix.UUCP (Scott Evernden) (04/20/87)
In article <662@aurora.UUCP> jbm@aurora.UUCP (Jeffrey Mulligan) writes: >in article <239@rocky.STANFORD.EDU>, ali@rocky.STANFORD.EDU (Ali Ozer) says: >+ >+ In article <647@puff.WISC.EDU> beilke@puff.WISC.EDU (Matthew Beilke) writes: >+>Make that 320X400 6-bit H.A.M. The Amiga doesn't have the capability to >+>display > 6 bit planes. >+ >+ Despite that (just to set the record straight for comp.graphics >+ readers not familiar with the Amiga), the Amiga can display 4096 >+ colors at once, using 6 bit planes. > >Could you elaborate a bit on how they achieve this remarkable feat? The Amiga can display 4096 colors using 6 bit planes in a mode called HAM (Hold-And-Modify) using the following trick: Each pixel is represented by a 6 bit value. If the top 2 bits are 0, then the low-order 4 bits are used as an index into a (16 entry x 12 bit wide) color lookup table supplying that pixel's color. If the top 2 bits are NOT 0, then they are 1, 2, or 3 and the low-order 4 bits are used to modify a primary color component of the preceeding (left neighbor) pixel. (i.e., MODIFY 4 bits of the 12 bit color value HELD from the last pixel). +-----------------------+ | 0 | 0 | X | X | X | X | +-----------------------+ \_____________/ \__________ 4 bit index into color lookup table; lookup table has 4 bits/primary (= 12 bits) +-----------------------+ | N | N | X | X | X | X | +-----------------------+ \_____/ \_____________/ \ \ new 4 bit primary value for (eg., RED) \ \_________ the pixel's color is the same as the \ preceeding pixel except the (eg., RED) \ 4 bit component is directly given here. \_ 01 - modify RED 10 - modify GRN 11 - modify BLU So, with this scheme, you effectively have 12 bit/pixel control, although you cannot use any 12 bit value anywhere. Consequently, HAM-mode Amiga images can tend to be a bit fuzzy in the vicinity of color edges, but if the color lookup table is designed correctly, then this problem can be minimized. DBW_Render actually computes 12 bit color values for the entire picture, and then computes a histogram of color usage in order to choose a "best" set of lookup table values to minimize this "fringing". - scott
upl@puff.WISC.EDU (Future Unix Gurus) (04/20/87)
In article <854@xanth.UUCP$ kent@xanth.UUCP (Kent Paul Dolan) writes: $In article <4612@utcsri.UUCP$ buchanan@utcsri.UUCP (John Buchanan) writes: $$In article <239@rocky.STANFORD.EDU$ ali@rocky.UUCP (Ali Ozer) writes: $$$still use my Amiga. And thanks to multitasking you do not need to sit and $$$watch your Amiga grind away on ray-traced images. Besides, the $$ $$Hmmm Last starfighter ship = 250000 polygons. $$ Amiga memory = 512000 bytes $$ 2 bytes per polygon = 500000 bytes. ( it seems that under estimating $$ is the name of the game.) $$ =============== $$ Memory available for $$ raytracer. = 12000 bytes. $$ $$ $$ I fail to see where the multitasking system will reside. I'd also $$ like to see at least 24 bits per pixel. $ $Whoa! $ $The original Amiga 1000 came with 256K bytes of memory, and there was an easy $add on for another 256K bytes. (There was also always a "hidden" 256K bytes $where the operating system ("Kickstart") was loaded.) However, the available $users memory address space included another 8M bytes of memory, making the $original machine an 8.5M byte machine, not a 0.5M byte machine. $ Sure, if you add another $500+ for the expansion box. (I have one on my machine, and love it, but buying it really hurt.) The 2000, which can be expanded internally, with no extra hardware (outside of chips) to 1 meg I considerr a base 1 meg machine. The 1000 is a base .5 meg machine since it needs major extra hardware to bring it any higher. After all, for $500 you can get a card with a couple of meg for the IBMPC - does that make it a multi-meg machine??? Or perhapse more to the point, you can buy an extra card-cage for the IBM, does that make it a base machine with twice as many slots? $Since then, Commodore has relinquished claim to another megabyte of memory (of $the total 16M bytes provided by 24 bit addressing), permitting it also to be $used for user expansion memory. This makes the Amiga a 9.5M byte machine $from the user's point of view, today. This is a linear address space, a $big improvement over the Baby Blue clones' segmented memory. But does this old reserved space autoconfig??? (This is a question, I don't know the answer.) $There are lots of third party vendors providing add on memory units from 0.5 $to 8.0 meg for the Amiga. I run a 2.5M byte system at home, and I have yet $to run out of memory, even after copying a couple of the 880Kbyte floppies $into ram disk to save disk access time. Then again, you aren't doing professional quality ray-tracing, are you??? We are talking a REAL memory intensive application here. $ $As to the 24 bit frame buffer, I'd like one too, and someday I expect to add $one as a peripheral. There is no way I want to pay for a home computer with $the memory bandwidth to support that from memory to video display, though, at $the price of today's fast memory. The Amiga in HAM mode (see other articles) $can display pictures with near photographic realism. More would be nice, but $more would always be nice; it just takes paying for. I'm in agreeement here. HAM mode is fine for me, from a micro. $ $On multitasking: this evening, for a lark, I put up 39 demos with graphics $output, all on the screen, all running at once, and all obviously doing $something. The windows in which they ran were overlapped, nested, a real $mess, and yet the Amiga kept up. With this much junk around, moving a window $was worth a 20 second pause, but this isn't a realistic way to use the $machine. Neither is ray-tracing. The point you have missed here is all your demos are custom-chip (blitter etc) intensive. Ray tracing can use almost none of the abilities of the custom chips. It is a compute-intensive application that requires tons of processor time. $ $Practically, like the previous author, I have found myself printing one file, $downloading another with kermit, unpacking a third with arc, and editing a $fourth with micro-emacs, all at once. This is useful, and it does work. $Since all but the arc process (which I usually run memory to memory) are I/O $limited, the editing procedes at a comfortable pace, even with everything $else going on. It isn't a Cray X/MP, and there is an occassional pause, $but that is a small price to pay to get away from serial processing. $ $I'm hardly disinterested; I liked the computer so much I went back and $bought some of the stock. Gambler, aren't you? If it pays off, it should pay off nicely.. if not... $However, lack of care by publishers of Amiga $reviews leave the Amiga with the reputation of being a slow, half megabyte $machine. The floppy disk access is slow, but multi-megabyte memory is $possible, and, with add on enough memory to dump the contents of a floppy into $ram disk (a ram disk driver is standard as part of AmigaDOS), the machine is $screamingly swift. For a graphics type like myself, with it's special $purpose graphics coprocesser chips, the Amiga is unexcelled anywhere near $it's price, and, except for the resolution/pixel depth limitations of slower $memory, exceeds the performance of machines for which I paid $50,000 a decade $ago. I agree with all this. Thats why I bought one (and put my self in debt for 2 years...). In the name of "perspective", the original point of all this has gotten lost. Since I started this holy-war (which IS what it has become), I feel somewhat obligated to try to bring it back there. The point was NOT that an Amiga isn't a cray, NOT that the Amiga is not a wonderful and inexpensive graphics box, BUT that ray tracing as a movie making procedure on the Amiga is silly and stupid. You WASTE everything that makes the Amiga what it is, except the screen. And if you are just gonna use it as a display tube, do your work on a bigger machine and download. No matter HOW MUCH you love your Amiga, an hour/frame just wont cut it for film work. Jeff Kesselman uhura!captain@puff.cs.wisc.edu
drco@sphinx.UUCP (04/22/87)
This is my first posting ever so please be patient.
I do not currently own an Amiga (although my next student loan may go towards
a 500 if it turns out to be as good as the propaganda says it is), but
the postings about the AmigaWorld ray-tracing article interested me, so
I bought a copy. The long and fruitless comparisons between the Amiga
and the Cray seem to have obscured a crucial point about the program
printed in the article. Namely that the ray-tracing algorithm given therein
is really, really slooooow.
As written, the program will test for each pixel and each
sphere in the universe whether the line from the observer to the
patch of the perspective plane corresponding to the pixel intersects that
sphere. With 50 - 100 spheres in the universe, and 320x400 pixels
(or however many there are) that is a whole bunch of comparisons.
If each comparison requires two floating-point multiplications and
a subtraction, no wonder the program takes so long! Some sort of pre-
processing (a simplified Z-buffering comes to mind) should be included
so that only necessary comparisons are done and !!NO!! line-sphere
intersection tests should be done on pixels that turn out to be
background. Of course your programs are going to take hours if you use
such brute force techniques as using ray-tracing to do hidden surface
elimination.
Other problems with the code are less obvious. Little things
like the fact that the color of a mirrorred sphere is irrelevent
(I want my jugglers to have golden balls to work with :-) ), and
that if a bright red light reflects off of a shiny surface the
highlights turn out white. I won't even talk about the really
unrealistic model of specular reflection.
In short, what we have so nicely listed in the article is
some really slow and sloppily conceived code. This would not bother
me except that an improved version of it is being made available for
commercial release. Please tell me that not all commercial Amiga
software is of this quality. Such a wonderful sounding machine
--
...ihnp4!gargoyle!sphinx!drco Dave Griffith
University of Chicago
Mathematics Dept. cmcmanis@sun.uucp (Chuck McManis) (04/23/87)
In article <4612@utcsri.UUCP>, buchanan@utcsri.UUCP writes:
<
< Hmmm Last starfighter ship = 250000 polygons.
< Amiga memory = 512000 bytes
< 2 bytes per polygon = 500000 bytes. ( it seems that under estimating
< is the name of the game.)
< ===============
< Memory available for
< raytracer. = 12000 bytes.
<
< I fail to see where the multitasking system will reside. I'd also
< like to see at least 24 bits per pixel.
<
< These opinions are mine mine! you hear. Don't blame any body else.
< John W. Buchanan Dynamic Graphics Project
But my Amiga has 2.5 Meg, and soon may have 4.5 meg and a 68881! So memory
is not a problem. (Oh, 2 Meg cards that plug on the side go for about $800
stuffed) Still, it isn't a Sun 3/260C but it is an order of magnitude less
expensive!
--
--Chuck McManis
uucp: {anywhere}!sun!cmcmanis BIX: cmcmanis ARPAnet: cmcmanis@sun.com
These opinions are my own and no one elses, but you knew that didn't you.ali@rocky.STANFORD.EDU (Ali Ozer) (04/23/87)
In article <1514@sphinx.uchicago.edu> Dave Griffith writes: >I do not currently own an Amiga (although my next student loan may go towards >a 500 if it turns out to be as good as the propaganda says it is) Rumor has it mail order places will have the Amiga 500 for LESS THAN $500 when it FIRST comes out. So go for it! > In short, what we have so nicely listed in the article is >some really slow and sloppily conceived code. Another Ray Tracer for the Amiga is available as Shareware from Dave Wecker (who also wrote a very popular public domain VT100 Emulator/Kermit program for the Amiga). This program apparently uses "heuristics" to reduce the computation time on the Amiga to that of on a Vax 780 --- Not bad! After the program is done, it tells you how many pixels were computed and how many were guessed... Dave's program also comes in two parts: The first part calculates 12 bit absolute colors and the second part generates Amiga standard IFF files in one of various formats and also allows you to merge different images. Dave also plans to create a ray-traced animation generator (to generate Juggler-type animation sequences). It'll be interesting to see how it compares to Eric Graham's program... (Ie, how long it takes to generate images of similar quality.) Ali Ozer, ali@rocky.stanford.edu
amamaral@elrond.UUCP (04/23/87)
In article <1514@sphinx.uchicago.edu>, drco@sphinx.uchicago.edu (david lee griffith) writes: > This is my first posting ever so please be patient. > > As written, the program will test for each pixel and each > sphere in the universe whether the line from the observer to the > patch of the perspective plane corresponding to the pixel intersects that > sphere. With 50 - 100 spheres in the universe, and 320x400 pixels > (or however many there are) that is a whole bunch of comparisons. > If each comparison requires two floating-point multiplications and > a subtraction, no wonder the program takes so long! Yes! It may be slow, but it's so very elegent and simple to program and maintain that way. That's one of the big reasons raytracing is SO attractive in the first place! Most "conventional" graphics packages that do hidden surface elimination are HORRENDOUS pieces of code with all sorts of special case tests and bounds and such and usually can be broken in several ways. I'll just about guarantee that my ray tracer that will render a correct picture 99.999% of the time, and look as good or better than just about ANY "conventional" renderer, AND do it with easily 1/10 to 1/50 of the code. > Some sort of pre- > processing (a simplified Z-buffering comes to mind) should be included > so that only necessary comparisons are done and !!NO!! line-sphere > intersection tests should be done on pixels that turn out to be > background. Of course your programs are going to take hours if you use > such brute force techniques as using ray-tracing to do hidden surface > elimination. Z buffering is great if you only generate a ray tree one generation deep, but if you do you shouldn't be doing ray tracing because you would be ignoring most of the benefits of the technique. As soon as you start generating reflection and refraction rays you have to regenerate your Z buffer from a new perspective, or more likely just forget it. This means that you've got code around that tests what to do depending on how old the ray it is, and the Z buffering adds another level of complexity that doesn't add at all to the picture quality. There are better ways of doing these kind of things in a ray tracer, oct-trees for one, but they add incredibly to the complexity of the program. Also, in your last sentence you basically state that "ray tracing will take a long time to do if you use ray tracing techniques". I agree with that. If you want ray tracing, use ray tracing. If you want fast use something else. Besides, slow is relative... > Other problems with the code are less obvious. Little things > like the fact that the color of a mirrorred sphere is irrelevent > (I want my jugglers to have golden balls to work with :-) ), and > that if a bright red light reflects off of a shiny surface the > highlights turn out white. I won't even talk about the really > unrealistic model of specular reflection. Uh uh... Everything that I have read on reflection models, including some of the more advanced ones, state that the color of a purely specular reflection is the color of the LIGHT, NOT THE OBJECT! Now above you're describing apples and criticizing oranges. You say that the color of a mirrored SPHERE is irrelevent, and then talk about a colored LIGHT... Which is it? If the object is green and the light is blue, the specular reflection is blue, NOT green, black, OR some subtle mixing of the two. There may be some diffuse reflection that will bias the TOTAL color of the object, but that's another story. The only problem with the highlights is that the lights are restricted to WHITE. If instead of having "for(k=0; k<3; ++k) brite[k]=1.0;" he would have used "for(k=0; k<3; ++k) brite[k]=color_of_light[k];" (assuming the variable existed, etc...) that problem would be rectified. My personal opinion is that if you have problems with the program FIX IT and submit the fixes to the net. It didn't cost more than the $3.95 that you spent for the magazine so don't complain. Mr Graham apparently spent a good deal of his personal time creating it, and was nice enough to submit it for publication so if you can't appreciate it for what it is TOUGH. GEEZ, I bet you complain when friends invite you for a free meal. :-) > In short, what we have so nicely listed in the article is > some really slow and sloppily conceived code. Have you ever tried to write a ray tracer? Try it, then criticize. You're right, it's not the best ray tracer that I've seen, but it's relatively readable and understandable. I bought the magazine at lunch and was able to find the fix above in about 5 minutes. If a couple of people type it in and make some pretty pictures GREAT. If not, it's no skin off my, or your, nose. Again, slow is relative. I believe it was Jim Kajiya, one of the foremost authorities on computer graphics and raytracing, at the last SIGGRAPH conference that said "Ray tracing is not slow, computers are slow. Some day someone will build a $99.00 zillion mflop machine and EVERYONE will be doing ray tracing in real time." I can't wait... ;-) > ...ihnp4!gargoyle!sphinx!drco Dave Griffith -- uucp: ...decvax!elrond!amamaral I would rather be a phone: (603) 885-8075 fool than a king... us mail: Calcomp/Sanders DPD (PTP2-2D01) Hudson NH 03051-0908
jon@oddhack.UUCP (04/23/87)
In article <804@elrond.CalComp.COM> amamaral@elrond.CalComp.COM (Alan Amaral) writes: >Again, slow is relative. I believe it was Jim Kajiya, one of the >foremost authorities on computer graphics and raytracing, at the last >SIGGRAPH conference that said "Ray tracing is not slow, computers >are slow. Some day someone will build a $99.00 zillion mflop machine >and EVERYONE will be doing ray tracing in real time." The reason this doesn't work is that the images we want to render are continually growing more complex in the quest for realism. One of the students here raytraced a picture containing 4e11 polygons last fall (of course, there were several levels of instantiation - we can't fit that much in memory yet). Some sort of hierarchical enclosure scheme is required to render scenes of even moderate complexity. Another way of expressing this is what I have come to call ``Jim Blinn's law of Constant Image Generation Time'': Given an individual and a computer, the amount of time the individual is willing to spend rendering an image is roughly constant. Thus, as computers get faster, images LOOK BETTER, but take just as long to make. For people who need to make large quantities of material, the time constant is ~5 min/frame. For people who want realism, it's more like 8-12 hours/frame. -- Jon Leech (jon@csvax.caltech.edu || ...seismo!cit-vax!jon) Caltech Computer Science Graphics Group __@/
dave@onfcanim.UUCP (Dave Martindale) (05/02/87)
In article <804@elrond.CalComp.COM> amamaral@elrond.CalComp.COM (Alan Amaral) writes: > >Uh uh... Everything that I have read on reflection models, including >some of the more advanced ones, state that the color of a purely >specular reflection is the color of the LIGHT, NOT THE OBJECT! Now >above you're describing apples and criticizing oranges. You say that >the color of a mirrored SPHERE is irrelevent, and then talk about a >colored LIGHT... Which is it? If the object is green and the light >is blue, the specular reflection is blue, NOT green, black, OR some >subtle mixing of the two. There may be some diffuse reflection >that will bias the TOTAL color of the object, but that's another story. For plastic this is true - the colour of the object is produced by pigment within a carrier which is more-or-less white. So light scattered diffusely is the light source colour filtered by the pigment, but specular reflections off the surface are purely the colour of the light source. However, for ojbects that obtain their colour from their atomic structure, like metals, specular reflections are coloured too. A good example is copper. This is complicated by the fact that the colour of the reflection depends on the angle of incidence of the light - spectral reflectance is a 2-parameter function (wavelength and incidence angle). And if you have non-white incident light, it isn't sufficient to just have reflectances for "red", "green" and "blue" and multiply them by the RGB components of the incident light if you want really realistic looking colours; you have to split the spectrum up into more than 3 bands and do the computation band-by-band. Shading that takes reflectance characteristics of the material into account has been discussed by Cook and Torrance in the SIGGRAPH proceedings sometime in the last few years. (Sorry, I'm moving and can't get at my copy to check this).