Here are my simple changes to statpress.php:

// A function to check whether a referrer should be
// omitted due to a manual ban
// To add/remove referrer bans, edit
// wp-content/plugins/statpress/def/banreferrers.dat
function iriCheckBanReferrer($arg)
{
    $lines = file(ABSPATH.'wp-content/plugins/'.
                  dirname(plugin_basename(__FILE__)).
                  '/def/banreferrers.dat');
    foreach($lines as $line_num => $banref)
    {
        if(strpos($arg,rtrim($banref,"\n"))===FALSE) continue;
        return true; // banned
    }
    return false;
}

// In function iriStatAppend()
$referrer = (isset($_SERVER['HTTP_REFERER']) ?
             htmlentities($_SERVER['HTTP_REFERER']) :
             '');
// BANNED REFERRERS
if (iriCheckBanReferrer($referrer)) $referrer = '';
// END BANNED REFERRERS

Then all I needed to do is create a banreferrers.dat file in the plugins/statpress/def directory containing one bad word/domain per line and now hopefully a lot less referrer spam will appear in the statpress overview. For now this will suffice for me.

type Test =
  | Option1 of float
  | Option2 of int

If we take the generated assembly apart, this simple code generates a relatively large amount of code. First of all, a class (type) named Test is going to be created. What is more surprising is that five nested classes will also be defined. Of this five, two seems to be crucial as we’ll see while the others seem to be more about administration.

Talking about administration, the resulting type implements a fair amount of interfaces automatically.

IEquatable adds three Equals methods: one with the Test type, but also two with object type (one of which allows a second IEqualityComparer parameter). Similarly IComparable and IComparable<Test> are implemented. In addition IStructuralEquatable and IStructuralComparable are also implemented. I won’t talk about these methods.

What is more important is that one nested class that is inherited from Test will be created for each option, named Option1 and Option2. Both of these classes will contain a property named Item and not surprisingly Item will be float64 in Option1 and int32 in Option2.

Test will also contain two more boolean properties: IsOption1 and IsOption2 which return whether this refers to an instance of the respective type.

Finally Test provides two factory constructors named NewOption1 and NewOption2 which create either of the nested option instances. Its constructor in fact is not public (and doesn’t do anything except create the useless parent Test instance).

An implementation in C# therefore (removing much of the automatically generated interface implementations and helper methods) would look like this. The generated IL is very similar to that of the original F# code.

public class Test
{
    public class Option1 : Test
    {
        public Option1(double v) { item = v; }
        readonly double item;
        double Item { get { return item; } }
    }

    public class Option2 : Test
    {
        public Option2(int v) { item = v; }
        readonly int item;
        int Item { get { return item; } }
    }

    public sealed class Tags
    {
        public const int Option1 = 0;
        public const int Option2 = 1;
    }

    Test() {}

    public static Test NewObject1(float v) { return new Option1(v); }
    public static Test NewObject2(int v) { return new Option2(v); }

    public bool IsOption1 { get { return (this is Option1); } }
    public bool IsOption2 { get { return (this is Option2); } }
    public int Tag {
        get { return ((this is Option1) ? Tags::Option1 : Tags::Option2); }
    }
}

There are two further nested classes named Option1@DebugTypeProxy and Option2@DebugTypeProxy, but I’m not really sure what their functionality is. Also, there is that Tags nested class with its const definitions and the Tag property in Test whose role is also not completely clear from this IL code. It can be related to enums or maybe to do with performance

After comparing the two implementations, it is very easy to appreciate how – in probably Don Syme’s favorite word – succinct F# really is (and that’s even before diving into heavyweight functional programming.

let adder x y = x + y
let partial x = adder 2 + y

is compiled to

.method public static int32  adder(int32 x, int32 y) cil managed
{
 .custom instance void \
      Microsoft.FSharp.Core.CompilationArgumentCountsAttribute::.ctor(int32[]) \
      = ( 01 00 02 00 00 00 01 00 00 00 01 00 00 00 00 00 )
 // Code size       5 (0x5)
 .maxstack  4
 IL_0000:  nop
 IL_0001:  ldarg.0
 IL_0002:  ldarg.1
 IL_0003:  add
 IL_0004:  ret
} // end of method Program::adder

.method public static int32  partial(int32 x) cil managed
{
 // Code size       9 (0x9)
 .maxstack  4
 IL_0000:  nop
 IL_0001:  ldc.i4.2
 IL_0002:  ldarg.0
 IL_0003:  call       int32 Program::adder(int32,int32)
 IL_0008:  ret
} // end of method Program::partial

which comes down to the following common C# code

public class Test
 {
    public static int adder(int x, int y) { return (x + y); }
    public static int partial(int x) { return (adder(x, 2)); }
 }

and it does generate a similar IL code:

.method public hidebysig static int32  adder(int32 x,int32 y) cil managed
{
 // Code size       9 (0x9)
 .maxstack  2
 .locals init ([0] int32 CS$1$0000)
 IL_0000:  nop
 IL_0001:  ldarg.0
 IL_0002:  ldarg.1
 IL_0003:  add
 IL_0004:  stloc.0
 IL_0005:  br.s       IL_0007
 IL_0007:  ldloc.0
 IL_0008:  ret
} // end of method Test::adder
.method public hidebysig static int32  partial(int32 x) cil managed
{
 // Code size       13 (0xd)
 .maxstack  2
 .locals init ([0] int32 CS$1$0000)
 IL_0000:  nop
 IL_0001:  ldarg.0
 IL_0002:  ldc.i4.2
 IL_0003:  call       int32 CSharpTest.Test::adder(int32,int32)
 IL_0008:  stloc.0
 IL_0009:  br.s       IL_000b
 IL_000b:  ldloc.0
 IL_000c:  ret
} // end of method Test::partial

F# is very easy to work with in this sense, because it will be compiled to IL first, so if I only run ILdasm on it, an equivalent C# code could be created.

let a(x,y) = (y,x)

This innocent short code will generate the following IL code

.method public static class \
        System.Tuple`2<!!b,!!a> a<a,b>(!!a x,!!b y) cil managed
{
 // Code size       9 (0x9)
 .maxstack  4
 IL_0000: nop
 IL_0001: ldarg.1
 IL_0002: ldarg.0
 IL_0003: newobj instance void class System.Tuple`2<!!b,!!a>::.ctor(!0, !1)
 IL_0008: ret
}

Aha! So we are not fiddling around with temporary variables (which wouldn’t work anyway because variables are immutable by default in F#), instead the simplest of things happens here: a new variable is constructed with the parameters swapped and then returned.

In C#, Swap could be written along these lines

public static Tuple<T2, T1> Swap<T1, T2>(T1 a0, T2 a1)
{
    return (new Tuple<T2, T1>(a1, a0));
}

In fact the C# code generates an almost identical IL code (although honestly I’m not sure what the final branch is supposed to be, as it doesn’t do anything apparently useful)

.method public hidebysig static class System.Tuple`2<!!T2,!!T1>  \
        Swap<T1,T2>(!!T1 a0, !!T2 a1) cil managed
{
  // Code size       13 (0xd)
  .maxstack  3
  .locals init ([0] class System.Tuple`2<!!T2,!!T1> CS$1$0000)
  IL_0000:  nop
  IL_0001:  ldarg.1
  IL_0002:  ldarg.0
  IL_0003:  newobj instance void class System.Tuple`2<!!T2,!!T1>::.ctor(!0, !1)
  IL_0008:  stloc.0
  IL_0009:  br.s IL_000b
  IL_000b:  ldloc.0
  IL_000c:  ret
}

Before Rei was released at the end of September, it was called 3Di OpenViewer. As it stands, that viewer didn’t need to download textures through the region server, rather, it would download assets (textures, meshes, avatars) directly from an asset server. For this reason, when someone logged in to an upstream OpenSim grid with 3Di OpenViewer, textures and avatars would not appear.

But that changed when we released Rei as an open-source viewer at the end of September. At that time, textures were already being fetched from OpenSim. You can go ahead and grab the installer from github and it will display textures. What it won’t do with textures is correctly apply UV coordinates in some (fortunately very rare) twisted-hollow-prim cases (but it was more about PrimMesher than Rei). Since September, we have done many improvements to PrimMesher – and Rei too, so now even those rare cases appear correctly (big thanks to the bug reporters). Texture downloads are slow unfortunately, but more on that later.

Avatars

Now this is a very delicate issue. The heart of the issue is that currently there is no non-LL viewer that supports SecondLife(tm) avatars. Let me say that again: there are no viewers that support SL(tm) avatars. Naali has a built-in mesh (the same as the old viewer), IdealistViewer has a built-in mesh, LookingGlass doesn’t yet have avatars (correct me if it does), Xenki doesn’t have an avatar yet as far as I know either.

The closest a viewer gets to SL avatar support is the PandaViewer by dahlia (http://vimeo.com/6812213) , which supports avatar shapes and actually looks really nice. Unfortunately it’s not open source (yet?), nor is it available in any form.

The thing with avatar support is that it’s pretty difficult to do right. No, not only technically, but there’s the issue of using or not using Linden Labs(tm)’s original mesh. You can find downloadable meshes, but there is a nice warning hidden neatly inside an obj file:

# This model is released for use by residents of Second Life.
# It may be imported into external 3D modeling, texturing, and animation applications to aid in the creation of character animations and textures for Second Life, as well as for any non-commercial purpose.
# Use or modification of this model for any other commercial purpose is prohibited without the express written consent of Linden Lab.

With all this said, we are looking at SL(tm) avatar support. It definitely won’t happen before the end of this year, the target is early next year.

OpenSim support

Of course Rei still has issues with upstream OpenSim support. This is partially due to the very very bad way textures are downloaded (through a single server, in UDP). The truth is, even SL(tm) viewer chokes on those: in heavy regions it would download the low resolution image, but the full image is never actually downloaded. My personal opinion is that the sooner we can break free from that way of transferring assets to clients, the better (guess how 3Di OpenViewer delivers content). Hopefully OpenSim will not remain an SL(tm) clone and there will be lots of innovations in the virtual world space coming from OpenSim. Rei is supposed to show what is possible when we can control both the viewer and the server side without the fear of not being able to work on one or the other for six months.

The current state

Below are two videos of Rei logging in to OSGrid’s Lbsa Plaza and Wright Plaza.

So, what do you think of the viewer so far? What sort of improvements do you think would be nice? What do you think is missing, other than the avatar support?

In general, what are the things you absolutely expect from a virtual world viewer?

Let me know in the comments.

Wii Controller Plugin

3Di Viewer “Rei” provides a great flexibility when it comes to adding custom functionality to the core viewer by making it possible to create binary plugins. Just drop these binaries into the Rei folder and let the viewer find and load it automatically the next time it starts. While these plugins are still in their early phase – we can do a lot more to ease the process of deploying plugins and resolving their dependencies – you can get a glimpse at their power already.

The WiiControllerPlugin is a fun project, a proof-of-concept, rather than a commercial solution, so before you dive in, be warned, that it is sometimes rough around the edges. With that out of the way, if you have Rei, head over to http://github.com/zaki/ReiWiiControllerPlugin and grab the binary from the Download section. Just copy the contents into the Rei installation folder (usually C:\Program Files\3Di\Rei). And… that’s basically it.

How to connect the controller?

To use a Wiimote, you will need a Wiimote, a nunchuck and a bluetooth adapter. I’ve heard that Toshiba adapters works best, but I have used Broadcomm’s chips successfully as well. It is said that the Microsoft stack doesn’t work most of the time with the Wiimote.

Before you start the viewer, connect/pair the Wiimote via bluetooth. If you find it difficult to connect, I found that keeping (1) and (2) pressed simultaneously while connecting helps a lot.

Once the Wiimote is connected, start Rei and if everything goes well, the primary Wiimote will have its first LED turned on. You are now ready.

How to use the Wiimote?

The WiiControllerPlugin allows you to use the Wiimote and the nunchuck to control your avatar and the camera. The nunchuck’s joystick, or the directional controller on the wiimote can be used to make you avatar walk. Up will always make your avatar walk forward, regardless of the position of the camera.

The camera is controlled with a combination of the wiimote and the nunchuck. Zoom in and out by holding down (Z) and tilting the nunchuck forward and backward. Hold the wiimote straight up; while you press (B), you can tilt the wiimote in four directions to rotate the camera around your avatar. Remember, you don’t have to look away from the screen to change the camera angle.

If you get lost with the camera, you can always press (C) to go back to behind your avatar. Pressing (C) also switches to “follow” mode, so your camera will “stick” to  your avatar and will follow it from behind if you move. Pressing (C) another time will switch back to the free camera mode.

If you get tired of moving with the wiimote and want to switch back to using the keyboard or mouse, you can disable avatar movements by pressing (-). Your wiimote’s will light the third LED when it’s disabled. Press (-) again to enable moving by the wii controller.

About the demo

The video above contains a very dull maze, in which there are colored balls that hurt or heal you when you touch them (I’ve never said I was a great contents designer, have I ) The demo shows how easy it is to integrate custom features with an unmodified OpenSim grid. All that was used is simple LSL script that detects collisions and gives commands via llSay. These commands can be intercepted by javascript and further dispatched to all plugins, that can act accordingly. In this case a simple health bar is adjusted.

As my LSL was sending plaintext commands like “heal,20″, the necessary javascript looks really simple:

function DispatchCommand(message)
{
	var strList = new Array();
	strList = message.split(",");

	if (strList.length == 2)
	{
		ctrl.Callback(strList[0], strList[1]);
	}
}

If you have a question, or have a good idea about plugins, or the WiiControllerPlugin, please share it in the comments.

Plugins

In “Rei”, there is a curious little green “health” bar above the avatar’s head. That bar is not something that is built in to the viewer, rather, a simple plugin provides the functions that are necessary to have a very rudimentary health bar. Of course this TestPlugin is only to show what sort of things are possible with “Rei”.

What do plugins do?

Plugins are intended for two main purposes. First, to communicate – through javascript – with the 2D web, and second, to interact with objects within the 3d scene. Of course a plugin is a .NET assembly, so it can pretty much do anything, but the main functions it is intended for are the above two. For instance TestPlugin provides two javascript functions: one to inflict damage and one to heal, basically allowing a regular 2d web application, for instance an SNS site or an online game, to change the health meter of the avatar within the 3d world according its own rules. Responding to these javascript functions then, the plugin interacts with the 3d world by rendering its own little health bar above the user’s head.

How to write plugins?

To make things as simple as possible, “Rei” uses the same method for developing plugins as OpenSim. Essentially one writes an addin for the /OpenViewer/Managers extension by implementing the IManagerPlugin interface and then creating and embedding a plugin manifest to the assembly.

IManagerPlugin

All plugins need to implement IManagerPlugin, which means implementing a few methods:

void Initialise(Viewer viewer);

- Initialise is the method that will be called right after constructing the plugin class. This will be only called once for the life of the plugin and is used to create objects that will persist through the entire lifetime such as static resources (textures, models), configurations.

void Initialize();

- Initialize (note the z in the name) will be called when “Rei” is getting ready to enter a region. This happens on the first startup as well as after logout or before entering a new region after a teleport. This is to make sure that unnecessary scene objects do not make it over to a new environment, therefore Initialize would create objects that persist only through the lifetime of one region, such as dynamic resources (textures, meshes) or dynamic information (region data, prim data)

void Update(uint frame);

- Update is called every frame. This is the place to calculate the next state of the plugin, including objects in the 3d scene. This is the only place where it is allowed to change properties of any object that is within the scenegraph. By using the frame parameter, it is possible to count or skip frames.

void Draw();

- Draw is also called every frame and it is where drawing directly to the 3d canvas is possible. Generally it is recommended to use proper scenenodes that draw automatically, instead of drawing directly.

void Cleanup();

- Just like Initialize is called before “Rei” is ready to log in to a new region, Cleanup is called every time a region is no longer needed, such as when logging out or when leaving a region by teleport. Cleanup is responsible of releasing resources that were allocated by Initialize (but not Initialise!)

RefController Reference { get; set; }

- This property is the entry point to “Rei”s core. Through this object it is possible to call into the public api of the viewer or to access javascript. Reference must always be initialized from the viewer parameter passed in to Initialise()

Communication with Javascript

Plugin to Javascript: Dispatch

A plugin can call Reference.Viewer.Adapter.Dispatch(string action, string message) when it wants to send a message to javascript. If a handler was added to the javascript library for the particular action, this dispatch will be processed by passing the message to the handler function. For future compatibility it is recommended although not required that the message be passed in json format.

Javascript to Plugin: Callback

The Adapter supplies a Callback delegate and a registry to handle calls from Javascript. A plugin can register a callback method that it is interested in receiving by calling

Reference.Viewer.Adapter.RegisterCallback

. It must pass the name of the method it wants to listen to and the method to call when the event arrives. The way a Callback works is very much like delegates work in the .NET framework.

From the javascript side, one can use

ctrl.Callback("method", parameters)

and all plugins that are listening to “method” will receive a callback to their registered functions. For an example of Callbacks, you can see the DoDamage and DoHeal from test.js and TestPlugin.cs

Plugin to Plugin: Message

It is also possible to send messages from one plugin to another, even without being aware of the other plugin. The mechanism is very similar to Callbacks: a plugin registers a message handler by calling

Reference.Viewer.Adapter.RegisterMessage

. The first parameter must be the name of the message to listen to and the second one is a message handler delegate.

A plugin can then raise a Message by calling

Rerence.Viewer.Adapter.SendMessage("message", parameters)

and all plugins that subscribed to the message being sent will receive it.

[line]

Irrlicht.NETCP

I’ve spent the last couple of weeks working towards rebasing the now abandoned Irrlicht.NETCP to use the latest Irrlicht released: 1.6. There are multiple reasons to do so, probably the most straightforward is to get the bugfixes or some of the new features, like the new light manager. However the less direct reason to do the rebase is that it includes Mac support out of the box – and now that I have a macbook sitting on my desk at work (albeit, temporarily), that is something of very high interest for me. In my dreamland, OpenGL ES support (for the iPhone) would work without much work too – hey, I can dream, can’t I.

So, for this rebase, I’ve started a new repo on github, that I hope will soon become the official repository for 3Di Viewer “Rei”, and maybe even for users of Irrlicht.NETCP (if any are still left, but who knows, maybe this can spark some new interest). The repository starts with a clean Irrlicht 1.6 SDK and gradually adds the fixes and features that are necessary for Rei (but of course those are fixes and features that would probably come up in other development as well).

On top of the improvements to Irrlicht, there is one huge patch, that makes the IrrlichtW wrapper compatible with 1.6. This mostly consists of type changes in the method interfaces and other minor details, but the patch itself is pretty monstrous, as many things changed at the same time. It is only after this collective patch, that the .NETCP library is usable again (it won’t even compile before this fix, so be careful with the history).

Later, IrrlichtML fixes were added. ML stands for multilingual and these changes are required even though things finally started  moving away from c8* to proper strings and io::paths in the core, stuff like IME support was not included and the unicode support is still horrible to say the least.

Getting Irrlicht.NETCP

If you want to give the new Irrlicht.NETCP libraries a try, head to github: http://github.com/zaki/irrlicht.netcp and check out the sources (either using git, or click on download in github). For the impatient, I’ve also uploaded binary files for 32-bit windows (Release mode).

To compile the libraries yourself, you will have to compile three components: Irrlicht SDK, IrrlichtW and Irrlicht.NET, in basically this order. To compile Irrlicht SDK, go to Irrlicht SDK\source\Irrlicht and open Irrlicht9.0.sln in Visual Studio 2008 and build. IrrlichtW’s solution is found in IrrlichtW, named IrrlichtW.sln

Irrlicht.NET uses Prebuild to create its solution files, so before you can compile, the file runprebuild2008.bat needs to be run. That creates the solution file Irrlicht.NET.sln, that can be opened and built in VS.

Rei and Irrlicht.NETCP

To use the new binaries with “Rei”, some minor changes need to be made to Rei’s source. I committed these changes to my github repository: http://github.com/zaki/3di-viewer-rei, however the changes are not in the master branch, which I try to keep as a clean integration copy (therefore there is a little time delay). Get the Irrlicht 1.6 supporting sources from the ‘linux’ branch.

One more thing…

Ahem… did I just say ‘linux’ branch? Well, that’s probably because I’ve also started working on Rei linux support and so far things look quite bright (as opposed to the MacOSX support, but maybe later about that). I managed to make Rei run on my Ubuntu machine in standalone mode using Irrlicht.NETCP and mono. There are still a ton of things that need fixing, but it’s only a matter of time before a consistent framerate is achieved – I had driver issues and occasional performance problems, probably not unrelated. There are some problems with JPEG2000 support that I didn’t have time to look at yet and haven’t written shaders (OpenGL seems to hate HLSL shaders for some reason , but everything in its own time.

So if you feel particularly adventurous, go ahead and grab the sources from the ‘linux’ branch – Irrlicht.NETCP’s master branch now includes linux support -, compile them on your linux machine and do let me know how it works for you.

Some questions did remain unanswered though. The two schools differed greatly on their views on the mass extinctions during which time whole families of species have disappeared leaving only a faint trace in the form of fossil evidence: a skeleton here and there or an object we could connect to ancient – primitive – species. The community was simply amazed when remains of a smaller colony from a couple of thousands of years ago was unearthed, but even that could not compare to what excitement spread through scientific journals when fossils of a long disappeared ancient species were found in a rare excavation. Scientists from both camps would throw themselves at the new samples, trying to fit the new pieces of the puzzle to their theories.

One group has claimed, that species evolved through a very coordinated, but seemingly random process from other – usually more primitive – species. Through time, organs that were more useful for survival have been – in a manner – selected. It’s as if there was an algorithm in nature that experiments with randomly changing the variables, keeping results that it deems good while terminating those it finds unworthy. This algorithm has been present for millions if not billions of years (some even went as far as proposing that the same process can be found before life itself appeared). There was however a strange gap between humans of the long gone past and humans of the present – as if only the right fossils that would bridge this gap were hiding  somewhere, waiting to be found one day.

Followers of this theory – called evolutions – found that pieces of evidence fit their theory perfectly. They argued, that evolution of the present humans from ancient human forms is completely possible, as the natural selection process would experiment practically randomly, therefore given enough time, ancestor  species could be significantly different from descendant species.
The other group also proposed a complete explanation, however their theory immediately caused an uproar in the scientific community. They claimed that present form humans have not appeared through a lengthy process of evolution, rather, it was created through an intelligent design. Their theory proposed that present day humans were created by an ancient, intelligent entity, or even by the – in lack of a better word – consciousness of some ancient species.
Many would instantly distance themselves from members of this second group and some even went as far as calling the professor that first published this  theory an idiot. As the arguments started to spiral out of hand, finally a well-known scientific association has organized a public forum for members of  these groups where they were given the chance to present their findings and evidence. In the heated debate, followers of the school of evolution would claim that intelligent design is unscientific, while proponents of intelligent design would argue on the improbability of random evolution. A noted professor of  the second group was quoted to say:

“I firmly believe that humans were created by in ancient intelligent designer. The probability of complex organs evolving at random is not in accordance with nature. The probability of a complex structure evolving randomly is provably smaller than the theoretically conceivable smallest probability in the Universe. It is laughable to assume that the organ we know as our brains have evolved at random from lesser life forms. I don’t think it is even theoretically possible  that the our alleged ancestors’ primitive carbohydrate-based organs would spontaneously evolve into our immeasurably complex silicon chips.”

Pretty close, but still not close enough. I guess, I’ll need to take a deep, hard look at PrimMesher too.