From: broehl@sunee.waterloo.edu (Bernie Roehl)
Subject: Re: TECH: My standard is better than your standard.
Originator: hlab@milton.u.washington.edu
Organization: University of Waterloo
Date: Sun, 26 Jul 1992 15:58:18 GMT


In article <1992Jul26.075054.9456@u.washington.edu> s047@sand.sics.bu.oz.au (Jer
emy 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]
Newsgroups: sci.virtual-worlds