keithe@tekgvs.UUCP (04/13/87)
In article <629@puff.WISC.EDU> upl@puff.WISC.EDU (Future Unix Gurus) writes: > > The other statement I found particularly objectionable was his statement that > "we now have the ray tracing time down to an hour. Considering professional > systems running on Crays...take 2or 3 minutes, our Amiga isn't doing > badly"... > ...Using my pocket calculator, > 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!!!! > Lessee - a Cray costs (how the heck do _I_know what a Cray costs?) say 2 megabucks. So I could buy (2e6/2e3)=1e3=1000 Amigas (does $2000 for an Amiga sound reasonable - especially if I'm buying a thousand of 'em?) So then the 14400 hours becomes 14.4 hours. Not bad, maybe? keith (keep it in perspective) ericson [this line added to satisfy the lines added "feature" of news] [this line added to satisfy the lines added "feature" of news] [this line added to satisfy the lines added "feature" of news] [this line added to satisfy the lines added "feature" of news]
kary@hplsdla.UUCP (04/18/87)
>>In article <629@puff.WISC.EDU> upl@puff.WISC.EDU (Future Unix Gurus) writes: >> >> The other statement I found particularly objectionable was his statement that >> "we now have the ray tracing time down to an hour. Considering professional >> systems running on Crays...take 2or 3 minutes, our Amiga isn't doing >> badly"... >> ...Using my pocket calculator, >> 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!!!! >> > / keithe@tekgvs.TEK.COM (Keith Ericson) / 10:41 am Apr 13, 1987 / > Lessee - a Cray costs (how the heck do _I_know what a Cray costs?) say 2 > megabucks. So I could buy (2e6/2e3)=1e3=1000 Amigas (does $2000 for an Amiga > sound reasonable - especially if I'm buying a thousand of 'em?) So then the > 14400 hours becomes 14.4 hours. Not bad, maybe? > > keith (keep it in perspective) ericson I'm sure it's fun to say things like this, but as long as we're keeping things in perspective, where are you going to put those 1000 Amiga's? How are you going to operate them? Communicate between them? Dan (Reality, what a concept) Kary
ma183say@sdcc3.UUCP (04/19/87)
A Cray XMP/48 costs ~$14 million. We have one at school- I can see the supercomputer building from my apartment window, the illuminated dish pointed at the heavens. The XMP/48 is a 4 processor, 8 million 64-bit word computer. It use used mainly for mathematical pipelining. Various other computers are used for support- VAX 11/750,2 11/785s, IBM 4381, 3 PDP 11's (84s,44s,24s), a Hyper Channel, and various other nets. The point is, a Cray alone is not too productive, so the overall price for a system using a Cray is a *lot* more than $14 million. (I like to think of the Cray as a math coprocessor!). It costs appoximately $2000 a minute per processor to use, or $8000/min for all processors... I'd still rather have access to the Cray than thousands of Amigas, (like where would I put them all?). John 7OHN (this is not Lee, obviously.)
scott@applix.UUCP (Scott Evernden) (04/24/87)
In article <629@puff.WISC.EDU> upl@puff.WISC.EDU (Future Unix Gurus) writes: > The other statement I found particularly objectionable was his statement that > "we now have the ray tracing time down to an hour. Considering professional > systems running on Crays...take 2or 3 minutes, our Amiga isn't doing > badly". Maybe not, but he forgets to mention that when doing animation, which > was a major thrust of his article, the time for a single frame gets multiplied > many times over, and thus time delays do as well. Using my pocket calculator, > 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!!!! Why is 1 hour of CPU time per ray-traced frame regarded as untenable for film making? The animation "Andre and Wally B." was produced on a VAX11/780, and the time per frame was 1-2 hours. It is true, frames from that film regularly contain several thousand objects. I think if you do any amount of investigating, you will find that the CG folks are quite used to tying up their machines in this fashion. An Amiga is roughly equivalent in power to an 11/750, and I know that 750s (being the most popular of VAXen) have been used to do this sort of thing, as well. Now, certainly it must be clear that DBW_Render, and the other program used to generate "Juggler" would benefit VASTLY if a 68881 was around? (V1.2 AmigaDOS and Manx C 3.4a support it, too.) The first Mandelbrot generators I saw on my Amiga would take almost 2 minutes to plot the entire set. But recently, a PD demo copy of MANDFXP would do the same set (presumeably using the same arithmetic) in about 5 seconds!! Doesn't this suggest that one could invest some effort in improving the math used and realize some radical improvements? In short, I'm completely confident that within a year's time, some enterprising folks will do exactly what has been doubted here, and that is to get a couple of Amigas, with 68881s maybe, produce some marvelous ray-traced animations, and blow away the crowds at SIGGRAPH. -scott
eugene@pioneer.arpa (Eugene Miya N.) (04/24/87)
In article <448@applix.UUCP> Scott Evernden writes: > >Why is 1 hour of CPU time per ray-traced frame regarded as untenable for film >making? > >The animation "Andre and Wally B." was produced on a VAX11/780, and the time >per frame was 1-2 hours. > >-scott Oh?! And just where did you learn this? I'm just curious, I won't try to correct you. 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!eugene
hatcher@INGRES.BERKELEY.EDU (Doug Merritt) (04/25/87)
In article <448@applix.UUCP> scott@applix.UUCP (Scott Evernden) writes: >The first Mandelbrot generators I saw on my Amiga would take almost 2 minutes >to plot the entire set. But recently, a PD demo copy of MANDFXP would do the >same set (presumeably using the same arithmetic) in about 5 seconds!! Doesn't >this suggest that one could invest some effort in improving the math used and >realize some radical improvements? What!? 5 seconds for a full Mandelbrot on an Amiga without hardware floating point is incredible! It's probably not impossible, but the issues involved in speeding it up that much go far beyond "improving the math" used (if what you mean is smarter arithmetic). It would indeed involve "improving the math" in the sense of either some very deep analysis or a very clever algorithm that does not actually compute the set in the usual ways. (Where can I get this MANDFXP???) I am inclined to think that you are simply misremembering the numbers, or that there was a trick involved. The first mandelbrot on the Amiga that I saw took about 30 minutes for low quality mode, and much more for high quality. More recently I've seen them speeded up to somewhere between 45 seconds and 3 minutes (I wasn't timing). That was Crystal Rose software; I talked to the author and he did indeed have some pretty good insights into the nature of the problem, and had come up with some heuristics for avoiding some of the arithmetic some of the time. He had originally gotten it down to about 5 minutes by very careful attention to use of integer arithmetic and by tight coding. This I found very believable from my own experiences with implementing mandelbrots. The radical improvements that you are looking for do not come as easily as you imply; obvious methods are slow. When you optimize them, you get medium speed. To make something really blindingly fast you generally need some kind of deep insight into the problem. Improving the arithmetic is necessary but not sufficient. This is as true of ray tracing as it is of mandelbrots. Doug Merritt ucbvax!ingres!hatcher
yba@athena.mit.edu (Mark H Levine) (04/25/87)
In article <448@applix.UUCP> scott@applix.UUCP (Scott Evernden) writes: > >The animation "Andre and Wally B." was produced on a VAX11/780, and the time >per frame was 1-2 hours. It is true, frames from that film regularly contain >several thousand objects. I think if you do any amount of investigating, you >will find that the CG folks are quite used to tying up their machines in this >fashion. > >An Amiga is roughly equivalent in power to an 11/750, and I know that 750s >(being the most popular of VAXen) have been used to do this sort of thing, >as well. > I think these statements are misleading. If someone who worked on the film cares to insert particulars, it will be more accurate than I can be (Sam?), but we loaned 40 or 50 Vax/750s for 30 days every night to the filmmakers, and that was just for the BACKGROUNDS of "Andre and Wally B.," which is a fairly short piece. It is probably also important to consider the system throughput, not the MPU speed, when estimating how much your computer will produce. Unless you can get 64Gb of primary memory on your Amiga. (Was it 10 Meg per frame? I don't recall). I agree that one should never underestimate the power of ingenuity and a new approach. Overestimating the power of new technology is just as dangerous.
tim@cit-vlsi.Caltech.Edu (Timothy L. Kay) (04/25/87)
In article <448@applix.UUCP> scott@applix.UUCP (Scott Evernden) writes: >Why is 1 hour of CPU time per ray-traced frame regarded as untenable for film >making? > >The animation "Andre and Wally B." was produced on a VAX11/780, and the time >per frame was 1-2 hours. It is true, frames from that film regularly contain >several thousand objects. "Andre and Wally B." were computed on a Cray XMP/48. (I was there when they were computing.) Some of the frames took many, many minutes on a machine that large. And it wasn't even ray traced. The trees in the background were computed on vaxes at MIT. I don't know how long that took. One to two hours to ray trace on an Amiga is very good. I haven't seen the demo. Is it antialiased? Tim
jg@jumbo.dec.com (Jim Gettys) (04/26/87)
>The trees in the >background were computed on vaxes at MIT. I don't know how long that >took. > At the time, Project Athena had around 10-12 Vax 11/750's which had been installed but were not yet ready for general use, so when Lucasfilm was looking for some cycles to compute the backgrounds, we figured the machines might as well see some use. If I remember correctly, the backgrounds were of order 100 Vax 11/750 days... Jim Gettys
ewhac@well.UUCP (Leo 'Bols Ewhac' Schwab) (04/26/87)
In article <448@applix.UUCP> scott@applix.UUCP (Scott Evernden) writes: >Why is 1 hour of CPU time per ray-traced frame regarded as untenable for film >making? > >The animation "Andre and Wally B." was produced on a VAX11/780, and the time >per frame was 1-2 hours. Wrongo. As I understand it, the story goes like this: The software that computed Andre and Wally B. was indeed written on a VAX-11/780 (named 'dagobah' I believe). One fine day, they fired up the software to compute one particularly messy frame. They came back 24 hours later to find that the picture was 1/3 finished. "This isn't good," thought one of the programmers, and through some fast talking and just plain being nice, they managed to borrow a Cray XMP-48 from Cray Research. Even the power of a Cray didn't create real-time response. It still needed 1-2 hours per frame. Cray said it was Pixar's fault for not vectorizing their code. Pixar now uses their own hardware for stuff. I am pretty sure that Luxo Jr. was computed with Pixar imaging systems. >An Amiga is roughly equivalent in power to an 11/750, and I know that 750s >(being the most popular of VAXen) have been used to do this sort of thing, >as well. > If it makes you feel any better, I understand that the Genesis Demo from Star Trek II: The Wrath of Mr. Rork was computed on a VAX-11/7?0 with rather respectable speed. My information comes from people I know inside Pixar. I'll see if I can't get an official response out of them. _-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_ ________ ___ Leo L. Schwab \ /___--__ The Guy in The Cape ___ ___ /\ ---##\ ihnp4!ptsfa!well!ewhac / X \_____ | __ _---)) ..or.. / /_\-- -----+==____\ // \ _ well ---\ ___ ( o---+------------------O/ \/ \ dual ----> !unicom!ewhac \ / ___ \_ (`o ) hplabs -/ ("AE-wack") ____ \___/ \_/ Recumbent Bikes: "Work FOR? I don't work FOR The _O_n_l_y Way To Fly! anybody! I'm just having fun."
tim@cit-vlsi.Caltech.Edu (Timothy L. Kay) (04/26/87)
In article <2948@well.UUCP> ewhac@well.UUCP (Leo 'Bols Ewhac' Schwab) writes: >In article <448@applix.UUCP> scott@applix.UUCP (Scott Evernden) writes: >>The animation "Andre and Wally B." was produced on a VAX11/780, and the time >>per frame was 1-2 hours. > > Wrongo. As I understand it, the story goes like this: > [deleted explanation about use of Cray] > Pixar now uses their own hardware for stuff. I am pretty sure that >Luxo Jr. was computed with Pixar imaging systems. Wrongo. It is easy to confuse. They have a renderer called REYES (Renders Everything You Ever Saw, though not ray tracing), which they run on their CCI Unix box. They also developed a renderer for the image computer which is very impressive in that it is very fast. However, it is not capable of all the special effects that REYES is. The confusing thing is that the marketing people decided to call this renderer (the one on the image computer is for sale) REYES as well. My guess is that Luxo Jr. was computed on the CCI, just like the stained- glass knight scene in Young Sherlock Holmes was. Tim
farren@hoptoad.uucp (Mike Farren) (04/27/87)
In article <2948@well.UUCP> ewhac@well.UUCP (Leo 'Bols Ewhac' Schwab) writes: > If it makes you feel any better, I understand that the Genesis Demo >from Star Trek II: The Wrath of Mr. Rork was computed on a VAX-11/7?0 with >rather respectable speed. Well, yes, probably, but Tom Duff told me that the resolution of that piece of work was only 512 X 512. Really. You can see the pixels on the edge of the mountains if you try, it's not even hard... -- ---------------- "... 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"
scott@applix.UUCP (Scott Evernden) (04/27/87)
In article <1371@ames.UUCP> eugene@pioneer.UUCP (Eugene Miya N.) writes: >In article <448@applix.UUCP> Scott Evernden writes: >> >>Why is 1 hour of CPU time per ray-traced frame regarded as untenable for film >>making? >> >>The animation "Andre and Wally B." was produced on a VAX11/780, and the time >>per frame was 1-2 hours. >> >>-scott > >Oh?! And just where did you learn this? >I'm just curious, I won't try to correct you. My source is from the current issue of "World UNIX & C", Vol. 5, No. 4, published by Springer-Verlag. The article, "Computerizing the Movies at Lucasfilm: A Little UNIX, a Lot of Brute Force", by Michael Hawley, cites the following in describing the film "Andre & Wally B.": Duration: 1.4 minutes Resolution: 512 x 488 pixels Animation controls: 809 Polygons/frame (average): 2.9 million (I got this wrong) Time to render a frame on a DEC VAX 11/780: 1-2 hours and 6-8 Mbytes -scott
rgm@utcsri.UUCP (04/27/87)
Sender:gbs@gpu.utcs.toronto.edu Distribution:world >> Lessee - a Cray costs (how the heck do _I_know what a Cray costs?) say 2 >> megabucks. So I could buy (2e6/2e3)=1e3=1000 Amigas (does $2000 for an Amiga >> sound reasonable - especially if I'm buying a thousand of 'em?) So then the >> 14400 hours becomes 14.4 hours. Not bad, maybe? >> Well.... This fine institution picked on up cheap last year from NASA-Ames for a mere $14 Million ( in funny coloured Cdn money ) They say our model goes for about $30M brand new. (X-MP/22) Oh, and did I mention the annual maintenance contract at $2M/yr ? Not cheap, but it does make nice pictures. ============================================================================ Gideon Sheps (or Cheops, as my Egyptian relatives spell it) gbs@gpu.utcs.toronto.edu /// gbs@utorgpu.bitnet/EARN/NetNorth \\\/// I don't need a disclamer 'cause nobody listens to me. \\\/ ============================================================================
cuccia@ucbarpa.Berkeley.EDU (Nick Cuccia) (04/27/87)
You're all wrong w.r.t. what/whose machine generated _Luxo, Jr._ Sure, it was done on a CCI box (actually, two), but not Pixar's -- if they even own one. The poop is: much of the rendering of _Luxo, Jr._ was done by Sam Leffler of Pixar -- the same Sam Leffler who has contributed much to the 4BSD project over the years. Sam was working on the CCI port of 4.3BSD; he also did the rendering of _Luxo, Jr._ on the two CSRG CCI boxes, okeeffe.Berkeley.EDU and manet.Berkeley.EDU. Of course, if you're one who likes to read the credits of films, then this would be no surprise, since the closing credits explicitly credit Sam and CSRG, and mention the names of the Berkeley CCI boxes. So now you know why I have a Pixar _Luxo, Jr._ sweatshirt, --Nick
bobr@zeus.UUCP (04/28/87)
In article <2058@hoptoad.uucp> farren@hoptoad.UUCP (Mike Farren) writes: >In article <2948@well.UUCP> ewhac@well.UUCP (Leo 'Bols Ewhac' Schwab) writes: >> If it makes you feel any better, I understand that the Genesis Demo >>from Star Trek II: The Wrath of Mr. Rork was computed on a VAX-11/7?0 with >>rather respectable speed. >Well, yes, probably, but Tom Duff told me that the resolution of that piece >of work was only 512 X 512. Really. You can see the pixels on the edge of >the mountains if you try, it's not even hard... Yes, but that was a desired effect. They did versions of it at higher resolution from what I understand, but the requirements of the movie were for a grainy, "computer generated" feel so they shot it at low resolution off a Barco monitor. -- Robert Reed, Tektronix CAE Systems Division, bobr@zeus.TEK
thomas%spline.uucp@utah-gr.UUCP (Spencer W. Thomas) (04/28/87)
In article <451@applix.UUCP> scott@applix.UUCP (Scott Evernden) writes: > Time to render a frame on a DEC VAX 11/780: > 1-2 hours and 6-8 Mbytes Ah, but this just is a "normalization". It does not say that the frames were actually rendered on a Vax. If he said each frame took "X" minutes of Cray time, nobody would know how long that was "really" (well, I wouldn't, anyway). =Spencer ({ihnp4,decvax}!utah-cs!thomas, thomas@cs.utah.edu)
dillon@CORY.BERKELEY.EDU (Matt Dillon) (04/28/87)
An Amiga might be nearer to a 750 in processor power, but not in IO bandwidth... that's the major difference between, say, a PC-AT and a UNIX 68020 box. Placing a 68020 in your amiga may make the processor faster than, say, that of a VAX780, but you'll never get the bandwidth the 780's VAXBI bus gives it. So, if you don't run out of memory, and don't need to do large amounts of IO..... -Matt
henry@utzoo.UUCP (Henry Spencer) (04/29/87)
> If it makes you feel any better, I understand that the Genesis Demo > from Star Trek II: The Wrath of Mr. Rork was computed on a VAX-11/7?0 with > rather respectable speed. I think Bill Reeves said it was a 750. But "respectable" is in the eye of the beholder; the sequence took weeks to compute. The flying-through-the- canyon bit wasn't originally planned. It was kludged in when they found that the fractal mountains were intersecting the flight path, since they didn't have enough time before the deadline to recompute the whole thing. -- "If you want PL/I, you know Henry Spencer @ U of Toronto Zoology where to find it." -- DMR {allegra,ihnp4,decvax,pyramid}!utzoo!henry
henry@utzoo.UUCP (Henry Spencer) (04/29/87)
> ... Tom Duff told me that the resolution of that piece [ST2 Genesis demo] > of work was only 512 X 512. Really. You can see the pixels on the edge of > the mountains if you try, it's not even hard... Note that Andre and Wally B. was shot at the same resolution. And it looks better than most of the stuff people do on n-zillion-pixel film recorders. "Work smart, not hard." -- "If you want PL/I, you know Henry Spencer @ U of Toronto Zoology where to find it." -- DMR {allegra,ihnp4,decvax,pyramid}!utzoo!henry
upl@puff.WISC.EDU (Future Unix Gurus) (04/29/87)
In article <1608@zeus.TEK.COM> bobr@zeus.UUCP (Robert Reed) writes: >In article <2058@hoptoad.uucp> farren@hoptoad.UUCP (Mike Farren) writes: >>In article <2948@well.UUCP> ewhac@well.UUCP (Leo 'Bols Ewhac' Schwab) writes: >>> If it makes you feel any better, I understand that the Genesis Demo >>>from Star Trek II: The Wrath of Mr. Rork was computed on a VAX-11/7?0 with >>>rather respectable speed. > >>Well, yes, probably, but Tom Duff told me that the resolution of that piece >>of work was only 512 X 512. Really. You can see the pixels on the edge of >>the mountains if you try, it's not even hard... > >Yes, but that was a desired effect. They did versions of it at higher >resolution from what I understand, but the requirements of the movie were >for a grainy, "computer generated" feel so they shot it at low resolution >off a Barco monitor. >-- See? Even in film production, a little cleaverness can turn a bug into a feature! :) :) :) Jeff Kesselman captain@uhura.cs.wisc.edu [The following is for the ravenous short-message-eater of rn!] . . . . . . [JC on a bicycle! I HATE using up transmission bandwidth just to make RN happy. This is DEFINATELY a non-feature!]
scott@applix.UUCP (04/29/87)
In article <8704250732.AA21568@ingres.Berkeley.EDU> hatcher@INGRES.BERKELEY.EDU.UUCP writes: >In article <448@applix.UUCP> scott@applix.UUCP (Scott Evernden) writes: >>The first Mandelbrot generators I saw on my Amiga would take almost 2 minutes >>to plot the entire set. But recently, a PD demo copy of MANDFXP would do the >>same set (presumeably using the same arithmetic) in about 5 seconds!! > >What!? 5 seconds for a full Mandelbrot on an Amiga without hardware floating >point is incredible! It's probably not impossible, but the issues involved >in speeding it up that much go far beyond "improving the math" used (if >what you mean is smarter arithmetic). It would indeed involve "improving >the math" in the sense of either some very deep analysis or a very clever >algorithm that does not actually compute the set in the usual ways. >(Where can I get this MANDFXP???) > >I am inclined to think that you are simply misremembering the numbers, You're right; I checked again, and the actual time to plot the entire set with MandFXP on a 320x200 screen is 12 seconds. I apparently got confused and was remembering the startup display which plots to approx. 1/4 of the screen's middle in about 3 seconds (nice for previewing). 12 seconds is still pretty incredible to watch... I also tried that first Mandelbrot generator (RJMical's own), and I was wrong there, too. That one took over 4 minutes. (Due to Lattice 3.02's laughably slow real math). MandFXP is a product of Bruce Dawson & Steve LaRocque of Cygnus Software. I believe they achieve these amazing speeds by using some hybrid variable- precision arithmetic. This program is a MUST for anyone into this stuff. It has nifty features like color cycling, variable resolution, does Julia set, iteration control, many zoom/location controls, 10 presets, on-line help, scrolling during calcs, a 3D mode, and more. All of this under full Intuition menu control. The Demo 3 copy I have was obtained from PeopleLink. PeopleLink has perhaps the most extensive on-line collection of PD Amiga software in existence (I'm not aware of a larger one). An enhanced version of MandFXP can be obtained for $15 from: Cygnus Software 1215 Davie St. PO Box 363 Vancouver, BC Canada, V6E 1N4 -scott P.S. And the fastest LIFE generator for the Amiga does 20 generations/sec...
jon@oddhack.UUCP (04/29/87)
In article <7978@utzoo.UUCP> henry@utzoo.UUCP (Henry Spencer) writes: >Note that Andre and Wally B. was shot at the same resolution. And it >looks better than most of the stuff people do on n-zillion-pixel film >recorders. "Work smart, not hard." True enough. Of course, when you put stuff on video tape and display it on an NTSC monitor, whether you computed at 512^2 or 4096^2 may make little difference. Sort of throws all those careful chromaticity calculations for the wonderful 1Kx1kx24 displays (or whatever) in your lab out the window, too. -- Jon Leech (jon@csvax.caltech.edu || ...seismo!cit-vax!jon) Caltech Computer Science Graphics Group __@/
spietrow@atlas.UUCP (04/29/87)
in article <2058@hoptoad.uucp>, farren@hoptoad.uucp (Mike Farren) says: > Xref: gould comp.sys.amiga:1684 comp.graphics:232 > > In article <2948@well.UUCP> ewhac@well.UUCP (Leo 'Bols Ewhac' Schwab) writes: >> If it makes you feel any better, I understand that the Genesis Demo >>from Star Trek II: The Wrath of Mr. Rork was computed on a VAX-11/7?0 with >>rather respectable speed. > > Well, yes, probably, but Tom Duff told me that the resolution of that piece > of work was only 512 X 512. Really. You can see the pixels on the edge of > the mountains if you try, it's not even hard... Even better, when that terrain was rendered, someone forgot to make sure everything on the planet was set up correctly. The first time they ran the whole demo all the way through the viewer flew THROUGH a mountain! Next time you watch the Genesis Demo, there is a part that the viewer is flown through a very narrow passageway, and then back over a wide open landscape. That's the place where the people who did the Demo patched it up. --------------------------------------------------------------------------- S. R. Pietrowicz UUCP: ...!{seismo,sun,pur-ee,brl-bmd}!gould!spietrow (NOTE: Disregard header info. Email to above path only). --------------------------------------------------------------------------- Opinions expressed here are not necessarily those of my employer. ---------------------------------------------------------------------------
lwall@sdcrdcf.UUCP (Larry Wall) (04/29/87)
In article <725@puff.WISC.EDU> upl@puff.WISC.EDU (Future Unix Gurus) writes:
...
$ Jeff Kesselman
$ captain@uhura.cs.wisc.edu
$
$ [The following is for the ravenous short-message-eater of rn!]
$ .
$ .
$ .
$ .
$ .
$ .
$ [JC on a bicycle! I HATE using up transmission bandwidth just to make RN
$ happy. This is DEFINATELY a non-feature!]
Please don't malign rn for a "bug" in inews. In fact, rn will help you get
around the inews problem if you just use the -F switch to set something other
than '>' as your line-quoting character. Inews is the delivery program that
rn uses to post news. Blaming rn for inews's problems is like blaming cp when
/usr runs out of space. No, it's worse than that. It's like blaming George
Washington for the John Walker spy ring. Rn was written and distributed long
before this "feature" was added to inews.
Note also that rn/Pnews go to some length to keep your .article file around
so even if inews screws up you don't loose all your typing. Just be sure
to rename it to something else before you try reposting.
Somewhat miffedly, or at least sniffedly, yours,
Larry Wall
{allegra,burdvax,cbosgd,hplabs,ihnp4,sdcsvax}!sdcrdcf!lwall
P.S. I know this doesn't have anything to do with Amigas, but at least I own
one, so I'm not altogether an ogre. I've been trying to correct the above
misconception by mail to the offenders, but it hasn't been working.schwartz@swatsun (Scott Schwartz) (05/01/87)
In article <7978@utzoo.UUCP>, henry@utzoo.UUCP (Henry Spencer) writes: > > ... Tom Duff told me that the resolution of that piece [ST2 Genesis demo] > > of work was only 512 X 512. Really. You can see the pixels on the edge of > > the mountains if you try, it's not even hard... > > Note that Andre and Wally B. was shot at the same resolution. And it > looks better than most of the stuff people do on n-zillion-pixel film > recorders. "Work smart, not hard." Absolutely. One of the professors here at Swarthmore is making computer animated movies for teaching geometry. His group is writing frame buffers directly to video tape. They tell me that video tape cannot record more than about 512x512 pixels (with 32 bit colors). In that case, there's no point in rendering 1K x 1X images. -- # Scott Schwartz @ Swarthmore College Computer Science Program # UUCP: ...{{seismo,ihnp4}!bpa, cbmvax!vu-vlsi, sun!liberty}!swatsun!schwartz # AT&T: (215)-328-8610 /* lab phone */
les@pixar.UUCP (Les Dittert) (05/01/87)
> > Note that Andre and Wally B. was shot at the same resolution. And it > looks better than most of the stuff people do on n-zillion-pixel film > recorders. "Work smart, not hard." Luxo was shot on the LFL laser scanner. The frames were resized to about 8 mega pixels , without doing simple pixel replication. So you won't see the pixels on film , it just gets a little 'softer'. Les Dittert , LFL
wtm@neoucom.UUCP (05/05/87)
> > > ... Tom Duff told me that the resolution of that piece [ST2 Genesis demo] > > > of work was only 512 X 512. Really. You can see the pixels on the edge of > > > the mountains if you try, it's not even hard... > > > > Note that Andre and Wally B. was shot at the same resolution. And it > > looks better than most of the stuff people do on n-zillion-pixel film > > recorders. "Work smart, not hard." Since I have a satellite dish, I was able to drop in on the video conference part of last year's SMPTE meeting. They had a lot of really nifty video stuff presented by the guys at Pixar, Industrial Light & Magic, etc. I forget exacty who did the presentation on Wally B., but he showed how they put it together. It has a lot of fancy blurring of the motion in adjacent frames to make it appear more realistic. It also has antialiasing with jaggies alternating and use of color gradations aroud the jaggies to make them less visible. Much of the computation for Wally B. was done of Vax 11/785s but they borrowed some time on a Cray to finish up, if memory serves me right. He said that rendering the blur was the most computationally instensive aspect of the animation. I'm talking about the motion blur, as opposed to removing the jaggies. The most mind-blowing video was the stained glass man from the Sherlock Holmes movie. They used 6 different texture models to build up a believable stained glass effect. Bill Mayhew Division of Basic Medical Science Northeastern Ohio Universities' College of Medicine Rootstown, OH 44272 USA phone: 216-325-2511 (wtm@noeucom.UUCP ...!cbatt!neoucom!wtm)
dave@onfcanim.UUCP (05/06/87)
In article <7978@utzoo.UUCP> henry@utzoo.UUCP (Henry Spencer) writes: >> ... Tom Duff told me that the resolution of that piece [ST2 Genesis demo] >> of work was only 512 X 512. > >Note that Andre and Wally B. was shot at the same resolution. And it >looks better than most of the stuff people do on n-zillion-pixel film >recorders. "Work smart, not hard." The difference between them is in the technology used for film recording. The ST Genesis demo was shot directly from a monitor screen, since it was *supposed* to be an image on a video screen. I believe that Andre and Wally was one of the first pieces of output from the Lucasfilm/ILM laser film recorder. To produce output for that, the images are rendered (with good antialiasing *and* motion blur) at relatively low resolution (725 x 435 for the SIGGRAPH '86 demo; I think Andre and Wally was similar) then blown up to about 3000 x 2000 by bicubic interpolation before being sent to the film recorder. The interpolation doesn't add any more information to the picture, but it does ensure that you can't seen the pixels in the final result. So, while the rendering was done at relatively low resolution to keep the cost down, the film recording was done at higher resolution to produce really clean output. (It sure helps to have a PIXAR Image Computer around to do that bicubic interpolation without waiting all day...) Also, note that the "n-zillion-pixel" film recorders really are necessary for some things. We've done some animation in IMAX format, where the film frame is about 10 times the area of 35mm (2.07 x 2.72 inches). The frames were rendered and shot at 4096 x 3072. Landsat images are even higher resolution, I think.
jcz@sas.UUCP (John Carl Zeigler) (05/19/87)
> The first Mandelbrot generators I saw on my Amiga would take almost 2 minutes > to plot the entire set. But recently, a PD demo copy of MANDFXP would do the > same set (presumeably using the same arithmetic) in about 5 seconds!! Doesn't > this suggest that one could invest some effort in improving the math used and > realize some radical improvements? If you can plot the ENTIRE set in 2 minutes . . . Well, you don't need any improvement. Isn't this the technique that Cray uses to get the XMP-3 to do inf. loops in 2 secs? :-) -- --jcz John Carl Zeigler SAS Institute Inc. Cary, NC 27511 (919) 467-8000 ...!mcnc!rti-sel!sas!jcz
cjp@vax135.UUCP (05/20/87)
> The first Mandelbrot generators I saw on my Amiga would take almost 2 minutes > to plot the entire set. But recently, a PD demo copy of MANDFXP would do the > same set (presumeably using the same arithmetic) in about 5 seconds!! Doesn't > this suggest that one could invest some effort in improving the math used and > realize some radical improvements? No. Though this may be a good suggestion, what it suggests to me is just that it takes about 5 seconds to load a precomputed image from disk. -- Charles Poirier (decvax,ucbvax,ihnp4,attmail)!vax135!cjp "The road to Hell is paved with good opinions."
agollum@ukecc.UUCP (05/25/87)
In article <1770@vax135.UUCP> cjp@vax135.UUCP (Charles Poirier) writes: >> ... But recently, a PD demo copy of MANDFXP would do the >> same set (presumably using the same arithmetic) in about 5 seconds!! Doesn't >> this suggest that one could invest some effort in improving the math used and >> realize some radical improvements? > >No. Though this may be a good suggestion, what it suggests to me is >just that it takes about 5 seconds to load a precomputed image from disk. > Only it doesn't do that--it *really* generates the starting image (of the whole set) in about 5 seconds. Now this image is about 1/3 the size of the screen (noninterlaced) and it takes slightly longer if you make the window larger. But the program's overall performance suggests that it *doesn't* use shortcuts because it's on the beginning screen--it really calculates the thing. Note also that MANDFXP lets you select resolution, # of bitplanes, interlace on/off, accuracy of the calculations (how many iterations and size of arguments), etc. all of which affect speed. But this program is undeniably incredibly fast. I haven't run it in a while, so my memory is fuzzy, but I could go home and run some benchmarks if you insist. :-) Kenneth Herron
cjp@vax135.UUCP (05/28/87)
In article <1389@ukecc.engr.uky.csnet> agollum@ukecc.UUCP (David Herron aka Admiral Gollum) writes: .In article <1770@vax135.UUCP> cjp@vax135.UUCP (Charles Poirier) writes: .>just that it takes about 5 seconds to load a precomputed image from disk. . .Only it doesn't do that--it *really* generates the starting image (of the whole .set) in about 5 seconds. Now this image is about 1/3 the size of the screen... Meaning, about 1/9 the pixel area of the screen? And (important!) how many iterations? The run time is proportional to number of pixels times number of iterations per pixel, *not* to the area of complex plane covered. .I could go home and run some benchmarks if you insist. :-) . .Kenneth Herron No, that's ok, I apologize. I'll run my own tests soon as I download it. -- Charles Poirier (decvax,ucbvax,ihnp4,attmail)!vax135!cjp "The road to Hell is paved with good opinions."