From: dlwood@mailbox.syr.edu (David L Wood) Subject: Re: TECH: My standard is better than your standard. Date: Sun, 2 Aug 92 02:25:11 EDT In article dstamp@watserv1.uwaterloo.ca (Dave Stampe-Psy+Eng) writes: >s047@sand.sics.bu.oz.au (Jeremy Lee) writes: > >>In article D.Stampe writes: >> >>>One of the basic goudelines for a virtual world is going to have to >>>be "Match the user, dammit!". Why even bother representing something that >>>the user can't see, or model tiny effects that would be swamped by friction >>>or whatever in the real world! We're NOT planning a worldwide network of >>>simulation programs, after all. So as for speed or force, it's OK to >>>set a minimum force threshold for motion (which is part of the object >>description) and allow some quantization. As for speed, same thing applies. This is very reasonable for the first generation of the VR network. >>Despite my earlier rantings, I don't see a problem with some objects >>acting wierdley towards the user. If I want to slow down flowing water >>so that it seems like hard playdough, even to me, then I should be >>allowed to do that. I maintain that each object should be aware of >>it's relations with other objects, and work from that, NOT a >>generalised world scaling. What no-one has answered yet is what >>happens when a lot of people all want to scale the world differently! >>Just keep it between objects. If we are in a VNE (virtual Networked environment) >and< if objects (some of them at least) are __owned__ by a particular user, then it would be my guess that a good way to deal with the problem of world time vs. client time, would be to change the scale of time for >that particular object's time scale< and send that new data field out to nearby (or all, if you don't follow another thread) users who care. If you define an object as time dependent, you can quite easily add a small variable that says: "This time-dependent object/system should be updated every XXXXXXXX world time units." I'm not sure how on v.earth you would describe a time dependent system abstractly enough to have a low bandwidth... But that's yet another standard that we should discuss. The point of using a "scaling" data field in the object description, is that everyone who can view that object/system won't have to re-download a copy of the system or whatever (depending on your implememtation), just update one field that it (presumably) already has stored off somewhere. >Yes, but that's Local time. Now, if you want get out of communication >with others while you diddle around running faster or slower, fine. This is cured when you assign "Owners" to objects. Just as in ANY operating system, a file has an owner. In the case of UN*X, this is the user-id of the person who "created" the file. In DOS, it is whoever is behind the keyboard (an assumed user). In a VNE, even more so than in un*x, ownership and privileges are key. >But world time is world time is world time, and you must keep the same >scale to interact with others. There's no real way you're going to be >able to do "flash" movements, except by cheating (specify goals and do >not act them out, but let the machine run them). The _interactive_ >time is what the net sees, and it has to use a constant set of units >across all machines. You want a different time frame locally, fine. >You translate it. What do you mean by "flash" movements? I want to be able to snap my fingers and be teleported to my own virtual workspace, where all objects there are my own to alter at will. >>>>>>Allow the object to decide how to scale itself to the world. How else >>>>>>am I going to put a representation of myself into the insides of a >>>>128 bit numbers, and "actual size" scaling. Accept no substitutions! I worked out on paper some ideas on bit size and actual real-world sizes. If you have a 32 bit system, and each unit (00000000000000000000000000000001) is a single millimeter (mm) large, then you can map out a world to milimeter accuracy for more than 4,000 kilometers. BTW- the light side of the moon is about 4,000 kilometers in circumference (if memory serves). The only objects that may require larger accuracy are the archaic things.. called... (recalling the name :-) ) text sheets: which can be represented as an image projected onto a polygon. The milimeter constraint is reasonable for today's machines and computing power, if a message router is involved, then it makes (size projected onto horizon significance, we need a term for that) a significant factor in reducing bandwidth and computing time. Each of the milimeter points in virtual space is a >Control< point, allowing for curves and projections, and apparent higher resolution devices. For most objects around us in the real world can be modelled with good enough results to be handled by 32 bit coordinates. With a message router, however, restricting coordinates to 32 bit for inter router communication (call it a >domain<) might be confusing if you tried to connect to routers together, which is why I suggest that each router have a domain that is also described by a 128 bit number. In fact, each coordinate withing the router's domain could be described by a 128-bit number, but the router ignores the first 196 bits (12 bytes), and doesn't pass the entire 128 bit coordinates to objects communicating with each other in the same domain. Other domains will have unique 128 bit "starting" coordinates, and could have larger or smaller coordinate sizes within the domain, so long as it doesn't overlap any other part of the "universe" coordinates (128bit). >Of course you use the world scale! You just adjust your own height in >that environment. If you _really_ want to know how long your arm is, >fine. But it makes no difference to others watching you from the same >area. Inter-area is the only case that this comes up at all. It's a >case of scale down to the net, then others scale bck on their end. > >>Please remember that tranlating between local-scale units and >>world-scale units, as you suggest, will require extra computation for >>every spatial operation done. In terms of transmitting this new information to others around you, be it through a message router, or a cacophonous object shouting match setup, you should >>abstract<< that information into something that takes up less bandwidth that retransmitting your entire object dataset over the virtual network. A few simple abstractions to most geometry "transformations" are: translate (i.e. teleport, jump, hop, blip,...), rotate (spin, turn,...), and scale (shrink, expand). If you can send a message like: 'Object: User_John_Q_Public Scale: XXX / YYY'. (or however you choose to define a means of transmitting scaling values) so that each machine that >cares< whether or not you are now Zeus, King of Gods in your fortitude, can perform the scaling for itself, it's part of the net, it knew what it was jumping into :-). Some restrictions would have to be placed on the functions so that, for example you can eliminate transforms that might crash a machine by division by zero or something equally inane. A message router could filter out those >meaningless< messages and inform the user that sent it that his/her s/w is acting up, and don't do it again. >>>This type of scaling has to take place anyway. Overconcern with things not >>>representable to the user will not add to the VR experience, but will >>>result in a slow system. >>I don't see how maintaining a fixed overall scale, within which >>individual objects are free to alter their own size/geometry, can result >>in a slower system, compared with a scheme in which everything alters >>when you want to change the world scale. And, as said before, multiple >>users will begin to conflict over the world scaling. > >The idea behind scaling is to prevent the sending of 128-bit numbers >over limited bandwidth connections. But Bernie and I are looking at a >protocal split that could prevent this anyway-- using local scales and >global, depending on your bandwidth. If you have low BW, you talk >thru a machine with higher BW, which converts for you. If you describe the world as a series of DOMAINS which are large enough to contain the north american continent (and then some since it's Three D!) then you can "chop" off the first 12 bytes, since within the domain, there will be no change in those 12 bytes for objects that are visible to each other, interacting w/ each other and such. A milimeter is pretty small! Especially in a 3d environment, if you made a point of light at every vertex of a cubic milimeter that could fill up the room you're in right now, I doubt you would be able to see across the furthest distance to the furthest wall. Now imagine 4,000 km of that. Here's the math: 2^32=4,294,967,269 Each "unit" is a milimeter 2^32 / 1000 = meters = 4,294,967.269 meters each kilometer is 1000 meters 2^32 / 1000 / 1000 = milimeters = 4,294.967269 Kilometers! If a milimeter isn't enough for those of you who want to model tiny objects, if you take one unit in a 32 bit coordinate system to be 1/10 of a milimeter then you still have 429.496 KILOMETERS to deal with. That's a LOT of bandwidth if you want to be passing messages between users (or objects :p ) in a "raw" mode. This is why I support a message router that defines a particular domain with lower size coordinates. Keep in mind that the system uses 3 of these coordinates: x,y,&z. 32 bit= 4 bytes * 3 = 12 bytes. This is still less than the size of a _single_ 128 bit coordinate (16bytes). The size of the WORLD coordinate >could< be undefined. No upper limit could be set. This is possible, and might allow for some really interesting errors when someone gets line noise :-). Each domain could define the scaling between its "units" and the metric system. (metric system is implied. if ANYONE objects I'll mail you my worst poetry, all 20 pages, it challenges Vogon poetry in listenability.) >-------------------------------------------------------------------------- >| 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 | >__________________________________________________________________________ Dave Stampe- What is an SDB, and I'll let you know. :-) -- +-----------------------------+-----------------------------------------+ | dlwood@mailbox.syr.edu | drive on a parkway, park on a driveway | | Cybernaut, with a thought. | Choosy netters choose GIF. | +-----------------------------+-----------------------------------------+