Kitely calls for a push to the web

Kitely CEO Ilan Tochner told Hypergrid Business this week that the Second Life and OpenSim viewer can be ported to HTML 5 and Web GL in a matter of months — and he’s looking for people to help accomplish that.

Kitely CEO Ilan Tochner

Tocher said that’s he’s received a commitment from Alon Zakai of Emscripten to convert the viewer’s C++ code into Javascript and WebGL — but only if other people can help out and do some needed preparatory work.

Tochner said he hopes to meet with OpenSim and viewer developers on Friday when he is scheduled to speak at theΒ Metameets conference in Amsterdam.

“I hope to gather enough support to get this off the ground,” he said.

Zakai has already demonstrated this technology, most recently with a conversion of Doom and of the Bullet physics engine.

“Instead of having a castrated Unity 3D viewer, you’d have the latest and greatest Second Life viewer compiled into Javascript,” said Tochner. “That could be huge for OpenSim and virtual worlds — and could be huge for Second Life itself, if they could have the technology.”

Users would still have to wait for the viewer to load the first time they visit a Web-based virtual world that uses it, but after that it would be cached in their computer’s memory. However, there might be some savings since the viewer would no longer need to have a built-in browser, since it would already be running in one.

Viewer developers would need to rewrite some code to use existing Web technologies to display in-world Web pages, images, and video.

Performance hits

Running a full viewer in the browser will entail some sacrifices, however.

For example, it will be slower, said Zakai.

“But I don’t know how much,” he added. “Expect one-tenth of the original for non-shader code, whereas shader code will run at the same speed. How much slower overall depends on whether shaders are used properly.”

In addition, the viewer will require more memory, he said, estimating that memory requirements would increase four times, without special optimization.

There are also some input issues. For example, Web browsers can’t do the mouse capture necessary for the mouselook view, Zakai said.

“And voice is not there yet in Web browsers, but is actively being worked on,” he added. “Running code like this on the web is a fairly new thing, and it is common to encounter browser bugs and inconsistencies. But, this is getting better all the time.”

Convention Center at KatiJack Emporium on Kitely. Web access would allow conference participants to visit the world without installing a viewer.

Easier user experience

On the plus side, users wouldn’t have to download or install any software, and companies wouldn’t have to worry about opening up their firewalls.

For Kitely in particular, a Web-based viewer would a breakthrough, he said.

Kitely offers easy to use and easy to create OpenSim regions — but users have to download and install a Second Life-compatible viewer in order to access them.

Tocher said that his company can’t do the viewer work itself, because they are GPL-licensed — and that would mean that company would have to stop contributing to the BSD-licensed OpenSim community.

“We already submitted four patches to OpenSim in the last few weeks, and want to continue doing that,” he said. “We need help from people to volunteer to do technical work, people who don’t have legal limits that prevent them from doing it.”

Tipodean's BuiltBuy.me viewer uses Unity 3D and runs in a Web browser, but offers very limited functionality.

The end project would be open sourced as well, he added, and available for anyone to use.

“If we get the community involved, we could be months — not years — away from having a working Second Life viewer with all the features.”

The main thing that needs to be done is to create a way to handle UDP messages. The Second Life-compatible viewers make heavy use of this messaging standard, which is not supported by Javascript.

“We need to either change it to HTTP or do some type of proxy — with a Kitely plugin or a Flash-based proxy — to move the UDP to the server,” he said.

The Flash alternative would be easy to set up but would keep the viewer from running on the iPad, he added.

UDP is important for games that require fast reactions.

“Even Whisper voice uses UDP, since there’s no reason to re-transmit a packet if you miss it, because it’s no longer relevant,” he said. “I hope that the people who are pushing WebGL include it as a standard option so that people don’t have to use hacks to create gaming applications.”

According to Zakai, creating a workaround for UDP will also add some lag to the Web-based version of the viewer.

Another conversion issue involves graphics.

Converting OpenGL ES to WebGL is reasonably straightforward, but requires an OpenGL expert, Zakai said.

However, if the viewer uses general OpenGL, then the translation would “be a significant undertaking,” he added.

More technical details about the project are available on the company’s Get Satisfaction discussion board. Those interested in contributing can post on that board as well.

maria@hypergridbusiness.com'

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.

  • Call me skeptical. I'd love to see a web viewer for SL / OpenSim that's fully functional. Kitely acknowledges a couple of the major issues when they mention that it may require "4 times" the memory to run it, at a reduced performance. Also, it has the disadvantage of running at the same time as a browser, which can typically eat up half a gig of memory.

    But beyond that, Kitely should be correct in their assessment that the code should be convertible from C++ to … well, I personally don't think Javascript is an option, but maybe full-on Java. But that task isn't just requiring an OpenGL expert, it's going to require someone who is an expert in both the source and target language. And there will be immense amounts of bugs porting it over, just from differences in the languages. Whole chunks of code may have to be rewritten just because of minute differences in how each language might handle a class, or a particular data type.

    But on top of that, there's an even larger, monumental problem. The SL viewer code is a frigging mess. When I started working with it myself, I was shocked just how undocumented and undisciplined it was. Global variables are band-aided on whenever someone deemed necessary. There's pretty one enormous megalithic data structure that represents the user – that is so wide, it encompasses everything from in-world data to graphics display. And when I say undocumented, I mean – literally – you look in the code, and there's almost never indications on what functions do, how they relate to other areas of the code, etc. It's amazing that 3rd party viewers exist at all.

    Frankly, if someone's interested in a web-based SL viewer, I'd rewrite the whole damn thing from scratch. And that would require a new team of people, one of which would need to be a communications guru who has intimate knowledge of how the viewer does its messaging with the server – something that's technically still closed-source and anyone who worked at Linden Lab may be prohibited by NDA from working on.

    So … good luck?

  • Hi Ron,

    There are limitations to using JavaScript but, unlike Java, it is the only thing out there that truly works on all platforms. Java itself is no memory light weight and requires about the same multiple of RAM as unoptimized Emscripten created JavaScript when compared to C++.

    The beauty of this solution is that Emscripten can work with obfuscated code with no documentation as easily as it does with well written and documented code. It's a compiler and it's creator has already gotten many C++ codebases compiled (see live demos on its site). It works by compiling C++ into LLVM which defines classes, data types etc. and then compiling the LLVM into JavaScript. This solves many of the problems you have mentioned. If you are interested in some additional technical details please go to our support forum (link provided in Maria's post).

    I agree that ideally we would create a better viewer code base but let's face it that can take years to write and this solution can get us to have functionality party with the existing SL viewer within months (and retaining that capability thereafter – with occasional bug fixes to Emscripten when we find them).

    So… Thank you πŸ™‚

  • Being the CEO of Unity I am admittedly slightly biased, but I think that it's a little unfair to call Unity "castrated" followed a long list of how a Javascript client would be extremely limited in performance of functionality (whereas a Unity viewer wouldn't be in terms of performance or functionality).

    Or maybe I'm just too sensitive πŸ˜‰

  • iliveisl

    i think many people have been pushing for this, including yours truly

    if only it were that easy! JavaScript can also be very heavy on the client (converting Flash games to "html 5" is just gobs of JS that always runs way heavier)

    Google's O3D is closest (imo)

    Ilan, stick to getting the bugs out of Kitely first and make it bullet-proof (and also remember your original big fans that got the word out – they might have a pretty good clue about social media . . . . ) =D

  • While I admire Ilan of Kitely's vision I personably think Unity is the best bet currently for a browser based Opensim viewer, albeit a limited one. I can't really see any alternative to getting a full viewer to experiencing Opensim and using it's full feature set properly. A browser-based viewer is certainly good for an introduction that, hopefully, will encourage the visitor to get interested enough to take more time and trouble to download a viewer.

    I agree with ilivesl, getting the bugs fixed in Kitely and opening up the system to more registration options is what I think they should consentrate on.

  • Hi David,

    I'm Ilan's co-founder at Kitely. I would like to clarify the remarks about Unity: we like Unity3D a lot and we may use it in the future. The term "castrated" referred to the feature-set of a hypothetical viewer that would be written from scratch, since it would take a long time to implement everything the current SL viewers can do. We certainly didn't mean that Unity3D itself is limited: clearly it's extremely capable.

  • To anyone who's concerned we (Kitely) are getting sidetracked: don't worry πŸ™‚
    We don't intend to work on this project directly. As Ilan has said, there would be legal problems if we were to work on the viewer code since I have already submitted patches for OpenSim and will continue to do so. And we are very much focused on the things we need to do to improve Kitely in the short term. However, the potential to create a full-featured web-based viewer in just a few months is exciting. Since we know OpenSim, and we know Alon Zakai (the creator of Emscripten), we would like to help jump-start this project.

  • Hi David,

    I think Unity is a great technology and I was in no way implying otherwise. I wasn't criticizing Unity as a platform but rather the virtual worlds solutions for SL / OpenSim access that are currently built on top of it. That said, I think the future of the 3D internet shouldn't be built on a solution that is proprietary to one company. That is why I personally prefer seeing an HTML5 + WebGL standard emerge for virtual worlds rather than one based on your company's (admittedly very impressive) technology. I'm sure that if you weren't involved with Unity you would share this belief as well.

    Hi Ener,

    The download size of a minified Emscripten generated JavaScript is most likely smaller than the size of the original C++ compiled executable (see the link to our support forums for additional info). RAM requirements are not ideal but those can be addressed (at least somewhat) with optimizations. Execution speed for the OpenGL code (which is GPU limited if implemented correctly, e.g. batching) would be about the same as that of the C++ based viewer. Execution speed for CPU limited code would be 10 times slower now but JavaScript execution engines are constantly being improved in browsers. It won't be too many years until the speed difference and the increased CPU speeds of the executing devices would make this a non-issue.

    We are not changing focus, we got Alon Zakai, the amazingly talented person who created Emscripten (who is not part of Kitely), to agree to spend the required amount of time and effort to get this done if the community helps with the two missing pieces (UDP proxy and adding an OpenGL to WebGL conversion layer to Emscripten). What is required of me is to try to get the community on board this effort. Oren is not diverting his attention from perfecting our own solution so this shouldn't effect our roadmap in the foreseeable future.

    Hi Gaga,

    Kitely supporting a web based viewer and a downloadable one isn't mutually exclusive. Our plan is to enable people who have a virtual world viewer installed to be able to use Kitely as they do now (with the Kitely plugin) and people who don't have it installed to be able to jump right in and get the basic mode SL v2 (or derived) viewer without needing to download anything. The benefit of this approach is that whenever a new feature is added to the viewer it can be compiled into the JavaScript based one as well and not require people to start implementing this new feature using some other codebase (which can take many months to do and will lead to the web-based viewer always being far behind the C++ based one).

    As I told Ener, we are not diverting our development efforts. We got someone who isn't part of Kitely to agree to work on this if other people help with the pieces missing from Emscripten.

    We are holding the course, we just got more people to help pave the way to a better standards-based virtual world future for everyone.

  • Two questions:

    1. Will any of these options support tablets or smartphones?
    2. Will any of them support LSL?

  • Would there be any merit in using a lightweight viewer such as Radegast for the prototype?

  • Hi graymills,

    Tablets and smartphones may or may not be supported depending of whether the browser they have installed suports WebGL and the type of solution we will implement for handling UDP networking between the viewer and the server (a flash based UDP proxy for example should work on Android based devices but not on iPhones and iPads).

    Once we gather the required community support we will need to work in stages. Using a lightweight viewer which uses a smaller subset of OpenGL's capabilities may make sense.

    The graphics and networking components that need work do not effect LSL suport on the viewer. The goal is to be able to retain the same capabilities as the original C++ viewer.

  • Chris Collins

    For the builtbuyme viewer the limited functionality is intentional. We could implement everything that the SL viewer does but we are trying to go for fast onboarding of users into OpenSim. As anyone who has tried to do a large rollout of of SL or OpenSim would know the download is one barrier but the amount of things you need to learn with editing appearance, building , camera, moving is another. I am a huge fan of the potential that WebGL offers but once you start getting up there on the poly count WebGL still has some work to do. On the other hand Unity gives me much more flexibility in that regard and already can run and be deployed in multiple ways

    Good luck guys, innovation is a good thing and I love where you guys are pushing things

  • Hi Chris,

    My personal preference for an open standards-based solution aside, I like your initiative as well and wish for its success. I think it is extremely import that the viewer UI be simplified for the general public and I love that you are taking this approach.

    There is no reason why OpenSim based worlds shouldn't be accessible from both existing SL-derived viewers, a builtbuyme Unity-based viewer and HTML5+WebGL based viewers. Each can have its benefits to a different user base with different needs. It's great when people have options and I'm waiting to see how yours develops. Once we develop the ability for direct grid login, there is no reason why Kitely shouldn't be accessible from your viewer as well.

  • Lawrence Pierce

    As I see it, the primary attraction of virtual worlds is the experience of immersion. Otherwise, the critics have a point when they say there are more efficient, mature and effective solutions to delivering content.

    It is disappointing to say the least that computer users are, or are perceived as being unwilling to deal with a separate application to view virtual worlds. I think there have been multiple reasons the masses have not flocked to virtual worlds, and the viewer is just one piece. But to the extent that learning the viewer is an "impediment", that's a bit like saying people will never type again because Microsoft Word is too hard install and too complex to learn. People can and do learn many complex things, if they have a strong enough incentive. I'm not against simplifying the mechanics of using an avatar, but even a Web browser is intimidating to the first-time user. The reason people learn browsers or any other computer-mediated interface is that they have their focus on the content they seek, not the mechanics of getting there.

    The Web is already excellent at delivering myriad content, facilitating commerce, and so on. What the Web, lacks, in my opinion, is placing all that content in a context that models the real world, and even extends it in ways not practical in the real world. I would rather tour a realistic and immersive virtual museum to see art than see a table full of thumbnails. I think that in order for the masses to feel the same way, the experience of immersion needs to improve, not regress. If, however, we push to have a Web-based viewer, but with the reductions in capabilites every developer agrees are necessary, it will be one step forward and two back. Sure, more people will log in, just to be more disappointed than ever.

    Because of the ascendency of the tablet form-factor, with much reduced computing power, virtual worlds may suffer more than ever in the short run. I would like to see a dedicated app that is an optimized viewer that squeezes out every last bit of processing power from those fledging tablets. Then, one day, when tablets are finally powerful enough and the Web has matured even further, a Web interface would be like icing on the cake. And of course all that would play out well on desktop computers as well.

    The richness and complexity of virtual worlds are precious and critical qualities, worth preserving and enhancing.

  • Hi Lawrence,

    I agree that the main draw of virtual worlds is the immersion factor and that there are quite a few reasons why virtual worlds have yet to have gained mass market adoption. Part of Kitely's mission is to identify and remove those various barriers to adoption and one of those barriers is the lack of effortless first-time experience.

    The reality is that a solution that doesn't require new users to download and install something will be used by a lot more people than ones that do. Virtual worlds are not the only ones effected by this market truth, many well known startups quickly gained market share simply because their web-based offerings were a lot easier for people to try out and fall in love with than ones that required installing something. Those startups succeeded even though their simple user interface enabled doing a lot less than the installable full-featured applications they replaced (e.g. see the histories of instant messaging applications and email clients).

    Moving the viewer to the web does not necessarily mean a reduction in capabilities. Emscripten, the compiler that will enable us to move the virtual world viewer to the web, has advanced in the month since this article was written and can now generate code that is almost as good as hand optimized JavaScript. This means a reduction in memory footprint and almost a doubling of average execution speed, making it about 5 times slower than optimized C++ and, for certain types of calculations, as fast as Mono (which is part of Unity3D). WebGL is about as fast as OpenGL (which is what 3D graphics employ in all non-Microsoft platforms) and, because well written graphics-heavy applications are more GPU limited than CPU limited, a JavaScript-based viewer can, at least theoretically, provide as good a user experience as an installed C++ based viewer. New development versions of web browser JavaScript engines continue to show significant speedups and, if this trend continues, will eventually offer code execution speeds that will significantly reduce the speed advantages of using natively installed applications.

    Tablets and smartphones may have significantly reduced computing power but if level of detail (LOD) optimizations for smaller display sizes are added to the virtual world architecture then even a web-based viewer running on those platforms should be able to display virtual worlds in reasonable quality.

    Kitely is a virtual worlds on demand utility provider. People can use us with many types of third-party virtual world viewers. That said, we believe that virtual world adoption as a whole will be much bigger once people don't need to install a viewer to start experiencing the benefits VWs can provide. Towards that end we are trying to organize a community effort to recompile the existing SL viewer into HTML5 and WebGL.

  • I realize that I’m a bit late to the party, but what about Node.js and websockets?

    On a separate note, the Ajaxlife online viewer uses libopenmetaverse on a server and the javascript fronted pushes all communications through it.

    What is the status of Emscripten, and using it to build a web enabled viewer?