Slashdot Mirror
1977 Star Wars Computer Graphics
Noryungi writes "The interestingly named 'Topless Robot' has a real trip down memory lane: how the computer graphics of the original Star Wars movie were made. The article points to this
YouTube video of a short documentary made by Larry Cuba, the original artist, that explains how he did it. In 1977."
Don't believe these lies.
The wireframe of the death star did not shoot first in the original.
http://www.3dconnexion.com/3dmouse/overview.php
The interestingly named "Topless Robot"
*click*
The space-ship consoles show CAD-drawings the ship aligning with landing pads. Also the astronauts debugging the supposedly broker communication module used graphics. Only these was faked with drafted animation cells because computer graphics wasnt advanced enough in the 1960s to this. There were only osilliscope vector graphics then. But Kubrick and advisers like Minsky were anticipating better graphics in the future.
CGI has ruined movies, they are so in your face that you can't enjoy the movie. What made the original star wars great was the animitronics for all the characters instead of jar jar binks super imposed cartoon characters.
Wow, that's nice to have the dials to manipulate 3D objects. Is there anything like that which someone can buy today?
Until about 2002 or so (about when SGI tanked), most of the high-end 3D systems supported MIDI devices as controllers. You could plug in a MIDI knob or slider box and connect it up to the joints of your character. For some reason, few people do that any more. Support for that never really caught on when 3D moved to the PC, even though MIDI devices were cheap.
The Jurassic Park guys had a small dinosaur skeleton model with sensors at the joints wired up to a MIDI interface, so they could pose the thing and the animation would follow. That sort of thing was popular around 1995-2000 because it required little retraining for stop-motion animators.
... I remember DirectX 7 quite well.
I just imagine manipulating 3d graphics with a casio pg-380 midi guitar.
"It's such a fine line between stupid and clever" -- David St. Hubbins, Spinal Tap
The reason Larry Cuba could do real-time rendering in 1976 was that he was using a vector graphics display (http://www.cca.org/vector/). In a vector display, there are no pixels. There is no video RAM. Instead, there is a list of (x y) pairs (a list of positions on the screen, each with an off/on flag). The controller simply loops through the list over and over: the (x y) are fed to digital-to-analog converters, which drive the left/right and up/down deflectors for the CRT's electron beam. The on/off flags turn the beam on and off. In other words, it's just a big oscilloscope, with the signal replaced by a list of numbers. The longer the list, the more time it takes to traverse it and draw it, the lower the refresh rate, and the greater the flicker.
If you stick to black and white, you don't need a CRT mask to separately illuminate the red, green and blue phosphor dots. Without this mask, you can get some very sharp images.
If Cuba were using pixels instead, he would have needed megabytes to hold an image. I doubt anyone could afford a megabyte. Moreover, I doubt that in 1976 the electronics was fast enough to even read an image's bytes and turn it into a CRT signal. And that's just displaying the image on the screen. To create the image in the first place, he would have needed, for each line segment, to fill in all the pixels from endpoint to endpoint. There's no way he could have filled that many pixels in real time. But with a vector display, filling is done by the movement of the electron beam, and costs you zero computation.
Alejo
The first digital computer I programmed was an IBM 1800 built in 1966 (and was donated to our university in 1975 where I got my hands on it) so I well know the level of computer power available when 2001 ASO was filmed. Back then analog computers were more suitable than digital computers for many real world tasks. Anyone studying computer science then was expected to be able to build an analog circuit to solve differential equations for example, that way was faster than the digital methods at the time. It would have taken quite a while to render a movie scene with the 4K that was left of the 1800's RAM after the compiler/runtime was loaded.
Now, where was I? Oh yes, Get off my lawn!
I remember seeing, hearing or reading something, a long time ago, from one of the effects guys on the Buck Rogers TV series (the Gil Gerrard one.) He was describing an effect in which they needed a 3-D wireframe model of a spaceship rotating on a computer monitor (much like you see here.)
He said that he spent a fair bit of time trying to program a computer to do it, but couldn't get it to work (not really a math or computer guy at all). In the end, he fell back on what he knew best: mechanical effects. He whipped up a wireframe model using actual wire, painted it day-glo orange, mounted it on a gimbal, and stuck the whole thing inside a hollowed-out computer monitor with the insides painted black.
Sometimes the old ways are the best ways...
The machine was a PDP-11. It was a PDP-11/45 running a one-of-a-kind graphics OS, called GRASS, the Graphics Symbiosis System written by Tom DeFanti, a professor at the University of Illinois at Chicago (then the University of Illinois at Chicago Circle). Tom's appointment then was to the Chemistry Dept.; the GRASS system was used primarily for molecular modeling. It drove an Evans & Sutherland Picture System, a giant $100,000 vector graphics engine worth five times what the PDP-11 was worth.
Larry's work pushed the system to its limits. His work was done at night, on the QT, with Tom's permission. This was done by giving Larry his own disk pack with a copy of the system on it. Larry's use of the system worked around all sorts of bugs in that relatively early version of GRASS. The film was made by pointing a (film) camera at the E&S screen, and running a macro which would render a frame, click the camera, render a frame, click the camera... While the PDP-11 system could in fact render the Death Star trench in real time, by the time you included all the little bits and frobs, the E&S took long enough to draw it that the display flickered. Hence the need to do frame-by-frame. Also, there was no frame-sync hardware in the system; the camera and display were connected only by the solenoid that tripped the camera shutter.
I played with that disk pack a year or two after the fact and it was a hoot to fly around the Death Star by hand. GRASS pioneered the interactive control of complex graphics, so all the position (and other) variables could trivially be tied to dials, etc. I was discouraged by one thing: the final version of the run had apparently been deleted from the disk. The only version I could find had the big "dish" directly on the equator of the Death Star, not at 45 degrees north latitude as in the film.
Years after that, I happened to talk to Larry Cuba by phone about something else, and asked him about that. He said the version I saw WAS the final version. Years after that, when I went to my "farewell to Star Wars viewing of Star Wars", I saw he was right. The plans shown to the rebels show the dish on the equator. Obviously the plans were fake. Those rebels were all dead men.
I have the console from the Lucasfilm VAX 780. Just the top part with a few switches and lights, and a key lock, on display on the wall in my office. I removed it before Pixar (which had spun off from Lucasfilm) threw the VAX away. Apparently this is the machine used for the Genesis Effect (Star Trek) and perhaps some later Star Wars effects shot using the Evans and Sutherland Picture System 2 or 3. It would have been purchased in 1981 or later.
Bruce Perens.