From: broehl@sunee.waterloo.edu (Bernie Roehl) Subject: Re: TECH: My standard is better than your standard. Date: Thu, 16 Jul 1992 16:55:53 GMT Message-ID: Organization: University of Waterloo In article <1992Jul15.233601.6824@u.washington.edu> bobp@hal.com (Bob Pendelton) writes: [a lot of excellent observations; I won't respond to all of them, just the ones that catch my eye] >Just think of numbers as a string of bytes with the binary point clear >over to the left. The smallest number you can represent it 0 and the >largest is just epsilon short of 1. This is only slightly different from using variable-length integers; in one case, the decimal point is at the left and the other it's at the right. (Oh, no -- left-handed and right-handed decimal systems!) >You can even do tricks like pack 10 bits each of x, y, and z, or r, g, >and b into each 32 bit word. You can use the extra 2 bits to tell you >that this is the first word in a triple, the Nth word, or the last word. The NAPLPS system uses a protocol like this; it's pretty clever, since you send the most significant bits first and the station just ignores the trailing bytes it doesn't need. >> How do >> we subdivide space into more manageable chunks (to avoid having to keep >> the entire universe's database in memory on every machine)? >Oct-trees look good. Well, perhaps; but they're not terribly efficient. (I'll see I can get Dave (Stampe) to post his thoughts on this). >> How do we define connections between areas? >> How do we pass from one "world" to another? >Aren't these the same question? Maybe. I'm not sure... depends on whether 'worlds' and 'areas' are the same thing or not. >Well, to get grossly metaphysical, to me god is the universe. So, >basic transport, security mechanisms, and enforcement of "natural" >laws would be all I'd allow in a god. Right, but to do those things requires that god be omnipresent (i.e. to enforce natural laws, god must theoretically take part in every object-object interaction). That may be a potential bottlneck. >This means that if the god dies then the objects can no longer >communicate with each other and they are effectively alone. I'd guess >the universe would just sort of fade away... I have no problem with this; little "mini-Ragnaroks" (or "mini-Kali Yugas") are inevitable even without a god (they're just the "object fading away" metaphor, seen from the object's point of view; when your network connection goes down, I see you fade away and you see the universe fade away). >Imagine a library world. [...] >Only objects with a high enough security level that are members of the right >classes can access restricted data. >It would make sense that the god of that world would filter messages >so that objects that you can't access can't even be seen by you. I suspect that this sort of thing is best handled by the object itself. If I create a virtual book, it's up to me (the creator and proprietor of the book's contents) to decide who should read it. (If I sell the book, I sell control of its attributes and behaviour as well). If an object is to be invisible to certain other objects, it simply doesn't acknowledge messages from that object (including messages like "what do you look like" or "what is your location"). God should have nothing to do with it; god is a security hole. >Think about a world where you can't see or interact with thing more >that a certain distance away. [...] >The world god can enforce the distance rule by simply not forwarding the >messages to objects that are too far away. While this would help conserve bandwidth, there's a problem. Let's say we decide I can't see objects more than two kilometers away, and that messages from objects beyond that are not forwarded to me. How can I see clouds? Airplanes? Distant moutains? You might say "well, 2 km isn't enough; make it ten". Fine, then how can I see the moon? The sun? And in some ways, 2 km is too much; if I have to keep track of every object in a 2 km radius, my poor little VR station is going to melt. I think distance is perhaps one of the criteria for whose messages I get, but it shouldn't be the only one. Perhaps size over distance, giving apparent size; anything too small and/or too far way doesn't matter. That would solve the problems of the sun, moon and clouds, aircraft, etc. However, I still have to worry about all the stuff in the office next to mine. >This all leads to the idea of a world and it's god being defined by a >message router. Yes. >Put a time stamp on each message sent by each object. That means we have to "synchronize watches" across the network; that's probably okay, but... >Process messages in time stamp order. This is tricky. Let's say at time T1 I hit a vase that's sitting on a table. I send a message to the vase, saying "I hit you at x,y,z,T1". Meanwhile, you (at time T2) pick up the vase and carry it with you out of the room; you send a message to the vase saying "I grabbed you at x,y,z,T2". Fine. Now, if you're closer (network-wise) then the vase will receive your message saying that you're picking it up. It can't process my message first, even though it has an earlier timestamp, because my message hasn't arrived yet. In order to process them in timestamp order, it would have to wait some time (call it delta) before responding to your message; this could get very annoying, but the alternative is to throw causality out the window. I would say an object should respond to messages *in the order they arrive* without regard to timestamps. People with slow network connections don't have as much control over the universe; that's life. The alternative is to deliberately introduce delta-delays on every single interaction, which would make the world unusable. (Cascading interactions would be even worse, since you'd have to use longer deltas). >For some types of applications causality violations can just be >ignored. For others you must be able to "rewind" time and play back >all the events in their correct order so that history happens >correctly. Yikes! That strikes me as a very complicated task, especially since some interactions will depend on others. And from a user standpoint, watching an object I picked up suddenly and inexplicably jump from my hand down to the floor next to the table would be *very* disconcerting. >> What should our unit of time measurement be? >The second. >> What precision should it have? >Time would appear to need arbitrary precision and need to be scalable. Well, maybe. We still need to have some notion of a "tick time". If we were to adopt the timestamps you described, the timestamp would have to be in some kind of time units and have some number of bits of precision. >I expect that every dimension in VR will need arbirary precision and >need to be scalable. I'm not sure that's practical, but I think further discussion is needed. >> How do we ensure that a given color looks the same to >> everyone? Does this even matter? >Yes, it matters very much. Take a look at Xcms in the X11R5 release. I guess what I meant was more like "you see the color blue one way, I see it in another, but we both agree it's blue and that it's darker (or lighter) than another shade of blue; does the actual color really matter?)" >> How do we represent and share surface textures? >The people I know who really know 3D graphics tell me that mip-maps are >the way to go... I'll see if I can find a reference... anybody out there got any pointers? >Extensiblity is a requirement for any protocol. Agreed!!! >> Solid >> modelling is perhaps the most general, but currently it is not practical >> to do real-time raytracing. >I don't believe that there is an inherent connection between >raytracing and solid modelling. That's true. I tend to think of them together, since most raytracers support CSG combinations of primitives and very few non-raytracing systems do. >I'd say that solid geometry is the most general. I agree. >In a fully centralized system you can swamp any machine you can >imagine. In a fully distributed system you can swamp any possible >network. That's true. However, adding bandwidth is easier than adding processing power; you just add more physical connections and multiplex the traffic over them. (True, you can go to an extensible multiprocessor architecture, but that's still more complex than increasing bandwidth). >I like the idea of structuring it more like an air traffic control >system. You have a bunch of routing centers (called routers) that >control the propagation of messages. Each world has at least one >router. But, a world can be made up of multiple routers that each >handle specific regions of the world. It only gets messy at the >boundries between regions. The collection of all communicating routers >is called a universe. This sounds very, very good to me. >Routers aren't tied to specific iron. For small worlds multiple >routers can run on a single machine. For big worlds you may need >multiple very large machines. Yes. >I think that objects will need to send out position change messages >when they move. And they'll need to send out "here I am this is what I >look like and this is what I do" sorts of messages to anyone they want >to interact with. I think that we will want to move the visual >information and at least some of it's behavioural information to >individual viewing stations. Rendering across a network hard to do in >real time. Right. >But managing the data flow in a highly populated world is going to be tough. Yes -- it's probably the main "unanswered question" that (so far) no one's put forward a good solution for. >So, what are the hardware requirements for a "VR station" or "deck" >that can deal with this protocol? This is going to be controversial. Do we insist on HMDs? Do we set frames/second thresholds? Do we have a "standard world" for benchmarking? What about input devices? > How slow a machine do you want to target? > How little RAM are you willing to target? These are both difficult numbers to wrestle with. They're dependent on how you store the data; if you're representing things with CSG, you don't need nearly as much ram as if you're using polygons... and if you're using voxels, you need even more. Same with processor speed; you need more MIPS if you're dealing with CSG than if you're just doing polys or wireframe. I don't think we can set specific numbers; if we support multiple object resolutions (and representations) then we should be able to accomodate a wide range of machines. > Do you assume access to a large secondary storage device? Again, it depends on how you do things; in general, I'd say "yes" (so you can do local caching of object attributes). > The number of displays, the number of pixels/display, the number of > bits/display, and the color mapping method (static color versus > loadable tables) are critical factors. I'm not sure we need to know pixel resolutions and bits/pixel; if some people wind up being effectively color-blind because their station can't handle the color resolution, that's fine. >Are you goint to try to support people with 110 baud modems? Or are >you going to assume mega bit/second rates? I'd suggest somewhere in between. :-) > What does input from a generic input device look like in the protocol? Very good question. A more basic one is "what do we mean by a 'generic input device'"? > How do I substitute a dial box or a mouse for a data glove? Dave Stampe and I are looking at this very question for our REND386 stuff. (No, we haven't really answered it yet). >How many channels? What capabilites? Will a Disney Sound Source do? Stereo, certainly; in terms of where the sound gets processed... I would say in the user's station, which means we need to move a *lot* of sound data over the network. >In my view of what is being discussed, there are at least three >different hardware configurations to worry about. There is the >hardware that objects run on. There is the hardware that worlds run on >(a world is message router). And the viewing station that people use >to interact with worlds. Right. >All three of these things can run on a single computer. But I expect >that they will be mapped onto workstation/PC machines for viewing >stations, and servers for message routing and for running non-person >objects. Right. A workstation or PC is the most likely viewing platform. What's not as clear is what the viewing mechanism will be; a monitor, shutter glasses, head-mounted display...? Also input devices... 3D mouse, glove, datasuit? I suspect Unix boxes will be popular for implementing regions and objects. Anyway, thanks for all the good ideas... -- Bernie Roehl, University of Waterloo Electrical Engineering Dept Mail: broehl@sunee.waterloo.edu OR broehl@sunee.UWaterloo.ca BangPath: uunet!watmath!sunee!broehl Voice: (519) 885-1211 x 2607 [work]