Main Page |
Satori |
Tutorials Page |
Author |
So Many Browsers, So Little Bandwidth
Web designers are getting very excited about the emergence of Scalable Vector Graphics (SVG).
This non-proprietary browser and platform independent standard allows animation, transparency, display of any font, type on a curve, scalable zooms and all kinds of sexy stuff. Because the vectors are coded as text objects within an XML document, the file sizes are tiny, and are carried down the pipe at high speed. Adobe are first out of the traps with SVG product, their Live Motion program outputs animations and graphics in SVG format. Jasc Software, who make the venerable Paint Shop Pro, also have a downloadable beta of Trajectory Pro, an SVG authoring program, on their website.It's early and still rather messy days as far as the Document Type Definition (DTD) is concerned, but industry heavyweights like IBM, Hewlett Packard, Microsoft, Adobe and Corel have put their shoulders behind the SVG initiative. Mozilla (Netscape v 6.0) will provide browser side SVG support. When it all comes together, designers will be able to prepare one document that is suitable for both print AND the web. Animators will only need produce one version of a scene, and it will play out on TV as well as on the web. The web is a means of delivering data, much of which is in graphical form, and the more fluid and dynamic that data remains up until the very moment of delivery, the more efficiently the web will function. It is for this reason that vectors are being called upon in the new web standard. Macromedia Flash is another example of this type of image technology.
The pixelated Low-Res zoom view (Left), and Satori's High-Res view (Right).
Zooming still further, into the dot of the letter"I" of the word "domestic".
This dot was painted with a one pixel brush, and yet it is still not showing any blockiness. Here's where vectors start to get a bit mind-blowing.
TOP
So Many Dinosaurs, So Little RAM
The efficiency of vectors is being recognised by some of the big hitters in 3D Animation software.
Up until now, any 3D object created in programs such as Avid Softimage, Alias/Wavefront Maya or Kinetix/Discreet 3D Studio Max, would need to have bitmaps of textures slapped on top of the underlying (vector) polygon or Nurbs models before the scene can be rendered visible. From the lowliest grain of sand to the most complicated creased dinosaur's skin, every object in a scene must have an accompanying bitmap image to describe the surface colours as well as a bumpmap image to describe the texture. These elements, along with other specialist maps controlling shininess and other surface light qualities constitute one hell of a lot of pixels, each of which must be computed by the rendering engine. This volume of data applied to the underlying structure can become more complicated by camera moves within a scene. A zoom for example, will necessitate swapping bitmaps for different views. A bitmap that works in the distance must be substituted with another bitmap for a close-up, or even an extreme close-up version. This process of swapping and blending these bitmaps needs careful programming to avoid any nasty "popping" at the moment of transition. The RAM and processing overheads for a complicated camera move in a richly textured scene with lots of lighting soon become enormous. S-o-o-o many pixels.
Now step back a moment and think of replacing all those bitmaps and bumpmaps with vector paintings.
Imagine a scene from "A Bug's Life", for example. A thousand ants march towards camera through a field of swaying grass. Truck in slowly and hold on the last ant at the tail of the column. Every blade of grass and every ant (both constructed from vectors) needs its own texture maps, but this time they are rendered with vector paintings. Each blade and ant's textures could then re-scale by themselves according to their distance from camera in every frame of the move, and there would be no need for swapping and popping of bitmaps.
Result: file sizes are massively reduced, RAM requirements plummet, and rendering speeds up by orders of magnitude.
The zoom keeps going, and the brush keeps re-rendering itself. It only stops at a ratio of well over one and three quarters of a million to one, ending up as a flat colour.
Let's stop being tyrannised by legacy impediments like the pixel. The only truly necessary role for pixels at present is to display our work on output devices like monitors, but even these are doing terrible service to the images that we can produce. There are display devices such as oscilloscopes and radar which do not use pixels. Who knows if these might not make amazing progress in future?
That future is not so far away, and someone, somewhere is already designing the T-shirt for it. It will read: "Pixels are for Squares. Victory to Vectory".
©; 2000 Michael Hirsh
TOP
Main Page
Satori
Tutorials Page
Author
SITE MAP
