c05_ta06@jhunix.HCF.JHU.EDU (Ta06) (09/19/89)
Out of curiosity, does anyone know if there's a PD program available somewhere
which can convert a GIF format file to a straight binary file?
--
"The workers ceased to be afraid of the bosses. It's as if they suddenly
threw off their chains." -- a Soviet journalist, about the Donruss coal strike
Kenneth Arromdee (UUCP: ....!jhunix!ins_akaa; BITNET: g49i0188@jhuvm;
INTERNET: arromdee@crabcake.cs.jhu.edu)brian@ccssrv.UUCP (Brian Lantz) (11/30/89)
The transformation matrix: | cos(a) -sin(b) 0 | | sin(a) cos(b) 0 | a != b | 0 0 1 | has me mystified. In empirical tests with lines, it rotates through a different angle depending on the slope of the line. I can see that that property should be expected after having it pushed in my face, but I still don't have an intuitive grasp of the full function of this transform. Can it be constructed as the product of the basic translate, scale, and rotate transforms? How can one summerize its characteristics? All answers will be appreciated. Brian
josh@cditi.UUCP (Josh Muskovitz) (12/02/89)
In article <871@ccssrv.UUCP>, brian@ccssrv.UUCP (Brian Lantz) writes: > > The transformation matrix: > > | cos(a) -sin(b) 0 | > | sin(a) cos(b) 0 | a != b > | 0 0 1 | > > has me mystified. [text deleted] > Brian I'm not sure, but it looks as if this transform compensates for aspect ratio. Anyone else? josh@uunet!cditi
bruceh@brushwud.sgi.com (Bruce R. Holloway) (12/02/89)
In article <871@ccssrv.UUCP>, brian@ccssrv.UUCP (Brian Lantz) writes: > > The transformation matrix: > > | cos(a) -sin(b) 0 | > | sin(a) cos(b) 0 | a != b > | 0 0 1 | > > has me mystified. In empirical tests with lines, it rotates through > a different angle depending on the slope of the line. I can see that > that property should be expected after having it pushed in my face, > but I still don't have an intuitive grasp of the full function of > this transform. Can it be constructed as the product of the basic > translate, scale, and rotate transforms? How can one summerize > its characteristics? All answers will be appreciated. For what it's worth, the matrix can be factored as | cos(a) -sin(a) 0| | 1 sin(a)cos(b) - sin(b)cos(a) 0 | = | sin(a) cos(a) 0| * | 0 sin(a)sin(b) + cos(a)cos(b) 0 | | 0 0 1| | 0 0 1 | | cos(a) -sin(a) 0| | 1 sin(a - b) 0 | = | sin(a) cos(a) 0| * | 0 cos(a - b) 0 | | 0 0 1| | 0 0 1 | | cos(a) -sin(a) 0| | 1 tan(a - b) 0 | | 1 0 0 | = | sin(a) cos(a) 0| * | 0 1 0 | * | 0 cos(a - b) 0 |, | 0 0 1| | 0 0 1 | | 0 0 1 | so it is the product of a rotation by angle a, a shear which depends on (a - b), and a minification of y which depends on (a - b). Thus, there is no translation or uniform scaling.
foo@erfordia.rice.edu (Mark Hall) (01/17/91)
In article <5427@idunno.Princeton.EDU> markv@taylor.Princeton.EDU (Mark VandeWettering) writes: )In article <79641@unix.cis.pitt.edu> kwgst@unix.cis.pitt.edu (Filip Gieszczykiewicz) writes: )> What computer architecture would be required to support )> real-time (20-30 frames/sec), 800 X 600 (VGA), ray-traced, )> animation? In a SIGGRAPH class (1985, "Image Rendering Tricks"), Turner Whitted said that one of his superiors at Bell Labs had asked him a similar question, I think the requested resolution was 512x512. Turner was using this as an example of an unresonable question. His response was "take a 512x512 array of Cray-1's and put a red, a green, and a blue light on each one, and fly overhead in a helicopter." In the class notes, he talks about other ways of doing fast animations: "LAN-imation" (using lots of machines, each doing a small part of the scene), and "chain letter animation" (sending disks to 5 friends, etc., having the results sent back to you on floppy). There was a TR from the university of Utah (TR UUCS 87-014 by John Peterson) which discussed the history of such tricks. - mark
npw@eleazar.dartmouth.edu (Nicholas Wilt) (01/17/91)
> We have 480000 pixels, each one of which has a single ray. According > to my book, the fastest sphere intersector I have is around 16 adds, > 13 multiplies, and one square root, for a total of 30 floating point > ops. Since we are not using a hierarchy, we have 6 * 30 floating > point operations, or 180 per ray, per bounce. Since we trace > rays to level k, we have 2^k * as many rays per pixel, or 180 * 2^k. > Since we wanted real time (lets assume the video rate of 30fps), > then we have > 800*600*30*180*2^k = 2,592,000,000 * 2^k floating point ops > per second. > And this doesn't even take into account shading. Or color quantization; the problem stated 256 colors. So you'd have to quantize on the fly, as well, or figure out a clever way to do it incrementally. A PC would have a heck of a time doing the real time display even if the frames and color mappings were precomputed and compressed. --Nicholas Wilt npw@eleazar.dartmouth.edu
marcc@yoyodyne.ncsa.uiuc.edu (Marc Cooper) (01/17/91)
In article <5427@idunno.Princeton.EDU> markv@taylor.Princeton.EDU (Mark VandeWettering) writes: >In article <79641@unix.cis.pitt.edu> kwgst@unix.cis.pitt.edu (Filip Gieszczykiewicz) writes: >> real-time (20-30 frames/sec), 800 X 600 (VGA), ray-traced, >> animation? >> (Assume 6-12 objects, 256 colors, etc.) > > > Anybody have a 2 TeraFlop board for a PC they want to get rid of c > cheap? > >> (Please don't just say, "cluster of 6 Cray Y-MPs" :-) > > Yeah, it will take alot more. ALOT more. Well, I actually SAW a demonstration of real time raytracing. Only spheres. Only a few objects. Looked neat! Of course, it was on a CM/2. Somehow, trying to get a CM/2 on to a PC board seems a little, well, unrealistic. (Please consider the above as a nominee for Understatement of the Year) -- Marc Cooper | "In my childhood, I WAS an imaginary playmate." marcc@ncsa.uiuc.edu | -Tom Robbins, EVEN GOWGIRLS GET THE BLUES National Center for Supercomputing Applications Disclaimer: "It's mine! All mine!" -D. Duck
zap@lysator.liu.se (Zap Andersson) (01/20/91)
npw@eleazar.dartmouth.edu (Nicholas Wilt) writes: >> We have 480000 pixels, each one of which has a single ray. According >> to my book, the fastest sphere intersector I have is around 16 adds, >> 13 multiplies, and one square root, for a total of 30 floating point >> ops. Since we are not using a hierarchy, we have 6 * 30 floating >> point operations, or 180 per ray, per bounce. Since we trace >> rays to level k, we have 2^k * as many rays per pixel, or 180 * 2^k. >> Since we wanted real time (lets assume the video rate of 30fps), >> then we have >> 800*600*30*180*2^k = 2,592,000,000 * 2^k floating point ops >> per second. >> And this doesn't even take into account shading. >Or color quantization; the problem stated 256 colors. So you'd have to >quantize on the fly, as well, or figure out a clever way to do it >incrementally. VERY true. My raytracer does Quant-on-ze-fly, and for a simple test image with a plane, a cylinder and a sphere with a LOT of pretty shading, reflects e.t.c: Well total time was 8 minutes, but when doing it in black'n'white (i.e. skipping quant code) it was a 5 minute job.... :-( >A PC would have a heck of a time doing the real time display even if the >frames and color mappings were precomputed and compressed. Ahem: Here we have total dissagrement. Have you never seen Autodesk Animator? 70 Frames/Sec best case (Ok, MAY skip a vertical blank worst case) but does a really neat job of decompressing and displaying animations in realtime! >--Nicholas Wilt > npw@eleazar.dartmouth.edu -- * * * * * * * * * * * * * * * * * * My signature is smaller than * * yours! - zap@lysator.liu.se * * * * * * * * * * * * * * * * * *