From: dstamp@watserv1.uwaterloo.ca (Dave Stampe-Psy+Eng) Subject: Re: TECH: world description Date: Mon, 17 Aug 1992 13:16:32 GMT Message-ID: Organization: University of Waterloo dlwood@mailbox.syr.edu (David L Wood) writes: >Well, the example given was for 128 bit coordinates. If you have 1000 >objects and each can be represented by as many as 400 bytes, that's a >lot. Typically, with pseudo-CSG representations and scaled local >object coordinates (i.e. using 8 bit coordinates for the object and >that is scaled to 32) using delta encoding possibly, the quantity, >IMHO, will be around 100 bytes tops for fairly simple objects. For >those further away, even fewer bytes are required, possibly as few as >70. (With compression and ignoring insignificant detail.) I expect the average object size could be less, using primitives. For example, a 16-point spheroid would require about 8 bytes, a cube would require 10 or so. A random 20-vertex figure would need 70 bytes (less with some types of compression). Unions of primitives (CSG) take extra time on the user's station, but are also efficient. >>On second thought isn't some sort of object class database really >>helpful here? i.e. isn't that fork in the kitchen drawer in my world >>basically the same as the one that just came flying over the wall? > >This would require careful maintenance of that object database on each >router. Does each router have the SAME object database? Each router >must agree on the unique object ID's I would imagine. Hmmm, >abstracting the object types into types like: FORK, SPOON, LASERGUN, >LASERGUN2, LASERGUN3, HAT1, HAT2, HAT3, will be an aid in reducing >bandwidth, but adds load to the router. I think this calls for some >experimenting, to see what is the best balance, between complexity of >object dataset types and router load. If the routers can handle the >storage of a huge database of complex objects, then bandwidth is more >available for animation and such, however if the router can't handle >it, the object types will have to be much much more generic than >"FORK", maybe: cylinder1, cylinder2, rectangularPrism1, etc... Even >these will require some modifying parameters, dimensions. Hmm, >thoughts? THe basic division is this: representation vs. unique ID. By "knowing" the region and cardinality (which one in the region) of an object, you have its ID as part of the position/status information. There can be many duplicate objects using the same represesntation (maybe recolored, but that's the delta definition). So we have representation ID's, regions, and some way to map unique IDs for important objects. I suggest local short IDs across low-bandwidth connections, with a mapping table at the router. -------------------------------------------------------------------------- | My life is Hardware, | | | my destiny is Software, | Dave Stampe | | my CPU is Wetware... | | | Anybody got a SDB I can borrow? | dstamp@watserv1.uwaterloo.ca | __________________________________________________________________________