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

Text File | 1992-07-22 | 5.8 KB | 141 lines

Newsgroups: sci.virtual-worlds
Path: sparky!uunet!wupost!gumby!destroyer!ubc-cs!uw-beaver!news.u.washington.edu!milton.u.washington.edu!hlab
From: [e-mail] (Bob Pendelton)
Subject: Re: TECH: My standard is better than your standard.
Message-ID: <[e-mail]>
Originator: [e-mail]
Sender: [e-mail] (USENET News System)
Organization: HaL Computer Systems, Inc.
References: <[e-mail]>
Date: Tue, 21 Jul 1992 19:57:13 GMT
Approved: [e-mail]
Lines: 127



From article <[e-mail]>, by
[e-mail] (Jeremy Lee):

> In article <[e-mail]> Bernie writes:
>
>>In article <[e-mail]> [e-mail] (Bob
>>Pendelton) writes:

> No. "worlds" per se don't exist in my model. Only objects do. If a
> group of objects decide to assosciate, then you can call that
> assosciation a "world", but it still doesn't really exists. Message
> routers should be completely transparent, and should have no bearing
> on the objects.

This sounds good. But it creates it's own set of problems.

> You can't rewind it. It's a non-deterministic system.

Some applications can live with non-determinism, some cannot. Define
your application.

>>I'm not sure that's practical, but I think further discussion is
>>needed.
>
> You can't really scale time. It's just not practical. the system will
> run at the speed it wants. You can't make it go faster, although I
> suppose you can make it go slower.

There are at least 3 different flavors of time involved. There is real
time, the time that you and I experience. There is process time. The
time that it takes to get next frame up. And there is model time. The
time unit used in the world we are simulating. I very well might want
to require the system to present a new frame 30 times/second and map 1
nanosecond of model time to 1 second or real time.

Real time cannot be changed. Process time can be changed by
simplifying the model, reducing detail, or by buying a faster system.
Model time can be set to anything you want.

I very well might want to require the system to present a new frame 60
times/second and map 1 nanosecond of model time to 1 second or real
time. It might not be able to put in all the detail of all the objects
at that frame rate. If I don't like it I can lower the rate. That's up
to me as a customer. The model time is picked by the model builder and
my be vital to the proper operation (techinical or aesthetic) of the
model.

Again, there are many different applications for VR.

> 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?

Allow the object to decide how to scale itself to the world. How else
am I going to put a representation of myself into the insides of a
virtual single celled animal?

>>>>  How do we ensure that a given color looks the same to
>>>>  everyone?  Does this even matter?
>>>Yes, it matters very much. Take a look at Xcms in the X11R5 release.
>>
>>I guess what I meant was more like "you see the color blue one way, I
>>see it in another, but we both agree it's blue and that it's darker
>>(or lighter) than another shade of blue; does the actual color really
>>matter?)"
>
> Irrelevant.

To you, perhaps. To most of the television viewing public, perhaps.
But if you are doing virtual art or advertising you might get pretty
picky about the colors.

The fact is that there are many people who care very much about the
color looking the same from station to station. They also want to be
alble to print pictures with the same colors and to create physical
models with the same colors.

>>>I'd say that solid geometry is the most general.
>>
>>I agree.
>
> So you are ruling out all special cases?

Absolutely not. I'm very well aware of the costs of doing different
kinds of rendering and the performance gains you can get by using the
representation that is correct for your hardware.

I just said that you can (with much effort) generate those different
representations from the solid geometry of the objects.

>>>I like the idea of structuring it more like an air traffic control
>>>system. You have a bunch of routing centers (called routers) that
>>>control the propagation of messages. Each world has at least one
>>>router. But, a world can be made up of multiple routers that each
>>>handle specific regions of the world. It only gets messy at the
>>>boundries between regions. The collection of all communicating routers
>>>is called a universe.
>>
>>This sounds very, very good to me.
>
> 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.

No, I'm not restricting anything. I'm making it possible.

For two objects to communicate there must exist a reliable
communication path between them. A router simply sets up that path.
Depending on the physical network involved the router may be involved
in the actual transmission of the messages.

A router also serves as a convenient first contact point for an object
that wants to enter into communications with a group of objects.

                                Bob P.
--
Bob Pendleton             | As an engineer I hate to hear:
[e-mail]              |   1) You've earned an "I told you so."
Speaking only for myself. |   2) Our customers don't do that.
                   <<< Odin, after the well of Mimir. >>>