OpenSim is now a semi-RFC1459 compliant IRCd. IRC clients are treated as full members of the virtual world, gaining a presence with a horrible default avatar, as the screenshots below picture. Each IRC client has an implementation of IClient* which means we could in theory insert text descriptions of the world and any events in. (Although in practice it’s unlikely to be useful for anything beyond basic text & IM messaging with an IRC client).

The advantage of this over the IRC Bridge module is that each presence is visible in both environments (users show up in the ‘who’ list on IRC, and have an avatar ‘in world’), and we will be able to handle a number of events more directly and appropriately – such as private messaging or group discussions. The IRCd framework I have written is extremely basic and probably not 100% to spec – if anyone with IRCd experience wants to get into the code and fix it up, please do.

In the mean time, enjoy. You can enable this by using the [IRCd] Enabled=true option in OpenSim.ini and connecting on port 6666.

Fig 1. XChat

Figure 2. Hippo Viewer

When running an infinite loop or other computationally expensive function, you will often want to release processing time back to the region to avoid causing undue ‘lag’. For instance – in a sim with 4,000 colour changing scripts, each will be trying to pummel the CPU simultaneously to get their updates onccuring.

What ends up happening is each will run for a fairly long period of time until broken up by a processing expensive “thread switch” at which point the next gets a long run before going to the next and the next and the next, or alternatively – none will finish and only one will be running.

The following diagram explains this in action – script A runs until there is an expensive thread switch, at which point script B will commence operation. You can manually force a thread switch through the use of the “llSleep(0)” statement in LSL, however the cost of switching threads is still present.

Fig 1. Normal Threaded Scripting

Microthreading allows you to say “You can pause and give time to another script” – in a way that is very lightweight and easy for the runtime VM. You manually insert breakpoints into the script which define points between the ‘tasklets’, at these points the VM can switch between runtime contexts without any penalty. As a result you can have thousands of them without problem; when running time is divided between all the running threads evenly – broken up at the tasklet borders.

The following diagram shows the same as above, in a microthreading environment.

Fig 2. Microthreaded Runtime

C# supports a limited form of microthreading via something called the “yield” keyword – and a lot of people have recognised you can use it to build a state machine — the basis of microthreading. Where we apply this to MRM is with some additional keywords.

The basic C# microthreading can be implemented in MRM without any additional work – however there is a significant manual cost in typing the construction of a microthreaded function. I have added two new keywords to MRM scripts today, which map to the C# yield statements.

The first is “microthreaded” – this keyword is inserted between the public/private/protected/internal keywords at the beggining of the function, and the variable type.For example, “private microthreaded void MyFunction(…) {”. Microthreaded functions can only work on functions with a no return type (void) – and internally it works by replacing “microthreaded void” with “IEnumerable”.

The second important keyword is “relax” – this keyword is defined as a breakpoint – an area where the VM can switch into another microthread without a penalty. There is a very small cost in placing these statements into your code, so consider placing them liberally. Place them inside of any loops or other routines which have a total processing time in excess of 2 milliseconds.

The relax keyword can only be placed inside of functions marked microthreaded – and you cannot call microthreaded functions directly (as in “Function(params)”). You must place microthreaded functions into the host scheduler marked as ‘Host.Microthreads.Run(myfunc(params));’

Another important note is that microthreaded functions will run asynchronously to your code, so do not expect “Microthreads.Run(…)” to block, consider it more a ‘Microthreads.ScheduleToRun(…)’. If you take these penalties into consideration however, these Microthreads can provide an excellent way to optimize your scripting and write coroutines relatively easily and quickly.

By default, the MRM VM will run 1,000 microthread tasklets per frame (or optimally 45,000 per second), this can be tweaked from inside of MRMModule.cs, however will eventually move into the OpenSim.ini [MRM] section.

The following is an example script that uses MRM microthreads.

Enjoy.

There’s been a rush of discussion recently about embedding virtual world technologies in the browser, I have seen two Java3D based implementations (which are very clever and deserve a closer look – especially if either is Open Source).

Tish has written up an interview with Avi who I mentioned earlier, on 3D in the Browser, the technologies and where things should be going – he’s very eloquent and I agree with pretty much everything he has to say. Avi added a companion piece with just a table of definitions and a small commentary on the article, which leads me to add my own comments on things.

First – the best browser is one that we dont need to install much onto the clients system, because the hurdle of making a plugin popular is a big one. XBAP is great for this since you dont need to install it to run it – it runs on a sandbox on it’s own just fine.

The downside to this is that we lose things like Local Caches which dramatically increase the load times when frequenting common areas – it would be nice to be able to optionally “Preview, then install” something we might be able to do via the XBAPs (one mode restricts to sandbox, other presumes it’s installed). Some experimentation in installing easily is going to need to be done.

I’ve been doing some further experimentations with XBAP (and yes, I’ll be posting the latest Xenki code shortly), and discovered some interesting things. First – 3D performance is no worse than a standalone WPF application, Second – it runs on Windows 2000/XP and up – I previously assumed it was Vista only, and was pleasantly suprised to find out this is not the case. Third – getting security certificates needed to automatically launch directly without install actually wont be too painful afterall (as long as libopenmv can get signed, we’re good.).

Cross Platform, Java3D?

The cross platform issue still remains elusive, which is why Java3D has caught my eye recently – given the similarities between C# and Java, it strikes me as potentially useful to be able to take large chunks of Xenki, run it through a special compiler and produce something that will run on Linux and Mac too.

The question becomes: why not use Java directly and skip the C#/WPF bit? Well the answer here is somewhat a personal one, first is that WPF is a lot easier to work with – this is an unfortunate fact of life, but doing things like UI ontop of 3D frames and doing it cleanly and efficiently is something that WPF has done so much better that there is almost no competition between them.

I personally have a preference towards doing things as quickly and cleanly as possible, worrying about making it functional rather than working on structural work that has already been done before – however if someone has already produced a good embeddable engine for Java on 3D pages – I’d be very tempted to at least try and give it a shot.

Java3D does also have the downside that it still sits in a sandbox, and the sandbox is mandatory – there’s no way we can implement a local cache using it to the best of my knowledge, I personally feel that the installable option is a very good way to cross the barrier between ‘hosted’ and ‘installed’ once the user is familiar.

Updated Xenki Sources

As stated above – I’m going to push the new xenki sources out in the next 24-48 hours. Watch this space as I will post the URLs and also the SVN address where I will be keeping changes.