From: broehl@sunee.waterloo.edu (Bernie Roehl) Subject: Re: TECH: My standard is better than your standard. Date: Sun, 2 Aug 1992 18:32:31 GMT Message-ID: Organization: University of Waterloo In article <1992Aug1.074144.2016@u.washington.edu> dlwood@mailbox.syr.edu (David L Wood) writes: >Suppose I was using a wireframe display with incredibly high resolutiono >(sitting next to Lee's processor and my pocket sized Terrabyte drive :) ) >then I would most definitely want the message router to tell me of the >existence of the fork in that drawer in your kitchen across the street. ...which implies a very long startup time when you first enter a world, since you must be told about thousands and thousands of objects that you'll probably never see. That's take up a *lot* of bandwidth. >Something as simple as a house wall would >quite easily eliminate the need to render the fork in a z-buffer system. Again, one of our goals should be realistic hardware requirements. We can't assume a z-buffer, any more than we can assume super-high- bandwidth lines. And even if they *have* a z-buffer, we still have to render everything into it, even the unseen things (unless we have the custom z-buffer discussed earlier, which tracks object visibility over time...) I believe we should not tell a rendering station about things that are obscured from its view. That way we can keep the rendering station simple and fast (which is what we want). It also means more intelligent "filters" (of what's visible and what's not) can be developed and implemented in a transparent way. >Where does all the bandwidth come from in this network? If an object's >data set, however >that< standard develops, is sent only when an >object first comes into significant view, and each succeeding message >is an object id code followed by something like a motion vector, then >bandwidth would depend on the characteristics of those messages. Perhaps. But consider a worst-case scenario of a group of strangers all meeting in a room at an appointed time; every object would have to send its appearance to n-1 other objects... sure, it only gets done once, but it chews up a *lot* of bandwidth while it's happening. >This addresses the problem of being swamped by messages whenever >someone's nose twitches and they're in an auditorium with ten million >other twitching noses (virtual of course.) This really depends on how >you could encode the "animation" information. Right. >A good way to define animation in a >network would be to identify an object, then identify sub-objects that >may move, but are still "related" to the parent object. Yes, absolutely. If I turn to look what's behind me, the rotation of my chest about my waist is the only information that needs to be sent; all my other parts (head, arms, fingers etc) naturally don't have to send their own messages since they're descended from my chest. >could send a message >to the router< telling it to only send me >messages concerning the objects that change or move within a certain >volume. This volume could be a hemisphere, a cube, or whatever [...] A strictly volume-based system isn't really enough. There are small things within that volume that I can't see (e.g. the paramecium from an earlier message) and large things outside that volume that I can still see (a plane flying overhead, for example). >the message router wouldn't be taxed too much (I'd imagine) by using >fairly simple cutting planes or volumes, and it would reduce the >number of messages I receive by objects that aren't in my field of >view. I think we should (for now) treat the "router" (which is a *really* bad name for it) as a black box that acts as a "filter" (much better word) that decides what's "relevant" to me based on information I give it about my visual acuity. I think we should further assume high bandwidth and low burstiness between the various filters/routers, but (for now) low bandwidth between the filters/routers and the machines hosting the objects (including the rendering stations). Ultimately, we'll have enough bandwidth coming into our local machines that we can move the filter process off the far end and into the machine on our desk, resulting in a completely decentralized system; in the meantime, we have a way of functioning with slow lines. >I know what you're saying, Bernie, and what about when I want >to turn my head 180 degrees, owl-style? Well, then you would send a >message to the router telling it that messages from this >updated< >volume are now significant. As soon as you look behind you, you would >have to be told the new positions of objects just as you were when you >first entered the scene. I'd say the filter should tell you everything you can potentially see from where you are, regardless of which way you're facing. >No, the router doesn't need to send you the >dataset of each object you look at, the router could store a list of >those unique object id's that have had their datasets sent to you, >(and it would be up to you to keep those datasets handy!) and tell you >only their updated positions any new motion vectors, and any new >objects (which could have their data sets sent to you at any time >before [even when you're not looking at it]). I sort of agree with this. I think there should be two types of caching; your local station should cache object data it receives from the vrnet, and your connection at the far end should do the same. >>Not enough for *what*? Quantum-level descriptions of the *entire universe* >>can be handled in 128 bits. It's not like internet addresses or color >>palettes or DOS memory; we're talking the basic physical dimensions of the >>universe, here. > >but if you were a >part of the microcomputer revolution then you can recall when a 10 >Megabyte drive seemed like a bottomless pit. Now a 1.2 Gig drive (at >least to me) seems equally bottomless [...] Yes, I was a part of the revolution, and yes, I know the feeling you describe. However, as I described above, we're talking about universal absolutes here. 128 bits is the *absolute maximum* you will ever need for *anything*, because that's effectively the resolution of the universe itself. >I can understand the ethical reasons behind disliking a controlling >device. But how else can the small machines on a network cope with >the vast data that hypothetically could drown them. Also, should each >object's dataset be stored on the router's machine? This is a slight >problem I'd imagine. That's why the "filter/renderer" split becomes important. The abstract "object" is implemented in two parts, one on each end of a slow link. The "filter" part is connected to a high-speed, high-connectivity network. (The "big, monolithic mainframe" advoctates can have all the filters sharing a common world database on a huge machine; the rest of us can set up a high-speed lan with low-speed external connections). The "renderer" part (or "object" part) connects up to the filter over a much slower, possibly bursty line. -- 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]