lbsa71.net Just another WordPress weblog

On Multi-protocol

From the Not-Invented-Here Dept. 

With the recent breakthroughs in OpenSim with (theoretically) supporting multiple protocols, the question of 'How do you transfer Object of protocol X over protocol Y' and 'how do you change SecondLife(tm) prims into MXP objects and vice versa?

I got a revelation the other day that "Maybe you don't".

 One of the problems with any viewer approach is that any multi-protocol viewer has to support a multitude of protocols to be interesting. Very much a discussion like the one on video streaming and video streaming clients.

So, I propose the following;

On the server side, all objects are stored natively; Second Life compatible Objects are stored as that, X3D objects as X3D objects, and MXP objects as MXP objects.

They collaborate on the server by exposing the same set of behavioural functions (Exposing meshes for the Physics engine, and functions to add, move and change some basic set of attributes) 

All protocols are implemented as "codecs", on the server side they will very much look like OpenSim 'modules'; these codecs

a) set up protocol-specific endpoints for native clients

b) register factories to create protocol-specific instances of core objects

c) register abstracted endpoints for multiplexed transfer over what I chose to call the "Real Time Scene Transfer Protocol"

On the viewer side, each protocol is also implemented as a 'codec'; here, the codec is responsible for implementing the transformation of protocol-specific stream data into scene changes.

Now, when a client connects to a Scene, it has the choice of connecting to a native endpoint, or to the RTSTP Endpoint

If it connects to the native endpoint, it will use only that codec, which means all scene changes will go thru that protocol, and the server codec will do its best to transform content from one protocol standard to another, optionally by chaining other server codecs.

But; if it connects to the RTSTP Endpoint, it will be served a stream that is a multiplexed interleave of the output of the different protocol payloads.

If a new object should be created, it's ether going to be recieved as an SL UDP ObjectAdd Packet payload or thru an MXP Object add - depending on what type of object is added on the server.

The Stream Demultiplexer then splits the packets and sens them to the according codec, which is then responsible for adding it to the viewers local scenegraph for rendering.

One central point is that the native endpoints should probably implement the same interfaces as the multiplexed payload endpoint, so an SL EndPoint should be split into the SL UDP Transport layer and the SL Packet layer, where the native endpoint would use one, and the RTSTP multiplexer the other.

The control stream, ie, the information of user intentions, like keyboard presses and avatar navigation, can (probably?) be thought of either being multiplexed into the various protocol tunnels, or as a separate 'control pipe' funnel.

Of course, all this is very half-baked, and I'm definitively not the man to start drawing up formal proposals. I just realized I had a solution for what I foresee as a very real problem in a multi-protocol multi-standard 3D client-server model. In essence, you need a network transfer, a session, an interleaved stream and the different content streams

So, anybody has good already-existing protocols to handle this? SIP or RTSP to negotiate EndPoints configuration? OGG or Matroska for stream interleaving?

Best Regards,

Stefan Andersson aka lbsa71

Hacking Trees

From the Under-the-Hood dept.

Today, I thought I'd show you how to attach a LSL/OSSL script to a tree, and in the process touch on some interesting concepts.

The first thing you need to know is that tree and grass are really just prims with a special 'PCode' that tells the viewer to render them differently. In theory, you would be able to attach scripts to trees and grass in Second Life™ - with OpenSim, theory becomes practise!

• set up an empty region
• create a Tree, call it 'My Tree' or something so you can identify it later
• create a Box, call it 'My Box'
• create a script in the box, call it 'Tree Script'.
• on the opensim region console, issue the command
  save xml2 test.xml
• the file will be saved in the OpenSim root /bin directory as test.xml. Open it up, preferrably, in an xml-savvy editor for readablity.
• inspect the xml code. It's a mouthful, but after some careful scrutiny, you will start to understand some of the nodes. You're now looking at the under-the-hood representation of objects in OpenSim, which incidentally is based on the binary data protocol that the viewer and region uses to communicate. Doesn't look anything like the numbers you see in the edit object tabs, right? That's because the viewer is trying to present stuff in a way that you as a user will feel more familiar with.
• Now copy the full <Shape>...</Shape> node block of 'My Tree' and paste it over the full <Shape>...</Shape> node block of 'My Box', replacing it. This is the tricky part, but done right, you've replaced the box shape values with the tree shape values, turning the box definition into a tree definition.
• Save the modified test.xml file to disk.
• Delete 'My Box' and 'My Tree' from the region, making room for importing the new hacked versions.
• Issue the command
  load xml2 test.xml
• Hey Presto! You will have two trees, probably of wildly differing sizes. (If so, this is because the <Scale> of 'My Box' was different from that of 'My Tree'.)
• Now, right click on 'My Tree', and chose 'Open' (not 'Edit'!) from the Pie menu - In OpenSim you can actually Open the contents of a tree - in Second Life™, this pie option woul be grayed out. In 'My Tree' the content is empty.
• Now, right click on the tree called 'My Box', and chose 'Open' - we still have our script there!
• Now, script away, you can basically do anything with the tree/grass that you can do with any other prim - set the params, size, position, communicate, do http requests. Go wild!
• Here's a little demo script to get you started: it toggles the tree position and size every second, while saying 'timer' every tick.

integer toggle = 0;
default
{
    state_entry()
    {
        llSay(0, "Script running");
       
        llSetTimerEvent( 1.0 );
    }
   
    timer()
    {
        toggle = 2-toggle;                      

        float newval = toggle + 3;                      

        llSay(0, "timer");
       
        list rules = [ PRIM_SIZE, < newval, newval, newval >, PRIM_POSITION, < 128+newval, 128+newval, 30+newval >];
       
        llSetPrimitiveParams( rules );
    }
}

• You can now take this object to inventory, clone it and give it to your fellow man.

For extra credit:

• The <State> field of the tree prim represents the tree type*.
• Explore changing the TextureEntry, Particle Systems, SculptTexture, CollisionSound of a tree - does it do anything? Please report back to me.
• What with defining sit targets, attaching to link sets, defining touch_start() events? Can you find a way to interact with the trees in interesting ways?
• Can you add other objects into the content? Make a wishing tree where people can actually 'Open' the tree and pillage the goodies?
• How about "Megatrees"? Find the <Scale> nodes and create a 100 meter Tolkien forest? (There are two but only one of them needs changing, figure out which)
• What fun can be had with 'grass'? (Create and save 'My Grass' and inspect the xml.)
• How would one go about to export the scripted trees to other grids, where you don't have console access?
• Is there an even simpler way to do this? Can Prims Rez trees from inventory, give them active scripts, and if so, can trees Rez their spawn? Please report back with your findings, or blog about them.
• Take screenshots of the steps along the way, and send them to me so I can illustrate this article better.

Thank you for taking your time reading all of this. I hope that you have learned at least something about Prims, Trees, Grass, Love, OpenSim, the xml2 format and life in general.

Best regards,

Stefan Andersson aka lbsa71

*       Pine1 = 0,
        Oak = 1,
        TropicalBush1 = 2,
        Palm1 = 3,
        Dogwood = 4,
        TropicalBush2 = 5,
        Palm2 = 6,
        Cypress1 = 7,
        Cypress2 = 8,
        Pine2 = 9,
        Plumeria = 10,
        WinterPine1 = 11,
        WinterAspen = 12,
        WinterPine2 = 13,
        Eucalyptus = 14,
        Fern = 15,
        Eelgrass = 16,
        SeaSword = 17,
        Kelp1 = 18,
        BeachGrass1 = 19,
        Kelp2 = 20

Working with the Hypergrid

A recent and exciting development in OpenSim is support for what is called 'hypergridding' or 'hyper-linking'

In effect, what it does, is just to let avatars ('guests') teleport into 'foreign' regions (on other grids) and in the process inform the target region where to look for inventory and assets for that guest - in theory, allowing for free teleports between grids.

Now, how have drm issues been solved, you wonder? The short answer: "we haven't".

As of this moment, you are adviced to think of 'hypergridding' as one big security and drm vulnerability. It is actually the very lax security of the OpenSim OGS protocol (Open Grid Services) that has allowed for the hypergrid to emerge.

It still has some heavy benefits, but more in the 'weak protection needed for loading a webpage' corner than the 'strong protection needed for participating in interchange within an economic system based on artificial scarceness' one.

So, how would you, as a grid owner, concerned for your users, work with this? I suggest something like this;

First of all, set a completely isolated Hypergrid standalone DMZ 'island' up parallell with your 'main grid', like thus:

By specifying gridmode=false in your OpenSim.ini and setting the standalone region to use a private database in the [Standalone] section.

Make sure you specify/create an dmz region 'master avatar' on startup, otherwise you will not have any account with permissions to modify the region once it's up. If you just start the region up from scratch, the startup procedure will ask you to create a master avatar account. Choose a strong password.

What this setup gives you is the opportunity to start trying hypergrid interlinking out, while ensuring none of your main grid data or content leaks out. Again, if you decide to use a shared database server, make sure you specify a new database clearly separated from your main grid database on that server.

I would suggest you create what I call a 'storefront' on this region, non-drm sensitive demo and pr content that ushers prospective users onto to your main grid through the grid registration page. The point here is to keep the hypergrid region air-tightly separated from your main grid whilst still allowing you to expose content that people can make part of their own grids. A '3D banner exchange program', if you will.

Do note that the only way to work with or access this dmz region is to either log on as the specified master avatar (if you specified one) or to hyperjump into it. And the only editing options is either to log on as the master avatar, or to turn perms off.

After familiarizing yourself with the hypergrid, we can start thinking of how to start sharing user data and content with the main grid, whilst retaining basic drm security. This I will cover in my next 'Working with the Hypergrid' blog.

(If all this sounds interesting, but you don't have a clue as of how to do all this, visit the opensimulator.org web site, join the #opensim irc channel on freenode, or send me an e-mail.)

OpenSim turns two

The 3D Application platform Open Simulator, or 'OpenSim' for short, turns two years old January 29th 2009.

The consensus is that this date 2007 OpenSim was 'born' when Darren Guard (aka MW) made his prototypical C# 3D world server publicly available.

You can help celebrate this joyous occasion in a number of ways;

• Read OpenSim History for some recap of the early days, and help continue documenting it.  
• If you're in the position to run a region or grid, or already do, this is an excellent opportunity for you to further OpenSim and yourself by 
  • taking the opportunity to demo and publicize noteworthy services or content.
  • set up what we call a 'hypergridded dmz storefront' - in effect, a public standalone region not connected to the main grid services - and be part of the hypergrid link-fest
  • blog about this joyous occasion, draw attention to OpenSim, the second birthday, and tell your own OpenSim story.
  • set some demo content up, demoing your grid and what's going on there
    • establishing a media parcel url going to a live voice feed so that you could hold voice demonstrations, dj sessions and panel discussions on topics relevant to your grid.
    • some avatar appearance/merchandise items that you are ready to give to the public domain
• Attend the party, dressed to kill, socialize, go hypergrid club hopping, generally helping out and enjoying what will still be referred to in the history books as 'back in the early days of the 3D web'!

This is a great opportunity to acquaint yourself with OpenSim and what it means to run a region, optionally hypergridded - and we hope to see lots of cool stuff happen and scare a bunch of ugly bugs out of their holes in the process!

Regardless,

If you're planning on doing anything for OpenSims second birthday, be sure to post it on

http://opensimulator.org/wiki/Second_Birthday

If there is no heading suitable for your project, just make one - it's a wiki!

Love,

Stefan Andersson aka 'lbsa71'