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