From: mtj@babar.asd.sgi.com (Michael Jones)
Subject: TECH: MIP-maps and Coordinate-resolution
Date: Mon, 27 Jul 1992 21:06:22 GMT
Organization: Silicon Graphics, Inc.



ON MIP-MAPS:

dstamp@watserv1.waterloo.edu (Dave Stampe-Psy+Eng) writes:

|> The mip-maps take 4x as much storage as the original texture, however.
In fact, MIP-maps only require an extra 1/3x (total is then 4/3x) storage.
It is summed-area tables that require 4x the base storage.

|> Of course, the real problem with textures is speed.

Not so. The SGI RealityEngine produces 80, 160, or 320 million
textured anti-aliased pixels per second. This is enough for 7000
textured, anti- aliased polygons at 30Hz, even at 1280x1024 resolution
-- at workstation prices. There are textured systems available from
other vendors, What's the problem with texture speed?

ON COORDINATE RESOLUTION:

hlab@milton.u.washington.edu (Jeremy Lee) and others argue for 128-bit
coordinates. The common solution in visual simulation is to use 32-bit
fp coordinates as offsets from a specified 64-bit fp origin. Then as
objects or the eyepoint moves through the database, the 64-bit fp eye
location is subtracted from each "relocatable origin" to produce a
32-bit, sp offset which is added to the object's world-space matrix.

This works fine because the dynamic range of a single frame's
coordinates do not exceed 32-bit fp limits -- at least in normal
visual simulation.

This implementation is essentially the segment+offset .vs linear
address space issue resolved in favor of segments due to the
consistent spatial locality of visual scenes and the desire for
reduced data transmission.

-- Michael Jones    mtj@sgi.com  415.390.1455  M/S 7U-550
		    Silicon Graphics, Advanced Systems Division
		    2011 N. Shoreline Blvd., Mtn. View, CA 94039-7311