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]
hutch@sdcsvax.UCSD.EDU (Jim Hutchison) (04/14/87)
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? [...] For non-amiga users/viewers, the juggler is a ~24 frame piece of animation which displays in real time. (not caculates, that takes ~24 hours, displays.) It displays in 640x480 12 bit color. <Fire hose on sprinkle> [...] > 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". [...] > 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. -- Jim Hutchison UUCP: {dcdwest,ucbvax}!sdcsvax!hutch ARPA: Hutch@sdcsvax.ucsd.edu 2049 6d61 7320 6c65 2066 6572 7270 7365 6e65 6974 676e 6920 206e 6874 7369 6120 7472 6369 656c 202c 2049 6572 7270 7365 6e65 2074 6e6f 796c 6d20 7379 6c65 2e66
upl@puff.UUCP (04/15/87)
>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. > Okay. 2 people have done this, and both have missed the point. (1) The relative complexity of the pictures generated for professional use on Crays (and Pixars) is MANY MANY orders of magnitude greater than what he is generating from his amiga program that takes an hour/frame. Also the rendering is much more subtle and complex. If you are gonna seriously do a price performance analysis, you have to time the two for the SAME results. (2) Two years for 10 minutes of film is ludicrous for film production no matter HOW you slice it. These wouldn't be as much of an issue if HE didn't bring up both subjects himself in his article, while failing to really explore them. I own an Amiga, I love my Amiga, and I am working on making it a viable low-end film tool. Any technique which takes an hour/frame however is never gonna be of use for film production. Period. Jeff Kesselman uwvax!puff!upl upl@puff.cs.wisc.edu
philip@dalcsug.UUCP (04/18/87)
>I own an Amiga, I love my Amiga, and I am working on making it a viable >low-end film tool. Any technique which takes an hour/frame however is >never gonna be of use for film production. Period. > >Jeff Kesselman >uwvax!puff!upl >upl@puff.cs.wisc.edu I agree, but the Amiga has a definite niche in the market as a low cost video machine (makes a great character generator) but has anyone been using the Amiga for film production using frame by frame ray tracing? I would think that a good 3d modeling/animation program would be a more viable approach, considering the time required for ray-tracing. Are there currently any such packages for the Amiga? The new program by Aegis (described in Amazing Computing) looks good, but is it vapourware?? Peter Philip Dalhousie University Halifax, Nova Scotia k
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.)
efo@pixar.UUCP (efo) (04/22/87)
Comparison of various graphics engines (all figures are approximate): Cray Pixar Amiga 2 Image Computer 1000 Bits/pixel 0 48 6 Number of colors 1 1,073,741,824 4,096 displayed simultaneously Number of pixels 0 8,388,608 64,000 Performance 1000 10-40 .5 (mips) Hold And Modify no no yes Base Cost $20,000,000 $80,000 $1000 FluorInert cooling yes no no --------------- Clearly, the Amiga wins hands down for mips per dollar. However, the Pixar has an edge in colors per dollar. The Cray wins on FluorInert per dollar. Any questions? - Members of the Animation R&D group, Pixar, Marin County, Calif. P.S. - The computation of "Luxo Jr" took around an hour and a half per frame computed on a CCI 6/32. This is an improvement over previous times: Andre and Wally B. took from 7 minutes to an hour on a Cray X/MP-48; the Young Sherlock Holmes effect took up to 6 and one half hours on a CCI. (Apologies to Jeff Kesselman.)
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
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
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)
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
ph@pixar.UUCP (Paul Heckbert) (04/29/87)
Wrongo. As I understand it, the story goes like this: The software
that computed Andre and Wally B. was indeed written on a CRAY-1 XMP,
but it used Sam Leffler and a big box of crayons. Through some fast
talking and just plain being nice, they managed to borrow a HAL 9000
for 100 days. The poop is: much of the rendering of the Star Trek II
Genesis Sequence was done by ray tracing. So now you know why I have a
Pixar sweatshirt.
-------------
PS:
YOU TOO can generate controvertial comp.graphics articles with the following.
Unpack, compile, and run "code pixar.code | fmt".
# to unpack, cut here and run the following through sh
# shell archive for pixar.code code.c
#
cat <<EOF14363 >pixar.code
CODE
INTRO\BODY\BODY\CONCLUSION\
%
INTRO
Wrongo. As I understand it, the story goes like this:\The software that computed MOVIE was indeed written on COMPUTER,\but it used RENDERER.
I am pretty sure that MOVIE was computed with COMPUTER.
Wrongo! I heard from SOURCE that MOVIE was made on COMPUTER.
"MOVIE" was computed on COMPUTER\(I was there when they were computing).
Wrongo. MOVIE was computed using RENDERER at PLACE.
%
BODY
Through some fast talking and just plain being nice,\they managed to borrow COMPUTER for LONGTIME.
The animation "MOVIE" was produced on COMPUTER,\and the time per frame was TIME.
Some of the frames took TIME on that machine.
If I remember correctly, the frames took about TIME.
My guess is that MOVIE was computed on COMPUTER, just like MOVIE was.
The poop is: much of the rendering of MOVIE was done by RENDERER.
%
CONCLUSION
If it makes you feel any better,\I understand that MOVIE was computed on COMPUTER with rather respectable speed.
My information comes from SOURCE.
So now you know why I have a Pixar sweatshirt.
%
MOVIE
the Star Trek II Genesis Sequence
Andre and Wally B.
the Stained Glass Man from Young Sherlock Holmes
Luxo Jr.
%
COMPUTER
a CRAY-1 XMP
10 Project Athena VAX 750's
a VAX
a VAX-11/780 (named 'dagobah' I believe)
a CCI box
Pixar Image Computers
a room full of Amigas
an IBM PC
a Radio Shack Color Computer
a HAL 9000
%
RENDERER
REYES (Renders Everything You Ever Saw)
ray tracing
the a-buffer algorithm
Sam Leffler and a big box of crayons
%
SOURCE
Tom Duff
Jim Clark
Computer Graphics World
a friend whose cousin works at COMPANY
Matthew P. Weiner
comp.graphics
%
COMPANY
Pixar
Abel Image Research
Digital Productions
Alias
%
LONGTIME
100 days
6 months
%
TIME
1-2 hours
many, many minutes
24 hours
30 seconds
100 days
I don't know how long
%
PLACE
Minneapolis
MIT
UC Berkeley
Lucasfilm
Pixar, I think
%
%
EOF14363
cat <<EOF14363 >code.c
/*
* code.c - program to generate National Enquirer headlines and other randomness
*
* Mark Leather, PIXAR
*/
#include <stdio.h>
extern long time();
extern short ran_vec[];
struct gstruct {
int items;
char *item[128];
char data;
} *group[64];
int groups;
char line[2048];
int startdata[10000];
FILE *f1;
rnd(i)
int i;
{
return((rand()&0xffff) % i);
}
search(word)
char word[];
{
int i;
for(i=0;i<groups;++i)
if(comps(word,group[i]->item[0]))return(i);
return(-1);
}
comps(word1,word2)
char word1[],word2[];
{
int i;
for(i=0;(word1[i]==word2[i]&&word1[i]!=0&&word2[i]!=0);++i);
if(word1[i]!=word2[i])return(0);
return(1);
}
alpha(a)
char a;
{
if((a>='a'&&a<='z')||(a>='A'&&a<='Z')||(a>='0'&&a<='9')||(a=='_'))return(1);
return(0);
}
init(filename)
char filename[];
{
int i;
char *pnt;
f1=fopen(filename,"r");
if(f1==NULL){printf("Bad open\n");exit();}
groups=0;
group[groups] = (struct gstruct *)(&startdata[0]);
group[groups]->items=0;
group[groups]->item[0]= &(group[groups]->data);
for(;;)
{
getline(f1,line);
if(line[0]=='%')
{
group[groups+1]=(struct gstruct *)((int)(group[groups]->item[group[groups]->items]+1) & -2);
++groups;
group[groups]->items=0;
group[groups]->item[0]= &(group[groups]->data);
getline(f1,line);
if(line[0]=='%')return(1);
}
pnt=group[groups]->item[group[groups]->items];
for(i=0;(*(pnt++)=line[i++])!=0;);
group[groups]->items += 1;
group[groups]->item[group[groups]->items] = pnt;
}
}
exec(word)
char word[];
{
char *ppnt;
char word1[64];
int g;
g=search(word);
if(g == -1)
{
printf("%s",word);
return(1);
}
ppnt=group[g]->item[1+rnd(group[g]->items - 1)];
for(;;)
{
getword(&ppnt,word1);
if(word1[0]==0)return(1);
exec(word1);
}
}
getword(ppnt,word)
char word[];
char **ppnt;
{
int i;
word[0]=0;
while((!alpha(**ppnt))&&(**ppnt!=0))
{
if(**ppnt == '\\')printf("\n");
else if(**ppnt != '|')printf("%c",**ppnt);
(*ppnt)++;
}
if(**ppnt==0)return(1);
for(i=0;alpha(**ppnt);(*ppnt)++)word[i++]= **ppnt;
word[i]=0;
}
getline(f1,line)
char line[];
FILE *f1;
{
int i;
for(i=0;(line[i]=getc(f1))!='\n';++i);
line[i]=0;
}
argerr()
{
printf("Correct usage is code (-nn) protofile\n");
exit();
}
main(argc,argv)
int argc;
char *argv[];
{
int i,st,ncount;
char filename[32];
ncount=1;
if(argc==1) argerr();
if(argc>3) argerr();
if(argc==3)
{
ncount=0;
if(argv[1][0]!='-') argerr();
for(i=1;argv[1][i]!=0;++i)ncount=ncount*10+argv[1][i]-'0';
for(i=0;argv[2][i]!=0;++i)filename[i]=argv[2][i];
}
if(argc==2)
for(i=0;argv[1][i]!=0;++i)filename[i]=argv[1][i];
st = time(0);
srand(st);
init(filename);
for(i=0;i<ncount;++i)exec("CODE");
}
EOF14363
exitupl@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!]
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
ph@pixar.UUCP (Paul Heckbert) (05/02/87)
If you had any trouble compiling or running the stochastic rumor generator
I recently posted here, try the following bug fix:
I should have quoted my shar file end-of-input tokens, i.e.
cat <<'EOF14363' >pixar.code
instead of
cat <<EOF14363 >pixar.code
As explained in sh(1), the quotes cause all input to be literal.
Without the quotes, a '\\' became '\' on line 113 of code.c,
and the first four lines of pixar.code were mangled from
CODE
INTRO\BODY\BODY\CONCLUSION\
%
INTRO
into something else.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."