Tag Archives: opensim

Thoughts on the Ideal OpenSim / SL browser

There has been a lot of work in the last few days in different directions for OpenSim / SL browsers.

I started playing around with Hippo Viewer, which has very nicely let me convert a bunch of my test environment to mega prims. So much nicer than large link sets. In the process I started thinking about all the ways in which people are making changes to the SL client to suit their needs. A non comprehensive list of items people seem to want to change are as follows:

  • prim policy – how big can a prim be? how many can be in a link set? What’s allowed to be physical? What are the limits for attribute changes (like % hollow).
  • appearance policy – what modifications can the client make to their appearance. (for 2nd graders Rich removed the “take of clothes” option)
  • url references – where does the search box go to? where does the front page go to?

If you start looking at these you see a theme. All of these are decisions that the server really wants to make (so it gives the control to the grid opperator), but that today are hard coded into the client. So much of what exists in the Second Life viewer today is a shared construct between the server and client. An understanding.

But as we extend past the 1 use case of Second Life (or the 2 if you include Teen grid), we find that the policy created for that one use case falls pretty short when creating different use cases of the underlying technology. By default, it means that users are having to dive in and change the client if they want to do something different. Fundamentally they are gutting the Second Life ™ use case out of the Second Life open source client code. As a side note, we’ve tried really hard in OpenSim to keep the use cases out of the platform so that many conflicting ones can be implemented. While not always successful, the multitude of uses that you can see on Planet OpenSim show we’re doing at least fair to middling on that front.

A few features of My Ideal Viewer

So, back to a few thoughts on my ideal viewer, and what it would do. I have no allusions we’re going to get there any time soon, but it doesn’t hurt to write down a few thoughts:

  • Cross platform. If it doesn’t work on Windows, Mac, and Linux I don’t think it will have any real chance of being univeral
  • URL bar. We keep talking about this a being ubiquitous browser like experience. Imagine if Firefox didn’t have a URL bar. Having ogs://osgrid.org/Wright%20Plaza/128,128,22 do the right thing is really important. I can put that link in a webpage, or IM it to someone. And all the addressing scheme needed is there.
  • Don’t do auth up front. One of the issues with the viewer today is that you have to put in account information before you can ever have your first conversation with a simulator. Why? HTTP defines a way to ask for auth later. If we talk about moving between grids we need to have the ability to do that. It also raises the question of not asking for auth. Some times a read only pseudo anonymous view of the app is appropriate, but that’s hard to do today.
  • Let the server define more policy. Once you are connected to the server it should be able to tell you:
    • Various relative applications urls (search, money, map, etc). The non existance of these urls means turning off the feature.
    • Limits for the environment. This include build policy (i.e. size of prims), appearance policy, and any other policies you’d like to define. These would of course be server side enforced, but letting the client know what the min / max values of dials should be would be a huge help (and let you have a single viewer work for SL, osgrid, and thousands of different 3D apps built on top of OpenSim).
  • Content plugins for the viewer. One of the things many people want to do is experiment with different types of content integrated into the environment. One of the massive wins for HTML was letting you embed anything as long as you specified a mime/type. And one of the big wins for netscape was defining an interface where you could write a plugin to handle foreign mime/types. You would need at least 2 types of content plugins. A surface content one and an object content one (i.e. 3D content in a different format). This is a good place where the SL use case runs against many others. People want to define a surface as an off site image url, but this breaks part of the SL use case in charging for content uploads.

These are by no means a comprehensive list of what I’d like to see, but it is a flavor. The power of the technology with a viewer that is that flexible would be incredible, and the number of use cases it would be applicable to would be way what can be supported today without digging in and modifying the code yourself.

Comments always appreciated, even if you think I’m just a moron for what I’ve said here. I’ll be traveling a bit over the next few weeks, so if I don’t get back to you quickly, it’s not you, it’s me being on the road. And, as a reminder, these views by no way represent my employer, they are mine alone. 🙂

The next stage in OpenSim community growth – OpenSim Forge

The OpenSim community is one of the most vibrant open source communities that I’ve had the pleasure to be a part of. We’ve got an active set of core committers, an active set of more casual developers constantly providing bugs and patches to the project, and an incredible active set of users that are testing nearly every checkin out there. This kind of community is really too big for one project. Many of things things the community is interested in doing around OpenSim, like alternative grid servers, or admin web interfaces for opensim, are great things, but don’t really make sense in the scope of the main OpenSim source tree. Many of these early efforts set up sourceforge projects, but it was sometimes difficult to find they existed.

Welcome OpenSim Forge!

Adam
brought up the idea of setting up a gforge instance for OpenSim a few weeks ago, and things started rolling from there. Adam did all the leg work on this one, so many props to him and his team.

OpenSim Forge is a site for hosting OpenSim related open source projects. All projects must be under an OSI approved license. BSD license is encouraged, as that’s the license of OpenSim, but it isn’t required. The point is really to just be a one stop shopping for opensim related code, and to make it very easy for anyone that is interested in adding to this community to have a place to stick their project and get visibility.

In the 10 days since the site went live, we’ve got 10 public projects already registered, plus a few more in the queue. Now, I don’t think the 1 new project a day pace is going to keep coming, but as can clearly been seen the OpenSim community is bigger than just the OpenSim project. Here’s what we’ve gotten already up on OpenSim Forge:

  • 3 administration tools for OpenSim (2 web and 1 console)
  • 2 alternate grid servers (ASP.NET & Perl)
  • 1 project for patches to OpenSim (the Open Grid Protocol enablement patches)
  • 1 experimental viewer for OpenSim (not based on the SecondLife client)
  • 1 opensim based application (done via Application modules) which is astro physics simulation
  • 1 opensim test suite
  • 1 tray launcher for OpenSim

It’s a very powerful thing once a community grows beyond it’s initial boundaries, when it truly takes on a life of it’s own. I think the quick uptake on OpenSim Forge shows we are definitely at that point. I see this as a new stage of growth in both the community and the project, and what an exciting stage that is.

Speaking at Linux World on OpenSim

If you are in the San Francisco area in early August, I’ll be giving a presentation on OpenSim at the Linux World Conference. Our local linux users group got a preview of that talk this past week. For the talk I started up an OpenSim instance on my laptop and let everyone with wireless and a capable video card connect to it, with much hilarity ensuing. It worked so well, that I’m definitely going to include that portion in my talk at Linux World.

If you are going to be around there, let me know. I’d also love to meet up with OpenSim folks in the SF area during my trip out.

Why is there no “No drop permissions” bit in SecondLife?

I’ve been thinking a lot about the way the implementation of SecondLife has created a very specific culture in that environment. One of the issues SecondLife is currently having in expanding scope, is that culture makes some things easy, some things hard, and other things impossible. The technology is never impossible, but meeting the needs of the residents of can be. I’m going to start posting some of these “what if” bits on the technology here under the opensim and secondlife tags, please feel free to jump in and discuss.

The Permissions System

The SecondLife permissions system is a curious thing:

  • No modify
  • No copy
  • No transfer

The model provides the ability to let people create modifiable, but un resellable goods, or prevents a good from propagating. What it doesn’t really do though is encourage Creative Commons content. Most creators that create “full perms” objects, find that someone takes a copy removes some of the permissions, then sells it elsewhere.

There has been a lot of arguments that a CC model for content creation can’t work on grid scale, but I don’t think it’s been given a fair shake. If you really wanted to try this experiment, you’d need another bit (at least one more) which was:

  • No drop permissions

Doing so would let you put content into the environment that has the Modify / Copy / Transfer bits enabled, and no down stream person could turn them off. “I gave away this thing, and want it to be part of the commons. Anyone can have it, but also has to keep it in the commons.” To support this kind of model building content on the main grid, Linden could even remove the upload cost for NDP content, making it a richer world for all.

The recent trend to do public works projects in SecondLife, paid for by the Lindens, means there is definitely some need for a commons space. Perhaps expanding the permissions model to keep free content free would do some of this on it’s own.

Adding stock scripts to OpenSim

Mo Hax and I have started a weekly effort to gather up some of the IBM internally created OpenSim / Second Life content and contribute it to OpenSim as stock content. As OpenSim approaches the 0.6 release, it would be good to have some more reasonable stock content included for those people that aren’t Second Life Heads, and have huge inventories of their own stuff sitting on their disks. The results of week one was a single handshake animation, and a lot of understanding on how our stock content system works, and how it should be changed to make it easier to contribute to it.

Yesterday, in between builds and meetings, I decided to refactor a few LSL scripts I had that used unique OSL functions that let you dynamically create textures on objects, both from text drawing commands, and from images of the internet. Those are all now in the OpenSim Library, and accessible for anyone in world. They are under the same license as OpenSim, so do what you will with them. 🙂 (Note: I’ve found the client caches the inventory trees, so you’ll need to clear cache before they show up.)

The scripts contributed yesterday are as follows:

  • osTextBoard – a text board I wrote to do agendas or note taking in world. Modify the script, hit save, and you get the content in your text board texture. Multiple font sizes, colors, and names are used.
  • osWeatherMap – a 3 panel cycling weather map for US weather. This is inspired by the work nebadon did on osgrid.
  • GrafittiBoard – Justin Casey’s GrafittiBoard (as seen on osgrid), which is similar to text board, but has an llListen hook so that if you talk on channel 43 it displays it on the board.

Consider all of these as launch points to more complex things. But, they’ll at least give people a flavor of what is possible. And you’ll get it with every opensim build.

Sculptie Physics in OpenSim

In secondlife sculpties only collide on bounding boxes, which make them really only suitable for visuals, not for part of complex builds. Due to some early work done by Teravus this week, that’s no longer true for OpenSim. We’re now creating a tri-mesh collision surface for sculpties and passing that into our physics engine. This code is young (only a week old), but you can see a demo of results below.

Sculptie Physics on OpenSim from Dahlia Trimble on Vimeo.

llTargetOmega in OpenSim, an epic journey in OpenSim prim updates

A few weeks ago I had an email conversation with Dale Innis about llTargetOmega support in OpenSim. This script function lets you set the angular velocity on a prim, which the client then interprets and displays spinning objects. It is not guarunteed to be synchronized between all clients, but it provides a rather useful visual effect regardless.

llTargetOmega didn’t work for us a week ago, which confused me, as I saw that in the LSL portion of our code it was doing exactly the right thing and setting the angular velocity correctly. I should work, but it didn’t. In the lack of it working people were setting fast timers that pushed out rotation updates. This caused a lot of extra load on the server, and was really the wrong approach for this.

Take 1: Terse Updates

OpenSim has 2 paths to sending information about Prims to the client (we’ll get to the first one later). Terse Updates are a small update packet that contains just a bit of information on updated textures and some of the vectors used to establish prim position, velocity, acceleration, rotation, and angular velocity. When a prim is updated in the environment, Terse Updates are used to tell all the other clients about that change. One of the heavy users of the Terse Update path is the physics engine, as all the vectors the physics engine changes are in there. We’ve seen a lot of work on the Terse Update path as physics have gotten more and more tested.

On Tuesday I finally dug in and traced our Terse Update path, and found an interesting thing. When the object was physical (i.e. movement coming out of the physics engine) we did the right thing for Terse Updates. When it wasn’t, we hard coded all the velocities to zero. So even if things were rotating, any time we sent an update we’d stop them.

Author: sdague
Date: 2008-05-06 15:17:00 -0700 (Tue, 06 May 2008)
New Revision: 4543

Modified:
trunk/OpenSim/Framework/IClientAPI.cs
trunk/OpenSim/Region/ClientStack/LindenUDP/LLClientView.cs
trunk/OpenSim/Region/Environment/Scenes/SceneObjectPart.cs
trunk/OpenSim/Region/Examples/SimpleModule/MyNpcCharacter.cs
Log:
send actual velocity and angular velocity in terse updates
instead of hardcoding to zero when the primitive is non physical.
llTargetOmega should work now.

Ok, so life is good, the issue is fixed, and we move on.

Except… it wasn’t.

CSI: OpenSim, getting to the bottom of this

At this point a whole bunch of people on the IBM side jumped in. Mike Osias had a build that was on it’s knees due to use of fake rotation, so he had all the good test cases, and opened mantis 1166. I’m not a scripter, so I needed some examples to know what should work. Alan Webb started to dive in and try to figure what was going on as well. I figured I’d spend an hour on it to try to figure out where things were at before getting back to avatar appearance bits.

After abount an hour Alan and I started comparing notes. The code in this area is extra confusing because we’ve got 2 vectors for angular velocity. An, no, they aren’t actually different in any real way. Lots of people have tried to rationalize that they do different things, but they don’t. This is cruft, and is part of what happens in an organically growing open project. The AngularVelocity / RotationalVelocity thing an opensim appendix, and should be surgically removed at some time in the near future.

But the behavior was even odder. I could set llTargetOmega on an object, and it wouldn’t move. Then I’d touch it, and it would. I got Mike into my test environment and was looking at a spinning cube.

“Ok, you see that cube spinning?”

“No”

I grab it and move it. “What about now?”

“Yes, spinning now.”

At this point I was confused a lot. Why would that be?

Take 2: Full Updates

I said there were 2 ways of a client finding out about prims, and this gets us back to the first one. In addition to Terse Update, there is what we call Full Updates, which are really just the full prim definition being sent down the wire. This is everything we know about the prim. This packet is also marked as reliable, to make sure the client doesn’t drop it (terse updates are droppable).

And now we get back to organic code bases. One of the big activities since October was working physics in opensim. Lots and lots of work were spent on Terse Updates. Very little work was spent on full updates. It turned out that Full Updates were always hardcoding all the motion vectors to zero. The SendPrimitiveToClient function predates both physics and scripting by months. In a pre-physical opensim world passing the motion vectors didn’t make any sense, as there wasn’t anyway to set those values. The code worked well, so no one was really looking at it again, at least not in this specific area.

TerseUpdates (sent on minor prim movement) would make things spin. Full Updates (sent on initial prim rez, or after calls to osSetDynamicTextureURL) stopped the spinning. My earth projector turned out to be the perfect test case for this once I added rotation to the globe.

Originally I was going to punt on this and leave it to someone else, but then the thrill of the chase got to be too much. But there was one problem. This information is sent to the client in a 60 byte array, with basically undocumented positions. It was easy to fix terse updates because someone had already sorted it out, and I just needed to copy the decoding pattern there. For FullUpdates, it was more of a trial and error approach, represented by a series of checkins, reverts, and new attempts.

You know what happens when you get that array wrong? Spectacular fail. 3/4 of prims aren’t in the right place, and touching an image board (user of osSetDynamicTextureURL) makes it fly away to some other part of your sim. Maybe in space. I eventually figured out a workable serialization:

Author: sdague
Date: 2008-05-07 12:44:22 -0700 (Wed, 07 May 2008)
New Revision: 4566

Modified:
trunk/OpenSim/Region/ClientStack/LindenUDP/LLClientView.cs
Log:
seriously hope this gives us rotation and rotational velocity

As you can see, I was getting a little punchy on changelog entries.

So we’re done and fixed, and back to work…. well not quite.

Take 3: Deselected Objects

When you edit an object the client stops it’s motion, as nothing would be more evil than trying to edit an object that is flying away from you at 60 m/s. When you’ve deselected the object it tells the server. But the object is stopped. The client needs to be told again that it is spinning. I got that critical information from melanie on IRC, which was enough to pass on the buck.

We had Mike almost working, and Mike is no slouch on our code base (he’s sent in a couple dozen patches in the past), so I flipped this one back to him with “we’re almost done, but you’ll need to find the right place in the deselect path to generate a Terse Update. Then I think we’ve got full llTargetOmega support.”

A day later Mike sent in this final patch:

Author: sdague
Date: 2008-05-08 05:48:29 -0700 (Thu, 08 May 2008)
New Revision: 4585

Modified:
trunk/OpenSim/Region/Environment/Scenes/Scene.PacketHandlers.cs
Log:
From: Michael Osias <mosias@us.ibm.com>

Patch to schedule terse update on deselect, specifically so llTargetOmega
sets rotational velocity on deselect.

This should complete our llTargetOmega support and fix:
http://opensimulator.org/mantis/view.php?id=1178

And now. For real. llTargetOmega works.

Final Thoughts

Avartar Appearance as a User Service isn’t coming this week, sorry folks. The above epic took much of my hacking time this week. It was a pretty solid educational experience for me in the way we actually communicate the contents of the Scene to the client, which was good to learn after a year on the project. 🙂

Something else to take away from this. Lot’s of focus is currently on the OpenSim scripting implementation, as it should be, as that’s a huge user visible portion of our function. llTargetOmega it self is < 6 lines of implementation. But our supporting scene model needed some work to actually get that info to the client.

I get asked all the time “how long until my favorite feature X is implemented”, and the answer is always an unsatisfying (to me and them), “I’m not sure”. Sometimes the plumbing is already there, and it’s quick. Other times we’re doing deep dives into our code base to implement what seems to the user to be a very simple function.

We’re making constant forward progress, I’d even say rapid constant forward progress, but patience is always a good thing. Also, if you want OpenSim to work for whatever you application is, you should be trying to use it now and filing bug reports. That’s how we function, personal itches, and knocking of mantis reports. Any ability that you have to narrow the bug to a specific section of code (even if you don’t have a fix), helps a lot as well, as it removes possibly hours of core developer time trying to track down where things fail.