Features of a minimum usable WebGL viewer

I know what I would like to see in a WebGL browser-based viewer for OpenSim — everything that current viewers have but super-easy to use and fast to load and quick to write.

Well, I know we’re not going to get that, especially if we’re doing it with a crowdfunded project. Since I wrote my column suggesting that last week, several folks have contacted me privately offering to help pay for it, in addition to the people who’ve pledged to help out in the comments.

KataSpace viewer is an example of an existing, open source, WebGL project. (Image courtesy Katalabs.)

But when I started speaking to actual developers and folks from the various communities that make up OpenSim — viewer and server devs, grid owners, consultants, and so on — it looked like everyone has a very different idea of how such a project should go, and how much it should cost.

So here’s my plan. It’s a minimal plan, to get something usable up and running as fast as possible, focused and targeted so that it would make for a nice, tight, crowdfunding project, and with plenty of room to develop later.

  • Basic login: The viewer should be easily customized with a login URI and region name — and welcome screen image — so that people can embed it on their grid websites or personal home pages. Visitors would be asked for their avatar name and password, and then it will load the region. Since it’s open source, individual grids should be able to adapt it to their own sign-in mechanisms — Kitely, for example, can put in a login with Facebook button.
  • Basic display: The viewer should display the avatar and the immediate surroundings.
  • Basic navigation: Users should have the simplest possible navigation mechanism — arrows and click to move. Browser-style navigation bar should allow teleports to other regions on same grid, or, if grid is hypergrid-enabled, to regions on other grids.
  • Basic chat: Users should be able to text chat with other people in the region.
  • Basic interactivity: Users should be able to sit on chairs, zoom in on surfaces.

Use cases

So what would be the use of such a bare-bones viewer?

Here are some possible applications:

  • Sim previews: Someone could log into a region from a website for a quick look around. If they want to do more, they can log in with a full viewer.
  • Preview OARs: If you want to buy an OAR files to use for your business or educational setting, you can quickly preview it with just a click. You get a better idea of what’s in the OAR than with images, and you can see it faster than with a Kitely preview or logging into the grid.
  • Virtual tours: A stripped-down viewer would be a good mechanism for virtual campus tours.
  • Virtual exhibits: Virtual artists and museums could showcase exhibits without requiring users to learn and use a fully-featured viewer, expanding their potential audiences.
  • Virtual support groups: Virtual support groups — especially those that use text chat instead of voice — could meet in-world without the steep learning curve of the full viewer.

Sure, you can do all that already with Unity-based platforms like Jibe and Unifier, or with Cloud Party. But those platforms are expensive, and require professional content developers to create the 3D environments. In addition, they’re proprietary — you can’t easily take a world from one to another.

OpenSim allows amateurs to create content, or to use the vast amounts of content already available for free or at low costin the OpenSim universe.

Finally, a viewer that is compatible with OpenSim will also, by default, be compatible with Second Life. This will allow existing Second Life region owners to provide easy Web-based access to their builds — and create an easy migration path from Second Life to OpenSim.

Once the basic viewer is created, I hope independent developer groups and grid owners will rapidly start adding features that they want to see the most, such as voice, media-on-a-prim, inventories, payments. search, groups, and, at some point, maybe even appearance and building tools.

Missed opportunity for Linden Lab

Personally, I think this would be a great opportunity for Linden Lab to make Second Life the portal to the metaverse, by creating a proprietary Web-based viewer that would allow it to promote its own land offerings and virtual currency — and protect its content — while allowing users to visit other grids.

I firmly believe that a Web viewer is inevitable. The question is, will it come sooner, or later? And I believe that the growth of the hypergrid, which already covers more than 100 OpenSim grids, is unstoppable.

By staying on the sidelines, Linden Lab is creating opportunities for open source projects to control the direction of the metaverse.

Which, actually, is probably going to work out just fine.


So how much time — and money — would a project like this cost?

Is there anyone out there interested in taking it on — either as volunteer developers, or for a bounty, or with crowdfunding?

Related Posts


Maria Korolov

Maria Korolov is editor and publisher of Hypergrid Business. She has been a journalist for more than twenty years and has worked for the Chicago Tribune, Reuters, and Computerworld and has reported from over a dozen countries, including Russia and China. Follow me on Twitter @MariaKorolov.

23 Responses

  1. graymills says:

    While I appreciate that the target here is the desktop, the proposed feature set is very similar to that of the Lumiya viewer for Android (apart from zoom to surface and hypergrid) which may also emerge for iOS in due course. Overall Lumiya exceeds your spec in several dimensions as it supports inventory, notecards and communication by IM, payment and sharing. Although it’s a closed source commercial viewer (a development route you omitted in your previous article), it’s perhaps worth shadowing its features at a respectful distance (making use of the benefits of a larger screen, of course) so that folk can swap to mobile without having to learn a totally new interface. Of course, WebGL may eventually arrive for mobile but that’s not an argument against using Lumiya in the meantime.

    • I don’t mind seeing commercial attempts at an easy-to-use viewer.

      But if I’m donating money to a project, I’d rather it be open source.

      Meanwhile, I think your idea about shadowing feature sets — whether of Lumia or something else — is great.

      I think there is room for multiple viewers in the metaverse, and that competition would be a net positive all around.

  2. It makes sense !
    I would be happy to help in some way.

  3. This might be a good startingpoint:
    No graphics, but all the login stuff is taken care of.

  4. Ener Hax says:

    i like the bare minimum features you list – a form of login to make sure only valid accounts can reach my work and the ability to sit on things and walk/fly. i don’t need any build or edit tools in that viewer and not even any inventory actions (not even being able to give and accept items). Purely visual and movement

    text chatting would be nice (just like kataspace which has been around for two years now)

    and just a not on OAR preview – sim-on-a-stick! it takes only seconds to load OARs – hmm, might be today’s blog post! =)

    i very much like your view on what this viewer should have and think Kataspace is a nice example. if someone has not tried Kataspace, they should just to see how it works

  5. stiofainx@gmail.com' Stiofain MacTomais says:

    What sort of “ballpark figures” are we talking about?

  6. dahliatrimble@gmail.com' dahlia says:

    Ballpark figure? I’m certain there’s several $million of dev costs gone into the LL viewer, in fact it wouldn’t surprise me if LL had spent $100 million or more to date. And then there’s all the thousands of free dev hours contributed by the open source community…

    Cloud Party has the advantage of starting fresh with fresh new content. Some SL/OpenSim content is amazingly complex and would likely bring a javascript/WebGL based viewer to it’s knees. I’ve seen the Cloud Party viewer become very, very slow when just displaying a few more meshes than one sees in a typical island. They have some severe limits on the quantity of content that cis allowed to exist on a “island” and I suspect there’s good reason for it. Javascript and WebGL add a lot of overhead over c++/OpenGL and impose some interesting limitations (websockets as only allowed networking) that may make imitating a SL viewer nearly impossible.

    I’ve seen some amazingly detailed content and beautiful particle effects in SL and OpenSim, as of yet I’ve only seen very simple objects in Cloud Party. I’m hesitant to assume that the technology Cloud Party uses is capable of displaying a typical SL/OpenSim scene and still have usable performance.

    • graymills says:

      Good and somewhat chastening contribution.

      Looking at it from the opposite direction, I wonder how many people would be willing to modify or scale back their builds to accommodate WebGL if that became necessary. It’s the approach I’m adopting with Lumiya. While I think the latter is a remarkable app and does something I want to factor into my teaching, it does have a fairly long list of unsupported features at the present time so compromise is required. Of course, it’s also quite new as a 3D app so that list may shorten over time.

      I see from their forums that Cloud Party is now running, albeit erratically, on jailbroken iPads.

    • graymills says:

      I think the other assumption is that a web browser is the stumbling block to widespread adoption. A recent piece in NWN suggests otherwise — it’s persuading folk there’s something worth their time inworld. That’s something Cloud Party will have to grapple with as well, WebGL or no.

  7. j.no.net@gmail.com' John Norris says:

    I often wondered if a minimal client would be something like a combination of AjaxLife and inworld snapshots taken every so often. Another possibility might be exploring alternative presentations such as TextSL.

    Perhaps one needs to get past the idea of not being immersed, but instead looking through a window into the world.

    • graymills says:

      There was something like that previously with the LookingGlass extension to Radegast iirc although Radegast has native 3D itself now

      • j.no.net@gmail.com' John Norris says:

        Thx graymills. I hadn’t seen it before and it looks intriguing. (Apparently I don’t get out enough.)

  8. Ener Hax says:

    is there a Kickstarter (or similar) page up yet for this?

    • No, someone needs to step up and commit to actually doing the project.

      And while I might talk big, I actually have zero ability to put a viewer project together.

      However, I’ve been emailing with some folks who might be interested, and if anything gels, I’ll definitely be writing about it.

  9. One advantage of doing something in WebGL (like Cloud Party did) is that most of the rendering work can be used by a 3rd party engine. A quick search for “webgl 3d graphics engine” found the following engines:

    CopperLicht (http://www.ambiera.com/copperlicht/) (there are free, €79 “student” and €1900 “commercial” editions)
    CubicVR 3D (http://www.cubicvr.org/cubicvr-js/webgl-cubicvr) Seems to be free.
    CloudMach (http://cloudmach.com/) Price unknown
    SceneJS (http://scenejs.org/) Open source, but probably not good enough for real-time rendering
    Oak3D (http://www.oak3d.com/) Open source, but still in development
    A few more can be found here: http://html5gameengines.com/tag/webgl/

    So what this means is that one of the “hard” parts — the engine — can be pushed into an existing WebGL 3D rendering framework. That’s good.

    Then there is the other side of the issue: connecting to the virtual world. Most TPV viewers are based on LL’s code, so they cannot be easily ported. Radegast is written in .NET and uses the libopenmetaverse — also a bit useless for a WebGL project. I have no idea what Lumiya is written in. I believe that the few iPhone apps that do text chat in SL use Mono encapsulated around Apple’s SDK, so they can run libopenmetaverse (very slowly on my old iPhone) inside the iPhone and thus avoid porting it to Objective-C…

    So this would mean effectively “porting” libopenmetaverse into JavaScript. Or at least a substantial amount of it. I would say that this would be the hardest part of the project, even for “minimal” interaction. The advantage is that libopenmetaverse is a hopelessly confusing bit of code (heh!) and the “port” to JavaScript might actually give us a leaner and easier-to-understand library…

  10. lordsirm@gmail.com' LordNine says:

    Again, I think you should talk to the RealXtend folks, as they have already begun tackling these very issues and have a bit of motivation to try and make their viewers cross-platform usable (scratch opensims itch while providing a look at thier own platform).
    A few interesting tidbits from their user/dev groups:
    Observations on Cloud Party –
    Growing support for OpenSim compatible viewer –
    Summer News and a Look Forward (Testing of different rendering methods including a WebGL+Javascript viewer.) –

  11. x@y.za' tx0h says:

    i even could live without prim support and a pure mesh based client. this would ease up a lot of things.

    i could imagine it could be possible to strip functionality from the linden based clients and use a llvm based compiler like emscripten ( https://github.com/kripken/emscripten/wiki ), which compiles the llvm code into javascript/webgl.

    this, maybe, is an easy way to go. but i’m not sure if the javascript which gets produced by emscripten isn’t to heavy and slow.

    but in any case, we need a webgl client, asap. else cloudparty or others will adopt the 3d web world.


    • ilan@kitely.com' Ilan Tochner says:

      Hi tx0h,

      The SL viewer codebase is very big and not designed for asynchronous loading. This means that even if you successfully converted it in its entirety to JavaScript, had it all working the same, got reasonable runtime speeds and got a download size which isn’t bigger than the standard compiled C++ SL viewer, then you would still be left with a very big JavaScript file that would need to be downloaded before the “viewer” would start running. This would result in a very long loading delay for the page containing the “viewer” even before the viewer started rezzing anything.

      In order to create the same user experience as you get with cloudparty you’d need to have a “viewer” that loads the basic functionality very quickly and loads the rest of the “viewer” asynchronously. IMO, creating such behavior would be easiest to achieve by taking one of the various realXtend branches designed to work in JavaScript and adding the missing components by compiling them from C++ to JavaScript using Emscripten. The result would need modifications to load things on demand but that should be easier to achieve than trying to optimize the SL viewer codebase to do so.

      • rossinimarcus@yahoo.com' Marcus says:

        Hi, I know of other worlds like Entropia Universe which although client side unlike Opensim, used a combination of Java and C++ I believe to create their World which has massive landscapes, can hold large numbers of avatars and (room) region crossing when you eventually have to is seamless, maybe a web version of this is possible. If so hopefully it uses a Open Source server.

        I think the days of expecting people who don’t intend to create anything in Opensim to use a Viewer is probably numbered, certainly for the type of new people joining SL these days for example, majority of them don’t want to do tutorials or need all the bells and whistles that the current viewers have. Keeping it simple is always going to appeal to the non creative users.