OpenSim needs a viewer of its own

Even as OpenSim implementation continues to grow, a constant remains: there is no viewer tailored specifically for OpenSim as it comes direct from OpenSimulator.org. It’s discouraging, and it’s easy to cite the nearly million lines of code that are simply too complex to unravel as the culprit, yet the reasons behind the absence of a universally compatible viewer are as related to community as to technology.

The viewer family tree

The technology aspect is convoluted, but fairly well known. Third party stand-alone viewers are adapted from Linden Lab viewers. However, Linden Lab viewers are not designed to work with OpenSim. That they and their third party progeny work at all with OpenSim is because OpenSim supports the core of Second Life’s messaging protocol.

However, the developers of OpenSim do not aim to make OpenSim a clone of Second Life, and Linden Lab has no reason to make OpenSim compatibility a feature of their viewers. This results in a complex interrelationship between the various products and often leaves the user with a dilemma.

The Imprudence viewer, like Hippo, has a built-in grid manager that allows users to choose their starting grid.

Viewer hopscotch

I originally used Imprudence with OpenSim. Soon after that, I also came upon Phoenix viewer and switched; since I was on a Mac, the strength of Phoenix development for Mac was the deciding factor. As time went on, however, I tried to migrate from Phoenix viewer 1.5.1.373, which worked very well with OpenSim, to their newer viewers, and building became impossible.

Finally, with Firestorm, even visiting my sim resulted in prompt and predictable crashes. I was confused until Lette Ponnier of Phoenix Viewer commented on my support request, “Ah, I overlooked that you said the crashes in Firestorm occurred on OpenSim. I spoke with others on the team, and they confirm that using Firestorm on grids outside of Second Life is buggy at this time.”

I decided to return to Imprudence, only to discover that there were still issues with the version for Mac, while Kokua is still ensconced in guarded language that states it has “Better, but not perfect OpenSim support.” I tried many other viewers, including the Linden Lab viewers, and noticed something else as well; the choice of grid was also influencing viewer performance.

The important role of community

This leads to the community aspect of viewers. Third party viewers, although derived from Linden Lab viewers, are community viewers. Arrehn, a Phoenix Viewer developer, explains, “Much of their [Phoenix, Firestorm] functionality comes directly from improvements contributed by various independent and cooperating developers.  The amount of compatibility with other grids is proportional to the patches we receive from community developers interested in specific other grids.”

The fact that the community contributes to viewer development does not mean the most popular grids have the most influence. If that were true, OSGrid, the largest grid, would compel third party viewers to be 100% compliant with OpenSim as it comes straight from the OpenSimulator downloads page. Instead, the grids supported by the most developer activity have the greatest influence on viewer development because they are the beneficiaries of the greater number of improvements and enhancements.

This is a bit like Linden Labs tailoring their viewers for Second Life. As individual OpenSim grids continue to grow, developer support for preferred grids will add to the code for third party viewers, which may, or may not, benefit other OpenSim grids.

What can we hope for?

It would be rude not to emphasize that since third party viewer development is largely a volunteer effort and users pay nothing for the viewers they enjoy, the utility we derive from these viewers is already a gift. The disappointment comes from the fact that while OpenSim is made available directly from OpenSimulator, there is no viewer tailored specifically for that out-of-the-box version of it.

Unless a user chooses those grids that have contributed to a viewer that ensures compatibility, if such a viewer even exists, their OpenSim virtual world experience may be difficult to impossible. As a testament to this, it seems many blogs are regularly filled with threads about which viewer works best, or at all.

This makes me wonder what to hope for moving forward. Viewer improvements will probably be driven more by favored grids than from hopes for a universally compatible OpenSim viewer.

In the meantime, we are fortunate to have not only multiple viewers, but also multiple viewer versions. It’s confusing, but necessary in order to get the full range of experiences out of our virtual worlds. Beyond that, many hope for a full-featured Web-based viewer written from scratch with sockets purposely designed for plugging in custom compatibility and integration modules. Oh, and of course, no 4096 bug!

It is rare, however, that we ever have ideal software. My personal hope for the near future is a sophisticated, education use appropriate, growing, always on OpenSim grid, with a matching compatible version 2 or 3 viewer that is fully functional with Mac Lion, as well as Windows.

What do you hope for?

lawrence.pierce@hypergridbusiness.com'

Lawrence Pierce

Lawrence Pierce specializes in new media design and production. He began as a computer game programmer and has been a systems consultant to corporations such as DuPont and the J. Paul Getty Art Trust, art director on the first computer game for MTV and a featured artist in the Hollywood Reporter.

  • Anonymous

    I hope for a WebGL client for months… 

    • We tried pushing for a community effort to make this happen but after an initial excited response other developers lost interest so this is still not being worked on. This is quite unfortunate because the compiler technology we would have used for turning the existing SL viewer into HTML5+WebGL has continued to improve and is now significantly better than what existed when we first raised this as an option.

      • Maybe this is something we can crowdfund… Ilan — do you know of any developers who would be able to take this on?  I’m sure many of the OpenSim hosting companies would pitch in, since a good viewer would be great for their business, especially if it makes OpenSim easy enough for newbies to use. 

        • Thats what i tought about crowfunding 🙂 

          I start to learn webGL and i know some guys able to do that, that will be awesome !   Let’s get in touch : contact at angezanetti dot com

        • Hi Maria,

          I think the best person to do the work that is required for the Emscripten compiler to be able to compile the SL viewer (or one the TPVs) into HTML5+WebGL would be KirstenLee who had actually showed interest when I talked to him about this at MetaMeets. However his situation has changed since then so he is no longer an option.

          The current situation is that there are several competent teams working on developing TPVs but most of them focus on SL and not OpenSim. The only way we will get any traction in creating a real alternative is if enough of them joined forces to create a viable alternative that isn’t in a constant state of catch up with the SL viewer.

          There are several not-too-hard-to-implement optimizations that can be made to the viewer cache and the protocol (e.g. using ProtoBuf instead of XML for serialization) that would make this viewer much better suited to lower end devices than the existing SL-derived viewers. It is really unfortunate that TPV developers don’t focus on making these improvements that could make using OpenSim so much better than it is now.

          • What XML?

            LLUDP doesn’t use XML for anything, it is afaik some basically tight binary, I guess with LLSD or somehow.

            But yes Protobufs are nice.

            I figure it is not strange that TPV makers don’t want to break compatibility, with other TPVs and with SL.

            If there are slviewer-derived viewer devs who would be interested in using an extensible common lib for the protocol, such as protobufs, it certainly would be interesting. As you know that’s what we’ve been basically doing in realXtend work, but there just don’t have any of the SL features as it’s not from that code and not with those technologies.

          • Hi Toni,

            XML is used in OpenSim in all (AFAIK) places that require serialization, this causes a big drain on resources on the server side. I may be wrong about how the viewer-server serialization works but I know that at least on the server side XML needs to be replaced with ProtoBuf.

            As for cache logic, the viewer repetitively asks for the same assets (at the same detail level) because instead of storing raw assets in the cache it stores them with object information such as their place in the user’s inventory list. This results in an easily avoidable situation where data in the cache isn’t reused for various objects that reference the same asset because the cache doesn’t contain the assets separately from the object data.

            I think it would be a great idea if realXtend and OpenSim supported the same protocol (doesn’t have to be the SL one, as you know OpenSim can support multiple protocols). If the protocol were compatible then the realXtend viewer could be turned (via a prim support plugin) into a great OpenSim viewer that isn’t dependent on the SL viewer.

            Alternatively, if the realXtend server supported all the virtual world capabilities that OpenSim supports then it could replace OpenSim and the SL derived viewers entirely. I know that is what you were initially aiming for but, based on your mailing list, it now sounds as if you’re aiming to be an open-source Unity3D replacement without any defined virtual world specific functionality. This makes building a virtual world metaverse on top of realXtend harder (e.g. no single avatar standard to comply with, etc.). I’m not saying flexibility isn’t great I’m saying that we need to have standards in order to promote interoperability.

          • Yes, XML is used for storing at least the OAR and IAR etc. files in Opensim. But indeed is not used in the LLUDP wire protocol.

            About realXtend and virtual worlds: It is true that we want to keep Tundra core clean of SL-style VW specific things (e.g. Avatar), but it does not mean that the platform would somehow make that functionality weak or that companies building businesses around it would not care about it. Actually it is the opposite: because avatar, chat, inventories etc. are in modules out of the core, it is easier for anyone to develop them for new advanced features. For example Jani Pirkola and his new company have avatars in the center of their long term strategy (his avatar identity concept writeup from March is: http:[email protected]/msg03251.html )

            But indeed standards are important — seems like a good idea to use existing ones (XMPP for chat, OpenID for auth/identity) and we need something for avatars. VastPark has proposed OpenAvatar and folks at chiru.cie.fi are investigating it now for realXtend.

            So my understanding is that standalone standards for the different functionalities (chat, avatar, ..) are good, and can be implemented in different platforms (vastpark, opensim, sirikata, wonderland, tundra, ..).

          • Hi Toni,

            OpenSim also uses XML internally for persistence in some places and for communication between various services.

            I appreciate the amount of progress your team has already made in building the realXtend
            platform and I would love to be able to use it with Kitely. The
            following reflects how I see things as they currently stand:

            I’m all for flexibility but if realXtend doesn’t provide its developer community with some standard modules for avatar, chat, inventories etc. then it will be hard to create a unified metaverse on top of realXtend. It is much more likely people will use the same protocols when they can choose preexisting modules that implement them then when they need to build modules from scratch.

            If people looking for a virtual world solution can’t choose realXtend without implementing various modules themselves then they are a lot less likely to choose realXtend. Your platform competes with dedicated virtual world platforms that don’t require developers to implement basic services themselves (e.g. OpenSim).

            We really like your two viewers potential but it doesn’t matter how good these viewers are if getting a fully functional virtual world environment will require a lot of platform development on our end.

            If you want realXtend to become the standard platform people use for virtual worlds then I really suggest you create a standard set of realXtend recommended modules that people can just select in order to have a fully functional virtual world (avatar, chat, inventory, synchronized would state, physics, voice, etc.). Once you have these things working it will be much easier for service providers such as Kitely to consider adopting your platform.

            Alternatively you can create viewer plugins (protocol, prims, avatar, etc.) so that your viewers could be used with existing OpenSim installations. This may not promote the platform but at least your viewers will start seeing a lot more adoption which will attract additional developers to help continue developing your ambitious open source project.

        • Breen

          @mariakorolov:disqus: “Ilan — do you know of any developers who would be able to take this on”

          Crowdfunding would probably work. I believe several grand has been raised already for “the ex linden to fix mesh”. This shows two things, people are willing to motivate themselves to financially contribute, and money is a good talent lure. From there the developers will come.

          My next comment about the type of developer is an assumption, please correct me if wrong – a third party viewer developer like kirstenlee is a different person to the one needed to do a webclient. Current TPV viewer development is almost project compilation – merging in new code segments from the Open Sourced Linden Viewer and modifying the XML interface configs. The true heavy lifting is done by libOMV and no-one but a select few works on that.

          I put it it to this blog that the right web dev viewer team hasnt done any viewer work, and doesn’t need to have done either.

      • Well, we do have the GLGE using WebNaali implementation, which works to test things at least — and implement chat etc.

        Uses Collada.

        Current versions works only against tundra, but the protocol is dead simple (json), so would be easy to implement in an add-on to opensim. In fact, with the IronPython-adding XPython semi-official opensim module could use some of the existing impl, and keep it compatible in the future in places.

        And we are working on further development of it overall, first port to current websocket libs etc. and then hopefully all sorts of basic features — skel anim playback triggering for e.g. avatar walks & gestures etc, is easy (5 lines of code 🙂

        So it’s not like no one is having interest in it.

        Patches are also very welcome, if someone wants to port PrimMesher to js & webgl or whatever (the tree system? 🙂 .

  • I would like to see one standard set of protocols used, rather than one viewer. Protocols that would be agreed upon by the grid developers. With the ability to completely separate the caches of each grid. Maybe add features in a plugin/addon fashion. This would maximize variety and flexibility while ensuring that all grids can be accessed.

  • Breen

    Its more that just performance and technical issues that affect viewers and Opensim.

    Some do not even  address the Second Life specific functionanilty  such as money payment, help file references, or other menu items that just jump you to the Second Life webpage, or try to reconcile your account with Linden Labs.

    I fully appreciate the time commitment TPV developers make.

    But a new person clicking the money icon, then being prompted about Linden Labs accounts is disasterous.

    The Help About menu in the current Imprudence contains the letters “Bastard”.

  • There are so many places left where important data is still being streamed as “reliable UDP” in the viewers, reimplementing a lot of the basics that are already built into TCP, wasting CPU and memory.

    Most TPVs that visit our grid still have HTTP textures turned off, causing a bunch of unnecessary memory usage. 

    Users are still left to try and guess what good values for their “bandwidth settings” are, when this isn’t something they should have to worry about. There are still bugs in the inventory cache that causes folders to be refetched with every login, regardless that the version number sent over in the XML skeleton hasn’t changed..–
    Crowd funding works great for tangible targets, but how do you crowd fund make it “more better”. And what happens when you crowd fund development and the dev drops off the face of the earth (happens more than you’d think)

    If you really want to develop the “future of the 3d web” you’ll want to design something around real and defined standards, and define new standards that can be agreed upon by more than just a couple people or even one developer working alone.

  • The Cool VL Viewer ( http://sldev.free.fr/ ) is (and has always been) OpenSim compatible, got everything you expect from a modern viewer (including meshes), and has been continuously developed for the past 4 years, with a high release rate (typically one release a week).

    • Lawrence Pierce

      Thank you for highlighting this viewer.  Nonetheless, it has limitations for Windows users and is not as capable as noted on Mac.
       
      On Windows, the install is a bit tricky, since it requires Snowglobe to be installed first, after which Cool VL Viewer is installed as an overlay.  However, this worked as advertised and the results were very good.  I tried using it in both Second Life and OpenSim.  Mesh and shadows worked in Second Life and shadows worked in OpenSim (I tested an OpenSim sim without mesh so I was unable to confirm that capability.)  
       
      However, the viewer interface is the classic viewer style.  And there is no media-on-a-prim texture creation facility.
       
      On Mac, there were a few issues.  To access a Mac OS X download, there is a separate link on the homepage of the Cool VL Viewer website, which then leads to the Cool VL Viewer forum and the latest Mac OS X releases.  The first three underlined links with full descriptions are broken.  These are, however, older versions, so the actual latest release is simply marked: “download here”.  This leads to a raw directory, and I followed the 1.25 subfolder to the CoolVLViewer1.25.0.3 download.
       
      The Mac 1.25.0 (36) version is dated May 14, 2011 (the latest Windows Cool VL Viewer is dated Oct 28, 2011.)  The Mac version does not support mesh, or shadows, and it does not have a grid manager, so only a script can start it for non-listed sim access.  Once started, I found it to be a competent viewer for its version.
       
      As noted for the Windows version of this viewer, the interface is the classic viewer style; there is no media-on-a-prim.
       
      These viewers function well for their versions, but lack the features expected in a modern viewer (meshes, shadows, media-on-a-prim).  The Mac viewer is particularly dated.

    • Lawrence Pierce

      Thank you for highlighting this viewer.  Nonetheless, it has limitations for Windows users and is not as capable as noted on Mac.
       
      On Windows, the install is a bit tricky, since it requires Snowglobe to be installed first, after which Cool VL Viewer is installed as an overlay.  However, this worked as advertised and the results were very good.  I tried using it in both Second Life and OpenSim.  Mesh and shadows worked in Second Life and shadows worked in OpenSim (I tested an OpenSim sim without mesh so I was unable to confirm that capability.)  
       
      However, the viewer interface is the classic viewer style.  And there is no media-on-a-prim texture creation facility.
       
      On Mac, there were a few issues.  To access a Mac OS X download, there is a separate link on the homepage of the Cool VL Viewer website, which then leads to the Cool VL Viewer forum and the latest Mac OS X releases.  The first three underlined links with full descriptions are broken.  These are, however, older versions, so the actual latest release is simply marked: “download here”.  This leads to a raw directory, and I followed the 1.25 subfolder to the CoolVLViewer1.25.0.3 download.
       
      The Mac 1.25.0 (36) version is dated May 14, 2011 (the latest Windows Cool VL Viewer is dated Oct 28, 2011.)  The Mac version does not support mesh, or shadows, and it does not have a grid manager, so only a script can start it for non-listed sim access.  Once started, I found it to be a competent viewer for its version.
       
      As noted for the Windows version of this viewer, the interface is the classic viewer style; there is no media-on-a-prim.
       
      These viewers function well for their versions, but lack the features expected in a modern viewer (meshes, shadows, media-on-a-prim).  The Mac viewer is particularly dated.