If so, is it possible to save files to DXF format or ANY other format
besides Infini-D?
I just got this program and I dig it A LOT. I want to use it, so I hope I
won't have problems converting.
jeff ~~~~~~~~~ Sherwood@Usc.Edu http://www.usc.edu/dept/etc/sherwood/
Professed Netscape User
The InterVerse is Upon
Us!!!!!!!!!!!!!!!!
Date: Thu, 20 Apr 1995 16:25:02 -0600 (CST)
From: "Andrew C. Esh" <andrewes@cnt.com>
To: "Joshua M. Thompson" <invid@msen.com>
Cc: vrworlds-list@netcom.com
Subject: Re: VRML usage (from www-vrml@wired.com)
On Wed, 19 Apr 1995, Joshua M. Thompson wrote:
> At 4:01 PM 4/19/95, Mark Waks wrote:
> The case that pops into my mind right away is this : I've got twenty people
> to update, and half-way through sending out updates, something happens (my
> net link has problems, my browser crashes, whatever). Now you've got two
> sets of browsers with two (possibly very different) views of the world.
This is a common problem with IRC, which is why there are so many lags
when a lot of people are trying to talk. It reminds me of a study that
was on on the Tokyo Subway System (I think it was Tokyo). They cam to the
conclusion that the only way to achieve a 100% on-time arrival rate of
the trains is to not stop to pick up passengers.
The Internet is inherently asynchronous, and so it will have lags. It's
unavoidable, due to the design of the system. There is a caveat to this,
as explained below.
> >I suspect we're not going to have any choice in this. Consider: when
> >VRMUDs get serious, we're going to want full-conversation audio. Do we
> >*really* want all that audio funnelling into the server, and then back
> >out again? I know that *my* machine (a high-power PC) wouldn't be able
>
> Of course we wouldn't want that. But, losing a few seconds of audio is a
> bit different than losing an important change to the layout of the world
> because the browser that originated the change never finished sending it
> out. Real-time audio doesn't change the world permanently, so if you lose
> some audio information it isn't a big deal.
I disagree. Remember the 1/4 second delays that occured on telephone
conversations that were carried across geosynchronous satellites, back in
the early 80's? Notice they aren't using that system much any more? It's
because customers got tired of interrupting each other, and signed on with
Long Distance companies which provide Earth based (Land Line) systems
which have no lag. Imagine what multi-second gaps would do to a
conversation. Look what they did to Richard Nixon's presidency. :)
> >No, when we start getting into this sort of high-bandwidth application,
> >we *have* to abandon the traditional models wherein the server does
>
> Distributed is definately the way to go. It's where the computer industry
> itself seems to be heading these days as well (System 7 Personal File
> Sharing, Windows for Workgroups, Personal Netware, etc.)
I suggest we consider a Broadcast Server configuration. The user sends
control changes via a low bandwidth channel (like the Internet, or a
direct modem connection). The Server updates the space on the fly, and
broadcasts it via a high bandwidth system like Cable TV. The data is
received by the client, and is used to update the display, and provide
the audio, just like TV. Since the broadcast is not distributed on a
mdium which has to allow other stations to gain access, it will not
suffer from the asynchronous problems that the Internet does. The only
thing which could be lost is one client's updates to the server, and that
customer is the only one who'll notice. If the customer has a
Point-to-Point synchronous connection direct to the server (modem line,
ISDN), then even the customer updates would be almost lossless. It's as
simple as the system used when you phone into a TV talk show.
> [ Yep we're getting off topic. We really need another mailing list where
> those of us interested in this matter can discuss it in parallel with the
> main VRML discussion. ]
That's why I'm over here. Hope you're here too.
--- Andrew C. Esh mailto:andrew_esh@cnt.com Computer Network Technology andrewes@mtn.org (finger for PGP key) 6500 Wedgwood Road 612.550.8000 (main) Maple Grove MN 55311 612.550.8229 (direct) <A HREF="http://www.mtn.org/~andrewes">ACE Home Page</A>