Pretty close, but still not close enough. I guess, I’ll need to take a deep, hard look at PrimMesher too.
How to install 3Di OpenViewer?
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.
Step 1.
IE Users:
Go to http://www.3di-opensim.com/openviewer/ie_install.html
The ActiveX bar will appear, click Install
FF Users:
Go to http://3di-opensim.com/openviewer/ff_install.html
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.
How do I embed the Viewer on a web page?
If you just want to try the viewer out, you can head to this page: http://zaki.asia/3di/ov/index.html
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.
What is Voipforvw?
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:
# # # bjam --toolset=msvc link=static runtime-link=static threading=multi --with-thread stage
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:
// CHANGE FILE: main.h:37
#define LOG
#ifdef LOG
extern FILE *logfp;
#define VFVW_LOGINIT() logfp = fopen(“test.log”, “a”)
/*
#define VFVW_LOG(fmt, …) fprintf(stderr, “[VFVW] %s:%d – “, __FILE__, __LINE__); \
fprintf(stderr, fmt, ## __VA_ARGS__); \
fprintf(stderr, “\r\n”)
*/
#define VFVW_LOG(fmt, …) fprintf(logfp, “[VFVW] %s:%d – “, __FILE__, __LINE__); \
fprintf(logfp, fmt, ## __VA_ARGS__); \
fprintf(logfp, “\r\n”); \
fflush(logfp)
#else
#define VFVW_LOGINIT() void()
#define VFVW_LOG(fmt, …) void()
#endif
//CHANGE FILE main.cpp:15
#ifdef LOG
FILE *logfp = NULL;
#endif
3Di OpenViewer provides a number of ways to connect to a grid, let’s look at those in a little more detail.
Manual
Manual login is the normal way, that everyone using SecondLife/realXtend/Hippo/etc are already used to using. This mode will show a login box right within the application and will allow you to specify the login uri, the first and last name and password. You can set the default values with additional params as well.
<param name="LoginMode" value="manual" /> <!-- Optional --> <param name="ServerURI" value="http://1.2.3.4:10001" /> <param name="FirstName" value="first" /> <param name="LastName" value="last" /> <param name="Password" value="password" />
Click
Click login is great if you want to specify all the information for the login and not allow the user to change it in any way (for example dynamically creating the login page based on an already existing session information). In this case, the user can only see an empty screen with no login box; when they click on this screen, login starts automatically.
Of course in click mode, you will have to specify all the login information like above.
<param name="LoginMode" value="click" />
Hide
Users can also use a JavaScript function to log in. Sometimes, it is better not to allow users to specify any information, but at the same time, login information can dynamically change at any time. In this case, you can set the login mode to hide, which will not show the login box, but also not allow login from within the application. Rather, it only allows JavaScript logins.
<param name="LoginMode" value="hide" />
To log in from JavaScript, one can use the following function:
openviewerCtl.Login(firstname,
lastname,
password,
server_uri,
login_location);
For the JavaScript login method, it is also possible to specify the exact location to log in to. The format is
// " uri:regionname&x&y&z" uri:region1&128&128&25
