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?
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.
Please note: WiiControllerPlugin is not endorsed by Nintendo. WiiControllerPlugin depends on WiiMoteLib, which is release under the license MS-PL. For more details, see http://wiimotelib.codeplex.com/
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.
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.
First and foremost, please note, that the viewer is currently for Windows and 3Di only supports Internet Explorer 6+ and Firefox 3.0 and 3.5 at this time.
Click on the orange button with the arrow to download and install the plugin.
Step 2.
The installer will appear.
The first screen is only an introduction. It asks you to close other applications before clicking next. The left button says Next, the right one is Cancel.
The second screen is the EULA. I won’t try to translate it to english, you can get a raw English version by pushing this through any online translation service. The long and the short of it was summarized in these two sentences:
1) No commercial use
2) No reverse engineering
The first radio button says Agree, the second says Disagree. Again the buttons are Back, Next and Cancel in that order. I guess it is pretty difficult to Agree with something you can’t read (I always feel that way in Japan ). There are no traps in there and as long as you don’t use it to become a millionaire celebrity without 3Di’s consent, you should be alright. (If you happen to be a millionaire celebrity already, you should definitely contact us )
The next screen has three buttons saying Back, Install and Cancel respectively. After clicking Install, it will start the automatic install process. When it finishes, you can click on the Finish button on the next screen.
You can of course see (and therefore use yourself) the HTML and JS codes that are used to embed the viewer. Please keep in mind though that 3Di is just about to make these available officially (and more conveniently) very soon as well.
You can see some details about changing the login behavior from javascript here: http://zaki.asia/?p=46
Is it possible to use 3Di OpenViewer in English?
This question is asked many times lately, so here’s a short guide on how to do it. Please do note, that this is sort of a pre-release thing, that might in some places be a little rough around the edges. And if you find any leftover Japanese text after the switch, do let me know.
When you install the viewer, and open a page with the viewer embedded, it will appear in default Japanese locale, but it is possible to change this to English. There are two ways to do it: you can log in to an OpenSim grid with the Japanese version and change the locale from the menu, or you could change the configuration file to make the viewer appear in English from the first login page. Either method you choose, you will have to start the viewer at least once (to initialize the necessary directories and configuration files).
Method 1 – Using the menu
Using the login screen, specify the login URI, first name, last name and password in that order, then click on the button to log in.
After you log in, move the cursor towards the upper right corner until the menu appears. Click on the wrench icon to go to settings. The last selectbox on the first tab is the locale, you should select the first option and press OK. A dialog will appear telling you that the settings will be effective after you restart the viewer. Do so, and the UI will appear in English now.
Method 2 – Changing the configuration file
After you start the viewer, the configuration file will be created in your local settings directory. On XP, this will be in Documents and Settings/<username>/Local Settings/Application Data/3Di/OpenViewer/, while on Vista and Win7, this will be in Users/<username>/AppData/LocalLow/3Di/OpenViewer
Open the file in configs/ called OpenViewer.ini and change locale to en
locale = en
Start the viewer again and it should be in English now.
Can I connect to OpenSim grids?
The short answer is ‘yes’. The long answer is ‘yes, but’. You can definitely log in to OpenSim grids with the current release version and prims will display. However textures and the avatar will not currently appear. The reason for this is that assets are not downloaded through the region server. We are working on a fully compatible version that we will release in the future, but for the moment to get the full experience, unfortunately you will have to connect to 3Di’s servers. We are also preparing more demo servers, but I have to ask for just a little more patience on that.
If you try 3Di OpenViewer, your feedback is always appreciated.
Kai Ludwig has recently left a very valuable comment (thank you, Kai):
Actually the new FreeSwitch siren14 codec has never been used with SLVoice! Everybody having voicechat with OpenSim is using PCMU without knowing it.
Actually I didn’t realize that at first either, but after he pointed this out, I started looking for a way to be able to use siren14. I haven’t really come up with a way to use the SLVoice.exe included with the SecondLife viewer, rather, I modified the voipforvw codes to support it. Voice quality is now way better than the stock PCMU.
In the near future, I intend to make a post on how to use voipforvw with FreeSWITCH.
With the SecondLife viewer comes an executable named SLVoice.exe. This is the piece of software that is responsible for the “low level” voice communication, so while the viewer does the accounting (login information, UI), this part does all the heavy lifting of contacting the voice servers and of course translating the voice of the speaker to RTP packets and back. The long and the short of it is that voipforvw (voip for virtual worlds) is a snap-in replacement for this executable that communicates with the viewer and as you’d guess, does the heavy lifting and coding/decoding. The core of this application was originally developped by 3Di (more specifically sempuki, who in the meantime left for greener pastures and skiryu, who is now the CEO of the startup Magical Implements) I came to the project around August 2008 and was working, among others, on this project with skiryu until about October 2008, when the internal priorities changed, so for a very long time we didn’t have the time to maintain voipforvw. Now here we are in May 2009 and I hope that with the new FreeSWITCH module for OpenSim working (mostly), attention might come back to voice and thus voipforvw. At 3Di, internally we are also increasing the amount and quality of community activity compared to last year (before we shifted temporarily to a shipping-oriented mindset), so we will have more time to work on and share various projects like this.
But why should I care about it?
The thing is, that the original SLVoice was developped for Linden Labs by a company named Vivox and is of a proprietary license. The good news is, that it is insanely high quality (it runs on a couple of plaftorms and powers virtual worlds like SecondLife or games like EVE Online) with ready-made 3D positional audio. The bad news is that it’s proprietary to the point that you are explicitly disallowed from using it for OpenSim. From the FAQ on vivox’s home page says:
Can I distribute this to friends?
No, currently Vivox software and service is offered for individual, non-commercial use only.
Can I use this outside of Second Life?
No, the currently offered software is only available for the Second Life Viewer open source community.
Tough luck if you are a commercial entity who wants to provide a VoIP solution for your customers based on OpenSim.
I was pretty surprised that outside 3Di (and to be self-critical, for a long time even inside 3Di – even if it’s for a reason) nobody really cared about this project and that voice patches were not accepted becase of a base64 encoded UUID (that by the way works the same way in the new FreeSWITCH module that was committed by the same person). My hope is that more developers from the community can join to the project in the future and help clean up the relative mess it is in right now.
What’s the catch?
Well, unfortunately there is a catch. The license of the SIP/RTP stack used in vopforvw is GPL. This has a simple effect on the whole project, that is, voipforvw automatically becomes GPL. Unfortunately currently there is no good library that comes with a BSD-like license, the closest we can get is LGPL. (If you happen to know of one, please do let me know in the comments). While I’m a fan of C#, there is basically no free SIP/SDP library of any license for C# either.
Second, at the moment noone is maintaining the Linux version: in theory it should compile just OK, but that is not something I’d personally guarantee. I will try to look into that later.
But it’s sooooo difficult to use.
I’ve heard this argument for quite some time: it is probably my failure to do zilch about it so far and i guess being busy (look up the japanese word karoushi) for the last half a year or so is no excuse, so I will try to make amends now. Compiling the SLVoice replacement is not really that difficult. If you have problems with building, take a look at the screencast below and see if it can help fixing your problem. And of course, you can leave comments here (sorry, I am not really monitoring the sourceforge project forum)
Please note: trunk contains a version that only works with SLViewer versions below 1.22 (1.19, 1.20 and 1.21 were tested). For 1.22, I started a branch named sl_1.22 that contains an updated version that – in turn – only works with 1.22. As I am not allowed to look at the viewer’s source code, many thanks go to yk, who described the major API changes to me. Unfortunately this also means, that I can’t guarantee that the 1.22 version works properly. At least I had success making conferences work with that branch, but further testing will be needed for that branch to be integrated back into trunk.
What will I need?
You will need voipforvw, that you can check out from sourceforge.net:
svn co https://voipforvw.svn.sourceforge.net/svnroot/voipforvw voipforvw
Next, you will need boost, curl and pjsip. The versions that I was using are 1.39, 7.19.4 and 1.0.2 respectively. For PjSIP, 1.x series will currently not work due to API changes.
For compiling on Windows, you will also need the Platform SDK and DirectX SDK. Voipforvw uses CMake for its configuration too.
Step 1. Compile dependencies
Set up (if you haven’t already) the platform SDK and DirectX SDK folders in Visual Studio.
Compile boost with bjam. To build bjam first, just run build.bat, which creates bjam.exe; use that in the boost directory with the following commandline:
To compile cURL, open the solution file, change the build type to Release and set the Runtime Library to Multithreaded (/MT). These changes are necessary, because we will be using multiple boost state machines from a multithreaded environment. Build only libcurl.
PjSIP will need you to move the file pjlib/include/pj/config_site_sample.h into config_site.h No changes are necessary to this file, the defaults will work fine.
Open pjproject-vs8.sln (and convert it as needed) set it to Release and build the solution.
Step 2: Configure and build voipforvw
Next, go to the voipforvw trunk and edit CMakeLists.txt You will need to change the paths for PJDIR, CURLDIR and BOOSTDIR. Don’t use backslashes, replace them with forward slashes. The CURLLIBS variable needs to be changed from curllib.lib to libcurl.lib.
Open up CMake-gui and set the source directory to the voipforvw trunk. The output directory can be the same. Hit Configure (it will probably complain about backwards compatibility, but just ignore it and hit Configure again). If configuring goes well, there will be no red lines in the config window. Hit Generate, that will ask for the format of the solution file, choose the Visual Studio version you have and click OK. This creates the main solution file.
After opening this solution, there are three things you will need to check: first, set the build type to Release. Next check that the Runtime Library is Multithreaded (/MT) to match the other libraries and finally, LIBCMT will have to be removed from the libraries (because it conflicts with MSVCRT). Now you can build SLVoice.exe that you can use as a replacement for the vivox solution.
Debug
You probably noticed that we are building everything in Release mode. That’s fine as long as it works, but sometimes you will want to debug (hopefully less often). In this case you will need to change the Runtime Library to /MTd for PjSIP and voipforvw. Then CMakeLists.txt needs to be updated to reflect this by setting
SET (PJTARGET i386-win32-vc8-debug)
Where you remove the LIBCMT library, now you will have to do the same thing for both LIBCMT and LIBCMTD and you can build SLVoice.exe in debug mode.
If you only need logging to see what’s going on inside, you can change the code:
It seems that Linden Labs has finally changed their code and removed the hardcoded vivox.com references in 1.22; this has opened a lot of possibilities for making voice chat work, which previously required the – still valid – voipforvw project’s SLVoice replacement. There is of course nothing wrong with voipforvw except that it’s a monster that prefers to live under a rock and by its nature does not lend itself easily to compiling; as other internal targets were more important, and the replacement SLVoice was working (and working well, actually) with the Asterisk setup, unfortunately I had pretty much no time to get that project into shape.
To my great relief, Rob Smart from IBM has finally stepped up the game and provided a solution for FreeSWITCH, that works without this SLVoice replacement (I want to note though, that it is only working with the unmodified SLVoice.exe because of the changes in the viewer, and in all likeliness, the Asterisk solution would work just as well). I’ve been eyeing FreeSWITCH for quite a while and just when I finally have some spare time to play around with it, this new module comes out: and it’s really awesome! First of all, it works without jumping through ztdummy/dahdi hoops and mysql realtime configurations, or heaven forbid, RFC4028s.
Setup is very straightforward, and it works even on Windows. To set it up, you will need three components:
First, OpenSim itself. Because the new FreeSWITCH module is experimental, it is only found in trunk, and as usual, please note, that trunk is unstable it might have serious bugs, it can corrupt your data, or eat your children, especially if you do the unthinkable and try to install it in a production environment, which you should never do. Ever! No exceptions. If you are brave enough, you can proceed very carefully and try out the trunk.
Next, obviously, you will need FreeSWITCH. I tried the Windows binary snapshot from here: that works well. For the configuration instructions take a look at the OpenSim wiki page. Linux installation instructions are also included there.
Finally, SecondLife viewer. Only versions later than 1.22 are supported, so be sure to grab a newer version from Linden Labs.
After setting up FreeSWITCH and OpenSim, connecting to the grid and enabling voice chat, one surprising thing will happen by default: that is, nothing. Conference chat won’t work with the default estate settings, because the parcel voice is disabled. In the video, I’m setting “Use a private spatial channel”, but “Use the estate spatial channel” should work as well. Enable voice, and it will work now. After this, conference and private chat features will work. On my setup, I found that private chat is quite clear and easy to understand, but the spatial conferences are way too low quality, but that is probably a configuration issue on my environment.
Disclaimer: I am a senior engineer working on multiple products – including various OpenSim technologies and most recently 3Di OpenViewer – at Japan-based 3Di Inc. This is a personal blog, and my opinion does not necessarily always represent that of my employer.
Introduction
3Di has released (Japanese) its virtual world viewer last week. It is an embedded viewer, that works directly in a web browser; it connects to the virtual world server solution also provided by 3Di, called 3Di OpenSim Enterprise 1.0 (Japanese) that has quite a few addition on top of the community version, utilizes much more than just SL prims to create a nice looking environment even within the limitations of the web-browser.
Open?!
Let’s get the biggest question out of the way first: the virtual ink on the press release hasn’t even dried, but I was already asked where one could download the source code. After all, it is called OpenViewer isn’t it.
The short answer is: it will be released as open source at a later – not too distant – stage. Personally I think that opening up the viewer will be crucial for two simple reasons: first, the future of OpenSim depends on a viewer that opensim developers can look at without running the risk of getting burned by the license – and serious innovation requires some degree of control (I met with “we can’t do that without changing the viewer” so many times). Second, tying back to the first reason, personally I think we are in a kind of a deadlock with the SL protocol. It was never designed for the sort of things the opensim community dreams about: rather, it is a very centralized, “the region server does everything” sort of protocol, that needs a fertile testing ground in the shape of a viewer that you can bend to your own will.
When exactly can you get the source code? I don’t really have the answer to this question, as it is not nearly my decision. For now, just keep an eye on this viewer because we are going to deliver some features that I hope will show everyone that by changing the viewer, you can accomplish extraordinary things.
Features
The main distinction is of course that this viewer runs directly inside the browser. Now, does that mean, that it is forever constrained within the limits of a solitary HTML page? Not really.Internally we sometimes use a standalone version for testing, so technically there is nothing stopping someone to “liberate” (as I’m sure many would call it so:) ) the viewer from the evil browser. Our first target was IE only (boohoo, yes) and at the very least people can start using it they way they are already used to after years of experience with ye’ olde series of tubes and, equally importantly, provide us with feedback on the important questions (no, not about our plugin system or our 3D engine). And the next stop is Firefox and Safari support.
The viewer itself is operated with the mouse only. This makes it simple and straightforward; on the other hand, there are not so many actions to do: you can walk around, run about, sit down to objects or touch objects. More complicated actions like chat or teleporting are of course in a simplified menu system. Our first priority is to make OpenSim – and virtual worlds in general – accessible to a wide audience. This will hopefully help the community indirectly as well as more and more people get used to using virtual worlds, more businesses will join the ride. Of course we could have gone to the other extreme and create a highly customizable meta-GUI system, but for the uninitiated first-time virtual world user, that wouldn’t really help.
The SL Viewer supports prims, which is a great thing if you have a limited bandwidth. Or if you push every single bit through your region server. But realistically, getting professional content into SecondLife can pose a challenge because of this. As realXtend has also realized this before, 3Di OpenViewer also enables content providers to use their usual 3D content created with most major 3D modelling software like 3DS Max or Maya with little or no change. This should further lower the entry barrier to many CPs that don’t really have the time and resources to invest in creating prims for all of their popular contents. If they can import their content as-is, the cost goes down and at the same time customer satisfaction goes up. In turn, there is an increase in virtual world penetration, that is good for 3Di as well as the community. (Hopefully the trend to make virtual worlds popular and more accessible can be seen here)
The last new feature for today is the JavaScript API: we are providing ways for a fair amount of intercommunication with a CP’s HTML content and OpenViewer.You want to create an e-commerce solution in OpenSim supporting currency? Why go to the trouble of recreating your already existing EC in the virtual world, when you can quite easily communicate between the 3D world and the 2D world. The demo site is actually showing a mockup for an EC site that doesn’t require lengthy configurations and recompilation of OpenSim. No, it’s not an end-all-be-all, but it’s a simple solution that one can use to quickly start up a new business in the virtual worlds.
In closing
There might be two things apparent from this post: first, I tried to convey why I think a new viewer, and specifically an in-browser viewer is good for the community. Second, I never talked about technical details. This latter, I am planning to ammend in a later post, but first I just wanted to make it clear that 3Di OpenViewer is not a product in isolation, and although it is only a first step towards a bright future for OpenSim and virtual worlds in general, I believe that it will be a significant one. So please keep an eye on the product, and do post any feedback you might have in the comments.
) 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.
