[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