From: bp629@cleveland.Freenet.Edu (Joel J. Nye)
Newsgroups: sci.virtual-worlds
Subject: Re: TECH: My standard is better than your standard.
Date: 29 Jul 92 01:06:24 GMT
Organization: Case Western Reserve University, Cleveland, OH (USA)
Originator: hlab@milton.u.washington.edu



I wanna play too!  Forgive my lack of credits to everyone I quote...
I'm just trying to make this readable.
 
}In a previous article, dlwood@mailbox.syr.edu (David L Wood) writes:
>In article <1992Jul19.055422.12836@u.washington.edu> Jeremy Lee
<s047@sand.sics.bu.oz.au> writes:
>In article <BrHr16.Mvq@watserv1.waterloo.edu> 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)?
 
I believe that the virtual universe should be organized in a
hierarchial model of 'relevance.'  Using a mantissa as in floating
point numbers, one can dermine an index of scale in which 'irrelevant'
details are not rendered.  This would allow the 'deck' to retain info
on the objects if desired, just not to act upon the trivial ones.
 
From an engineering standpoint, the Mantissa would act as a shift
count, where the OperatingSize = IntegerSize >> (OperatingScale -
Mantissa), thus allowing all coordinants to be scaled without the
slowness of most multiply / divide bottlenecks.
 
Such a Mantissa could be applied to every primitive along a heirarchy,
so that the closer you look, the more you see.  (Earth object holds
continent objects, which hold mountains, etc.)  Objects below a
certain relevance simply go unrendered.
 
Relevence Indeces (or Mantissas) can be applied to other applications
as well.  You may choose to ignore objects of insignificant Mass when
doing studies in Gravity on a planetary scale (or maybe not).
 
> If you want to shape the object definition around this, a tree of
> primitives (possibly similar to CSG) sorted with largest primitives
> at the top and smallest primitives at the bottom would allow for
> slow machines to discard the unnecessary details and faster machines
> to use the whole data structure for very nice pictures.  In the router's
> point of view, it only has to pass those levels of the object tree that
> would contribute significantly to a viewer's display, and ignore those
> that aren't visible because of size.
 
Yes, just what I'd come up with these last few months.  And by using a
determined index based on, say, the diagonal length of a bounding box
for each item, you can find an optimized clipping point for rendering.

>>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.
 
First, on the issue of 'cybertheology,' if you define a god program as
being the controlling force which keeps things in motion and assures
the continuance of processes, then that god is simply the operating
system.  Then that god IS the security system.  The rest follows the
"watchmaker's" rule that once the universe is set in motion, he sits
back.  (Though perhaps he handles the rules of adding/deleteing
objects and scheduling.)
 
There will no doubt be overlapping sets of relevance/influence... not
just Scale.  Scale effects viewing, and sometimes processes. (If
you're observing rust, metal with less than a certain amount of
oxidation will appear pure.)  Other sets can be grouped around
specific objects... the sun attracts objects smaller than galaxies,
etc.
 
>>> Put a time stamp on each message sent by each object.
>>
>>>Process messages in time stamp order.
>>
>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.
>
>>>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.
 
Bravo! By using an input queue, a fast machine can kill off idle
bandwidth, keeping the interface usable, by acting on input ahead of a
received 'approval'. While it may seem disconcerting to pick up an
object and move it only to find someone else actually grabbed it
first, this may be less troublesome than to find the object practical
immobile anyhow.
 
ON THE ISSUE OF TIME: Most industry workers are OBLIVIOUS to the
importance of time. Sound, Animation, and process are all functions of
time. (And isn't that what Virtual Reality is all about? :-) ) The
last thing we need are 'frames' that flicker by like an old
kinetoscope, running vastly different rates across different
platf{orms. Perhaps Fu{nctions of Time should be expressed as just
that; F(t).  Plug in the frametime elapsed, and you get the the new
result of the Function.
 
>>>I expect that every dimension in VR will need arbirary precision and
>>>need to be scalable.
>
>If you have a system of objects whose behavior depends on the time variable,
>you could certainly scale THEIR time, slowing down your virtual model
>railroad or speeding up your virtual ocean tides.  Your personal time,
>as recorded by the message router is unrelated.  You can't slow down another
>client's time, or the time of the entire network (legitimately) since
>this would upset people; I'd be!
 
Of course.  How else would Jaron Lanier have taught himself to juggle?
He slowed the acceleration of gravity to train his eye-hand coordination.
 
>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?
}Define floors, not ceilings.  128 bits is not enough.  You could use
}a system of variable length coordinates.  An id byte would indicate
}how many bits (or bytes, take your choice) are used to locate a
}coordinate.  Really, anything to extend the ability of the protocol
}is better than putting a limit like 16 bytes.  I'll admit 16 bytes is
}fairly hefty, but if you want to dump an entire universe into a file
}that contains every object at a particular instant (universe snap-shot),
}then 128 bits isn't going to cut it.
{{}
 
*Gasp* One-point-Twenty-eight Gigabits?!? er... I mean 128 bit
coordinants?  If an ant on the other side of the galaxy budged a
millimeter, do I care?  Calculations of scale cannot justify this
waste of bandwidth... especially if using integer Mantissas.(see
above)
 
AND SPEAKING OF BANDWIDTH... Many of the Applications in Cyberspace
will be demanding on Bandwidth... some will exclude the use of slower
machines.  These systems will vary from the low-band conferencing of
cardboard characters to simulations so intense that only supercomuters
can watch.  The law of admission will become "If you can't take the
heat, stay out of the Kitchen."
 
But you'd be amazed just how much can be done with a 2400 baud modem
and the right 'deck.'  Don't go pushing 100-point objects a new set of
128 bit coordinants when a simple transformation matrix will do.
(Unless you really NEED to cause the object to ripple in a non-linear
way...  and wait six seconds per frame for it to do so!)  When objects
are created, that may be needed.  But bandwidth and interaction are
important; Think 'triggers' instead of results... Causes instead of
effects.  That's what a protocol's about.
 
What's true with bandwidth is also true of graphics/memory.  MIP-maps
are useful, but a 2 meg machine may need to dispense the formality of
good looks in order to still run.  Send the raw map, and let the end
user choose between building a good-looking MIP-map or not.  One might
chose an aliased image over a slower anti-aliased one, for the sake of
speed or space.
 
>>>>  How do we represent and share surface textures?
I'd love to tell you about the fast-Bezier-surface-patch routine I'm writing.
But that would be cheating. (It's not finished yet.)
 
>>>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.
 
Behavioral Information!  That reminds me of another months-in-running
idea...  Many participants in VR dislike the 'artificiality' of the
people in cyberspace, even if their controlled (remotely) by humans.
It gives them Cyberphobia, a feeling of unreadable, unpredictable
malice, lurking behind the unchanging eyes of the walking dead.  Why
not send behavioral info?  My eyes will blink every 16.8 seconds and
the lids relax when I talk.  (Now THERE's one to chew on.)
 
Other Behavioral Information could be used for security access.
Manual: "I am a book, and I have a rather codex-like appearance."
User: "Open book."
Manual: "Nice try, buster, but you'll need more clout than that.
       Send the appropriate password to the following PO Box,
       and I'll then make my contents readable."
User: "Oh. that's okay.  I never read manuals anyhow."
and chucks the book into a virtual corner where all his other snooty
manuals are 'filed.'
 
}Never trust a client to handle something that could be misused. Also,
}imagine you're on a slow machine, I mean SLOW! You run in wireframe mode,
}and your tiny 2400 baud modem can barely keep up with message flow.
}(I'm not this deprived, but imagine those who are.)  Suddenly you are
}surmounted witha thousand requests from one source (an enemy) of a
}fully detailed object description!  Thousands of K that would bog you
}down like a fly on flypaper. Of course you could put some restrictions on
}frequency of requests and such, but honestly, the router should handle
}this.  Any slight variation in the course of my virtual airplane would have to
}be transmitted to the whole network who I am visible to, which is fine if
}the router included it in its round of messages to a client, but if I had to
}send out these messages myself, the strain would be horrific.
}You NEED a central control by definition of DOMAIN.
 
In keeping with the saying about kitchen heat, one might also say that
if you're cooking for one, you don't need fire for a dozen ovens.
Your router can probably assume that a bandwitdh of 2400 baud can
neither recieve nor provide a certain workload.  Not a bad line of
thought to pursue.
 
>>>        How slow a machine do you want to target?
>>>        How little RAM are you willing to target?
}Speed of the machine and RAM requirements are really NOT elements of the
}protocol, they are elements of IMPLEMENTING the protocol.  If someone
}can write the protocol and renderer and all with a meager 2 megs of ram,
}then why should the protocol care?  If the particular tricks and techniques
}of a particular implementation can allow a slow machine to keep up with
}network messages, why make it suffer?
 
Yes. The purpose of protocol is to cause the effects of a mutual model
to be communicated... not to muscle the full model manually through
everyone's system. If a slow machine loses a 'frame' or two of
animation, that's just a quirky effect it'll have to live with.
 
>>Same with processor speed; you need more MIPS{ if you're dealing with
>>CSG than if you're just doing polys or wireframe.
}The choice of polygon/wireframe/stereo viewing/ et ce{tera... is up to
}the cli{ent, the protocol doesn't decide that. It shouldn't!  Imagine having
}to send whole raytraced images over a network!  :)
 
Perhaps the 'host' of a function can take requests for speeding up or
slowing down a task.  If it got a 'consensus' of how things should
function, then the slowpokes could share without missing a step.
 
}Comments on input devices:  If the input device is "attached" to a virtual
}object, then the behavior of the object must be defined as changes in the
}input from that real-world peripheral. [...]In this way all the input device
}processing is done locally, and only the IMPORTANT information, the end
}result of the input is transmitted to the network.  You would have to
}"link" a dataglove to a virtual glove by defining the primitives or
}equations (formula for a hand anyone?) and where they can rotate about
}an axis, where they can be translated about, and for each of these range
}of motions in the virtual world, you would then of course have to calibrate
}your input device so that you get the degree of motion that you like.
} [ . . . ] I'd like to see the
}input devices kept INDEPENDENT of the protocol and any network overhead.
}End results should have smaller bandwidth, and more easily computed in
}real-time than raw output.  I propose no general input device supported
}by the protocol, only behavior or "puppet-strings" control of virtual
}counterparts.
 
How's this for a STANDARD... all user input is handled at Gr0und Zer0
from the 'deck', and is tied in to his user object.  His object can
then issue interaction and commands to the rest of CyberSpace.  The
three primary functions, similar to mouse buttons, are (but are not
confined to) READ, MODIFY, and WRITE.
 
These Three functions can be generated by glove, mouse, keyboard,
speech, a combination of the above, or something completely different.
I must explain them, but I must first explain how GUI's work with your
brain.
 
GUI's today are based on the actions of 'Point' and 'Click.'  'Point'
is a Right-Brain function.  It allows the user to browse the available
options, gather an impression, and hand a recommendation over to the
Left-Brain.  Likewise, 'Click' is a Left-Brain action.  The
Left-Brain, being endowed with language and logic, has made a choice,
and clicks on it.
 
It used to be that all creative uses of the computer were at the mercy
of Programmers whose oversized Left-Brains crooked their necks
off-balance.  All actions had to be orchestrated into Language, and
even then had to be expressed with explicit Logic.
 
Then came Menus, resuscitating the Right-Brain from its life in
vacuum.  Then came GUI's, which initially were so Right-Brain
intensive, they gave birth to WIMPS of the Anti-Logic.  GUI's had to
adapt, so they began to offer Keyboard Shortcuts, giving Both-Brains a
grasp at complete productivity Power.

Where was I?  Oh Yes, Point and Click.  The reason Macs have keyboards
is that Left-Brains are a terrible thing to waste.  The reason that
MS-DOS machines have Windows is because that's your Right-Brain on
drugs.  VR, being a logical and creative progression of modern
interface, has looked very Right-Brain so far, leaving no tools to
quantify design.

Pull-down menus are a function of READ.  Click buttons are a function
of WRITE.  Sliding gadgets and other interactive movements are
functions of MODIFY.  (Perhaps READ should be split into READ and
BROWSE, the first selecting a specific target, the second just viewing
the scenery.)  Simple, Yes?

Whadda Y0U think?
.--------------------------------------------------.----------------------.
|Internet:twisty@tso.uc.edu       Cincinnati, OH   |  ________O__________ |
|GEnie:TWISTY                      -  +#!$+/  -    | /  |       __ +-     |
|                               Joel 'Twisty' Nye  |    || | ||(__ | \  / |
|* animator * composer * illustrator * programmer *|    | \^/ |___) \ \/  |
|*  cyberspatialist  *  and  all-around-nice-guy  *|  \_______________/   |
`--------------------------------------------------^----------------------'

-- 
////twisty@tso.uc.edu      +#!$+/      Cincinnati, OH /.--+--'  O ___+-- 
///                  Joel 'Twisty' Nye               / '  || | ||(__ |  / /
//* animator * composer * illustrator * programmer */     | \^/ |___) \ \/
/*  cyberspatialist  *  and  all-around-nice-guy  */  \_________________/