[sldev] [META] There are multiple infospheres (Was: From Browser
Wars to Virtual World Interoperability)
Argent Stonecutter
secret.argent at gmail.com
Sat Nov 3 19:36:32 PDT 2007
On 03-Nov-2007, at 16:34, Lawson English wrote:
> Zha Ewry's take on this, as I understand it, is that the AWG should
> be using existing web technologies as much as possible when
> designing the future meta-grid, or even LL's more limited 60
> million sims LL-compatible grid. This doesn't make the SL viewer a
> web browser, of course, but helps make it conceivable that it can
> run anywhere a web browser can.
First, whether it runs everywhere a web browser runs isn't really
relevant... if it's anything similar to a virtual reality it's still
going to be a "spacial" environment. You might log in using a limited
interface in a public library, but you'll still be in a place, your
avatar represented on the high end systems of people who are in that
place too.
Second, I believe they should use appropriate existing web
technologies when possible, sure, but that raises the question of
whether HTML (as currently represented by web browsers) is an
appropriate technology for a 3d VR environment.
Some kind of virtual reality modeling language (in the generic sense,
hence the lower case) needs to be developed, but that language needs
to be something that both simulators and viewers operate on... both
for geometry description and for scripting.
Accurately displaying highly structured and intricately laid out text
on a surface is not nearly as important as efficiently and (within
the limitations of the display) accurately displaying 3d geometry
containing hundreds of surfaces.
As for scripting, even ES3 is almost certainly too heavyweight for
any code that's to run on the servers. People pooh-pooh LSL, but it's
a lot bigger a language than I'm used to using for virtual worlds.
I implemented a compiler for a real-time control language over 20
years ago. It was designed to replace relay ladder logic for
scripting extending real-time control software for oilfields, and to
ensure that it was safe it didn't even provide loops... if you wanted
to do something repeatedly, you scheduled it to repeat. That way
there was a hard limit on the amount of time your code would run
before returning to the main loop. The target language was Forth.
Everything was triggered by timers and external events, like LSL, but
those events included a subset of the expression language. You could
trigger an event when set_point_1 exceeded some value, for example,
so that test would be run every time set_point_1 was modified. The
code was all in Forth (compiled from a user-friendly high level
language), with the tests in table-driven assembly in the hardware
drivers for the measuring devices. Very fast stuff.
I don't think anything quite that limited is required today... that
code has to run on an 1802 microprocessor with 12-48k of memory
shared between the real time control system, the Forth interpreter,
the user-interface code, and all the custom control code provided by
us, our customers, and the end-users. The 1802 was a 4/8 bit CPU with
a clock that ran from DC up to 500 kHz. Yes, a 1/2 MHz CPU.
But that's still within an order of magnitude of the share of a
server's resources that should be available to any given asset.
More information about the SLDev
mailing list