From: Jeremy Lee Subject: Re: TECH: My standard is better than your standard. Date: Sat, 18 Jul 92 19:54:23 EST In article Bernie writes: >In article <1992Jul15.233601.6824@u.washington.edu> bobp@hal.com (Bob >Pendelton) writes: > >>> 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). I've got an answer to this. See my report. Objects themselves decide which other objects to talk to. Objects naturally form a group that talk almost exclusivley to each other, and that, to all intents and purposes, is the same as a "world" >>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"). Heyyyy! We think alike. I came up with exactly the same thing last night.. Each object is responsible for only itself. >God should have nothing to do with it; god is a security hole. >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. Probably the best way to deal with this is to use a system where if an object doesn't get seen for one frame, then the chance of even attempting to render it for the next frame goes down. You hit a lower limit, and say, for nine frames out of ten the renderer doesn't even look at it. If on that one go in ten it is suddely seen again, then the priority goes right back up and an attempt is made to render it every frame. Of course, it depends where you set your limits, but in this case, then when you actually end up looking at it, it will appear within ten frames, or 1/3 of a second in some systems. Short enough for you not to notice. It will take that long for it to move in from your peripheral vision. >>This all leads to the idea of a world and it's god being defined by a >>message router. > >Yes. No. "worlds" per se don't exist in my model. Only objects do. If a group of objects decide to assosciate, then you can call that assosciation a "world", but it still doesn't really exists. Message routers should be completely transparent, and should have no bearing on the objects. >>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. > >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). I agree. It's easier to put the messages in a queue, with timestamp attached. If the object want to pay attention to the timestamp, then that is their business. The universe itself throus causuality out the window on occasions anyway, so why worry about that? >>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. You can't rewind it. It's a non-deterministic system. >>> 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. You can't really scale time. It's just not practical. the system will run at the speed it wants. You can't make it go faster, although I suppose you can make it go slower. I personally like the idea of 128 bit numbers to describe spatial co-ordinates. If you scale 32 bit numbers, then you are going to get just as large a speed decreace through calculations, and you have the extra hassles of making sure that everyone is using the same scale factors. And what if an object just won't fit in the current world scale? >>> 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?)" Irrelevant. >>> How do we represent and share surface textures? Doesn't matter. Each object does it the way it wants. (See my paper) >>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? Nope, but I'd like some. >>Extensiblity is a requirement for any protocol. > >Agreed!!! Of course. >>> 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. There isn't. >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. So you are ruling out all special cases? >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). Look at the bandwith increaces that are just around the corner, when people really begin using optic fibre. Currently it's trunk line only. What happens when you have the equivelant of a trunk line leading into your PC? >>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. Routing and all network stuff should be trasnparent and should have no bearing on what constitutes a world. In that sentence, you are basically saying that objects are restricted to worlds in close physical proximity, and I therefore wouldn't be able to connect to a world that's in Tokyo, for example. >>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. Sounds like your routers are central controllers, and I thought we all agreed that they just won't be able to cope. >>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. Not nesessarily. Depends what you mean. >>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. You can't, and you don't need to. Any system is going to be able to be swamped by too many objects. But, by the time it gets that big, then most people will be leaving anyway, because it's so congested. >>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? See my paper. >> 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. See my paper. >Same with processor speed; you need more MIPS if you're dealing with >CSG than if you're just doing polys or wireframe. See my paper. >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. See my paper. (This is getting monotonous!) >> 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). Doesn't matter. >> 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). Just change the object. Re-write a few internal processes, keep the same interface with the rest of it. >>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. Not necessarily. See my paper. >>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. Nope. Chuck the message routers, because they are simply another bottleneck. They are not needed. Since the viewing station is also running objects, then you are just left with one type of machine. >>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. No, what will happen is that objects just get shared. Rendering bits will get put on the viewing station etc. >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? Doesn't matter. >I suspect Unix boxes will be popular for implementing regions and >objects. All machines will have to implement 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] So, where is this vaunted paper that I keep talking about? I'll post the text after this, but can someone tell me where to send the .ps file? (aw, stuff it. I'll just post it. No doubt the moderators will do what is correct with it.) *********************************************************************** * . Jeremy Lee s047@sand.sics.bu.oz.au Student of Everything * * /| "Where the naked spotless intelect is without * * /_| center or circumference. Look to the light, * * / |rchimedes Leland, look to the light" - Dale Cooper * ***********************************************************************