X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: fbb9d,cced09f2184fb5af X-Google-Attributes: gidfbb9d,public X-Google-ArrivalTime: 1995-02-02 16:25:14 PST Path: nntp.gmd.de!Germany.EU.net!howland.reston.ans.net!news.sprintlink.net!sashimi.wwa.com!not-for-mail From: c2a192@ugrad.cs.ubc.ca (Kazimir Kylheku) Newsgroups: rec.arts.ascii Subject: Talk: GIF conversion animations Date: 2 Feb 1995 18:25:14 -0600 Organization: Computer Science, University of B.C., Vancouver, B.C., Canada Lines: 45 Sender: boba@gagme.wwa.com Approved: boba@wwa.com Message-ID: <3grt5a$shj@gagme.wwa.com> References: <3gomis$97g@gagme.wwa.com> <3gomq0$9fb@gagme.wwa.com> <3gpg9i$a5h@gagme.wwa.com> NNTP-Posting-Host: gagme.wwa.com In article <3gpg9i$a5h@gagme.wwa.com>, Felix Lee wrote: > >Scarecrow: >> How about a GIF conversion animation? I would like to see maybe 15 >> seconds of motion video converted to ASCII animation. > >someone posted a conversion of a sequence from T2 a while ago. it >wasn't a very clean conversion, so it was pretty hard to see. The thing that started this thread was done using a program that I wrote. The 2280 frame rendering took 6 seconds of user time and 3 of system time on a 125 Mhz HP9000/735. The frames are rendered using gray-scale values; the lighting is a simple Lambert model, whereby the brightness of the surface is proportional to the cosine of the angle between its normal vector and the direction of the light. The basic modelling element is the triangle and the convex polyhedron. The transformation pipeline goes something like this: transformation of objects -> shading -> transformation of scene relative to viewer -> clipping against front/back planes -> perspective -> viewport clipping -> depthsort -> rendering/antialiasing (the latter in the pixel version only). I wrote the VT100 driver as a joke (and as a preliminary port to UNIX before I hit the Xlib) but it turned out to be pretty interesting! The driver works by using a simple C string of characters as a gray-scale lookup table. For each frame, it emits the "home cursor" escape sequence, followed by a newline-separated dump of the scanlines. The user can interactively manipulate the camera, then play the keystrokes back while redirecting the output to a file. The gzip program achieves a 30:1 compression ratio, bringing a 4.3 MB or so file down to 160K, because there is a great deal of obvious redundancy in the rendering, not to mention that it doesn't nearly use the full character set! The camera motion is a little hokey - it should really not be made interactively, but via a spline interpolation of some key camera positions for smooth motion. - Kaz