From: broehl@sunee.waterloo.edu (Bernie Roehl) Subject: Re: TECH: My standard is better than your standard. Date: Sun, 26 Jul 1992 15:58:18 GMT Message-ID: Organization: University of Waterloo In article <1992Jul26.075054.9456@u.washington.edu> s047@sand.sics.bu.oz.au (Jeremy Lee) writes: >>A good idea, but what do I do when I first enter the world? Do I have >>a long start-up period while I receive and render the entire environment? > >Well, the "Start up time" should be on the order of a second or two, so >it's not that bad. A second or two? Let's say there are 1000 objects in the entire world (which is actually quite a low estimate for most "interesting" worlds). Assume we're using polygon based reps, with an average of 20 vertices and 20 polys per object. If (as you suggest) we use 128 bit values for our coordinates, 20 vertices at 48 bytes per vertex is 960 bytes per object just for the vertices. Assume 24 bits of RGB, a vertex count and an average of four 16-bit indices per poly (say, 13 bytes/poly total) you get another 260 bytes per object for the poly information. Average per object: 1220 bytes plus miscellaneous timestamp, object i.d. etc.... call it 1300 bytes/object. Total size of the world: roughly 1.3 megabytes. Compression algorithms will help, but they won't save you much; say a 9600 baud modem has an effective throughput of 2 kBYTES per second for this kind of information. It would take 650 seconds, or more than 10 minutes, to download the world. And that's a *simple* world. If it took you 10 minutes to get into news, you wouldn't be here right now; you'd have given up in frustration a long time ago. Worse yet, that amount of information has to be transmitted across the network for *every new object that enters the world* ! True, I can do caching, but if you open up a new world and everyone flocks to it, you may have to move hundreds of megabytes of information over a very short span of time. More serious is the problem of position updating; assuming even just 10 updates per object per second, with 3 16-bit angles and 3 128-bit values (x, y and z) we get half a megabyte per second, not counting overhead! (Okay, you can do delta modulation as you suggest below, but *still* ...) >>(Also, some graphics implementations will find it easy to keep track of >>which objects are actually visible; others will find this very expensive >>to do). > >The way I'm thinking of it is this. Assume that you have a standard >Z-buffer drawing system [...] This is only reasonable if you assume special-purpose graphics hardware; how many people reading this right now have ready access to systems that do hardware Z-buffering? In any case, the scheme you're describing (which is very clever, by the way) wouldn't work with existing Z-buffer hardware, since the hardware (or firmware) doesn't know to do it. In which case we're talking about a custom hardware solution. >>(Of course, sending a timestamp with every single message does >>add to the overhead and lowers the performance). > >Not really. Most OS's and network systems put a timestamp on it anyway, >so it's more like utilising a facility that is already there. True. >[re: 128 bit coordinates and extensibility] >That's difficult, because we are defining such a basic parameter, that to >make it extensible would drastically degrade performance But it won't degrade it nearly as much as using 128 bit coordinates, which is my point. There's also the fact that very, very few systems can easily handle 128 bit coordinates. > (how would you >like to have to do the extra checking every time you wanted to perform >an arithmetic operation!) How would you like to have to juggle 16-BYTE integers for every arithmetic operation? In any case, you wouldn't have to; you can store them internally however your hardware likes them. I'm talking about a format for data interchange. >It is said that there are only three numbers in CS. 0, 1, and infinity. >(128 bits is the functional equivelant to infinity in this universe anyway) I'm saying that "infinity" varies from one universe to another. For the vast majority of universes, 32 bits should be the functional equivalent to infinity; we can make provision for 128-bit worlds, but it shouldn't be a minimum requirement (because it's not a minimum, it's a maximum). >I run a 32bit RISC computer. My point is that the number of people with 32bit RISC computers and custom hardware Z-buffering is much, much smaller than the number of people who don't. If we want a world that's only open to those who can pay big bucks for their hardware, fine... but that certainly leaves me out, and a lot of other people, too. [assembly language for a RISC computer deleted for brevity] >If you are worried about storage space, or net bandwidth, then don't >because 128 bit absolute positions will not be necessary that often, and >any intelligent scheme will support delta encoding. Delta encoding is only reasonable if you can be sure that everybody sees every sample; I'm not convinced that's going to be the case. It definitely won't be the case for someone who's just arrived; they need to get full-precision coordinate information for every object in the universe. >you use a compression algorithm before sending-recieving (hardware is >already here) Hardware is already *where*? On your platform, perhaps. Again, the more we add to our "entry-level" system, the fewer people we'll find in the virtual world once we build it. Frankly, I'd rather have a primitive world with lots of interesting people in it than a more detailed world that is, in effect, a ghost town. (Or a vacation resort for people with *very* big research budgets!) >The problem is that how do you make your basic way of dealing with >numbers extensible without drastically loosing portability or >efficiency. I think that 128 bit numbers will solve that, and give us a >lasting standard. Hmm. Food for thought. >How does EMail work? I think that is the best model we have. I would *strongly* disagree here. Email is not meant to be real-time; virtual worlds are. If it takes ten minutes for email to get through (because of a heavy load on the sending or receiving machine) it's not a big deal. Also, email is inherently person-to-person (or person to several people); in VR, in most cases, I would want information about me passed to everyone in the world (so they know where I am, what I look like, etc). >Of course message routing is needed, but the routers should only be >passing the message on, deciding which router to give it to next as a >simple excercise in quickest-path. The routers should NOT be deciding >*whether* to pass it on or not! So you're saying that every time I move, I must send my coordinate information to *everybody*? Do a "flood-fill" algorithm on the vrnet? Or that I send the message a large number of times, once for every object I suspect might be interested? >Thinking about it, I can still see a need for a little more intelligent >message routing along these lines: A message gets sent to 10 objects. >With todays system I would have to send 10 messages, and these messages >would follow the same path for quite a lot of the way. In other words, >it would be redundant data. Surely a little intelligent routing can be >done where the routers only fan out the messages when needed? That's what I would propose. (Actually, I'd propose we make it even smarter than that, but anyway...) >Interesting to converse with you Bernie. Together I think that a real >good system will get hashed out. I agree; it's good that we have such different opinions, since if forces us to think about our views more carefully (at least, it's done that for me). Of course, I'm *still* jealous that you have a RISC computer with custom hardware Z-buffering ... ;-) -- 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]