NetNews Usenet Archive 1992 #16/NN_1992_16.iso/spool/sci/virtual/2567

Text File | 1992-07-25 | 9.8 KB | 214 lines

Newsgroups: sci.virtual-worlds
Path: sparky!uunet!zaphod.mps.ohio-state.edu!sol.ctr.columbia.edu!destroyer!ubc-cs!uw-beaver!news.u.washington.edu!milton.u.washington.edu!hlab
From: Jeremy Lee <[e-mail]>
Subject: Re: TECH: My standard is better than your standard.
Message-ID: <[e-mail]>
Originator: [e-mail]
Sender: [e-mail] (USENET News System)
Organization: University of Washington
Date: Sun, 26 Jul 1992 09:02:40 GMT
Approved: [e-mail]
Lines: 201



In article <[e-mail]> you write:
>In article <[e-mail]> Jeremy Lee
><[e-mail]> writes:
>
>>>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.
>
>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?
>(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).

Well, the "Start up time" should be on the order of a second or two, so
it's not that bad.

They way I'm thinking of it is this. Assume that you have a standard
Z-buffer drawing system. You have objects that are within the field of
view, but are obscured, say by a wall. If your Z-buffer drawing code
(crude simplification, it may be a totally seperate section) keeps track
of each polygon, and for one frame does not draw a single pixel (which
is reasonably easy to check) of it, then the chance of drawing it for th
next frame goes down. It might reduce the chance by 1/30 to a lower
limit of 1/30, so that in a 30fps system, each object is attempted to be
drawn at least once. That means that if the objects comes into view at
any time within a second, then it will immediatley be resored to being
attemped to be redrawn every frame. Of course, you might want to fiddle
with values to get them right, but if you use this in conjunction with
the other efficiency systems (not drawing objects that are behind you,
objects with the surface normal facing away..) then it may increace the
efficiency somewhat.

>>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.
>
>Right.  (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.

>>I personally like the idea of 128 bit numbers to describe spatial
>>co-ordinates.
>
>I still maintain that 128 bits is overkill.  How often do you need to
>model the entire universe at the quantum level?  And having all that
>extra data to send around the network would degrade performance even
>further.  I think we should start with something smaller, but that from
>day one we should make provision for expansion.

That's difficult, because we are defining such a basic parameter, that to
make it extensible would drastically degrade performance (how would you
like to have to do the extra checking every time you wanted to perform
an arithmetic operation!) and to change it at a later date would break
all current systems.

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 have worked in depth with many many systems that both did and did not
make provision for what, at the time, was considered ridiculously
massive expansion (a 1981 computer with provision for a 24 bit pallete -
the BBC micro, cf. the IBM pc, 640K limit) but which in a fairly short
time has proved itself to be completely worthwhile. If your argument
that the only reason to ditch 128 bit numbers is that it is not
necessary *now*, then I would assert that your argument is invalid.

How often do we need the entire universe at the quantum level? All the
time! (In reality anyway, and I thought that VR was to go BEYOND the
bounds of reality)

I run a 32bit RISC computer. To do a 128 bit add would require, lets
see, (tuneless humming and the sound of turning pages) 4 instructions.
Iff the registers already contained the two numbers. (ps, that's 4 clock
cycles.)
        ADD R0,R4,R8
        ADC R1,R5,R9
        ADC R2,R6,R10
        ADC R3,R7,R11
        (eqivelant to R0-3 = R4-7 + R8-11)
To do it with two registers pointing to the address of the numbers it
would take 6 instructions which is 6 clock cycles and 8 memory cycles.
        LDM R0,{R4-R7}
        LDM R1,{R8-R11}
        [ .. same as above .. ]
To store the results somewhere, say at the position of R12:
        STM R12,{R0-R3}

This can all be done in much less time than a floating point operation,
with much more precision, mind you. Also, it can also be done faster
and with more accuracy than using 32 bit numbers with a scaling factor.
To use a scaling factor would take a multiply/divide, and would loose
precision, so 32 bit numbers will end up with below 32 bit precision.

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. You simply have to
tell the other objects the *offsett* from the last position. Also, if
you use a compression algorithm before sending-recieving (hardware is
already here) then I'm sure that unused resolution will get compressed
out.

>>>>Extensiblity is a requirement for any protocol.
>>>
>>>Agreed!!!
>>
>>Of course.
>
>I think this is one of the points we *all* agree on!

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.

>>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.
>
>Not sure what you mean by "a world that's in Tokyo"?  A virtual world doesn't
>really *have* a physical location.

But the description of message routers that was given was that it they
were physically based, and relied on the topology of the connecting
network.

>As to why routers are important... even with very, very high-bandwidth
>networks I don't think we want every object in the multiverse having to
>broadcast to every other object.  We need some way of limiting traffic
>to those who are interested in it.  (Broadband vs baseband, sort of).
>Different "worlds" (and perhaps different regions within a world) are
>different "channels".

How does EMail work? I think that is the best model we have.

>>Sounds like your routers are central controllers, and I thought we all
>>agreed that they just won't be able to cope.
>
>Not central controllers; *distributed* controllers.  Even "controllers" is
>the wrong word.  They're routers; they help objects communicate efficiently.

The description posted indicated that the "routers" did much more than
simply message routing, including deciding which objects other objects
would talk to, based on whether the router believed they were relevant,
in an effort to reduce traffic. That sounds like a controller to me!

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! If the sending objects didn't think the
message was necessary, then they wouldn't have sent it. Imagine an
analogy. An EMail router somewhere began dropping messages because it
decided that there was no need for someone in Australia to be conversing
with someone in the USA, and besides, it would reduce net.traffic.

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?

>>See my paper.
>>[...]
>>See my paper.
>>[...]
>>See my paper.
>>[...etc...]
>
>All right, I get the idea.  You want me to see your paper, right?  :-)
>Looking forward to it.

I posted it right after that. I expected the plain text to get posted to
the newsgroup, but apparently the moderators have archived that as
well. The postscript (complete with neat diagrams) should be somewhere
as well. I suspect it will be in the archive at wheresitcalled along
with everything else. Care to comment Mr. moderator???

>--
>        Bernie Roehl, University of Waterloo Electrical Engineering Dept
>        Mail: [e-mail] OR [e-mail]
>        BangPath: uunet!watmath!sunee!broehl
>        Voice:  [phone] x 2607 [work]

Interesting to converse with you Bernie. Together I think that a real
good system will get hashed out.

***********************************************************************
*    . Jeremy Lee [e-mail]    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         *
***********************************************************************