Building a web client
Henrik Bennetsen
at Sirikata we have been thinking about building a web client for a
while. Some of you may have caught Berkelium and Sirikata's Web Socket
Compatibility announcement along the way as web integration come into
stronger focus for us. We have now become convinced that we should build
a thin web client that connects to the Sirikata protocol. We would love
to see the same client connect to OpenSim or other virtual world
platforms, so this email is our way of testing if anyone is interested
in joining our project to build a liberally (we usually use BSD)
licensed web client.
Here are some of things we are currently thinking about building an
implementation:
We are pretty interested in O3D but have ultimately concluded that the
standardization of WebGL is closer and that it will see support on a
wider range of platforms and browsers, so this technology is what we
should base our work on.
We have have been looking into the emerging landscape of WebGL
frameworks and feel that currently the GLGE (currently LGPL but the guy seems open to going BSD) scene graph library presents
the best performing, most full featured starting point for our
development of a rendering library to render scene graph changes (passed
as deltas) from both networking and physics worker threads.
Nothing is carved out in stone at this point so feel free to give input
of any kind.
Cheers,
Henrik (on behalf of the Sirikata team)
Alon Zakai
--
So far I've been doing some tests with various browser plugin approaches, and asking for feedback and advice on some relevant mailing lists, see this blog post from the other day (and links therein),
http://syntensity.blogspot.com/2010/01/3d-and-open-web.html
- kripken
Daniel Reiter Horn
the end when you say
"One concrete idea among others is to port the Intensity Engine's
rendering system to O3D, and build a browser plugin of the result."
I think that's an excellent plan, but also one that would require a lot
of new code, since the whole engine would have to reside entirely in
javascript.
I think such a plan would be remiss not to include a switch to render to
WebGL as well as o3d (much like, for instance, the ogre engine renders
to both OpenGL and DX). We have no idea which technique will win in the
long run, but the ability to choose should come naturally with good
software engineering.
Where I disagree, however, is in the suggestion that a stand alone
plugin will become the next 3d in the web standard. If anyone wins that
game it will be Adobe with their flash plugin--that's the only plugin
with an install base you can count on. And your whole article is about
how we should avoid flash on the web.
So I think lets go with plan (a) intensity engine, or something similar
that we all build together ontop of o3d and webGL. I'm coming at this
from the webGL side, but again, the decision is only super important if
the software is poorly architected and does not expose a scene graph to
the rest of the app upon with both o3d and webGL backends may be
constructed.
My gut feeling here is that we should use event passing to get between
network and physics webworker threads and the main thread (with access
to the dom--the graphics thread that is). This means we need to define
an event model to update the scene graph--and suddenly whether we choose
o3d or webGL to reflect that stream of scene graph deltas seems to
matter a lot less as long as we're resigned to javascript land and
Thoughts?
-Daniel
On Thu, 2010-01-28 at 11:26 +0200, Alon Zakai wrote:
>
> We've been thinking about this as well. It seems though that a 100%
> web client would be limited in terms of rendering quality (although
> O3D might help with that), responsiveness/suitability for high-speed
> games (due to using TCP), and overall slowness (due to using
> JavaScript for client-side physics, AI, etc). So our inclination is to
> make a browser plugin instead (but just like with you, nothing is
> carved in stone yet). If there is interest in collaboration on that,
> that would be great.
>
> So far I've been doing some tests with various browser plugin
> approaches, and asking for feedback and advice on some relevant
> mailing lists, see this blog post from the other day (and links
> therein),
>
> http://syntensity.blogspot.com/2010/01/3d-and-open-web.html
> from the article:
> "One concrete idea among others is to port the Intensity Engine's
> rendering system to O3D, and build a browser plugin of the result. The
> benefit being O3D is already set up as a browser plugin, while the
> Intensity Engine provides all the other game engine stuff.
> Alternatively, we can just port the Intensity Engine as-is to be a web
> browser plugin, assuming that would work with SDL (if not, would need
> to work on replacing that)."
> - kripken
Ryan McDougall
Having a web client I think is something we've all thought about quite
extensively. At first I was quite against it, as it was awkward on
many levels:
* the web itself is inherently document oriented -- fundamental
mismatch from the very get go that filters into every consequence
* the browser UI is tailored to viewing linked documents. totally
inappropriate for immersive worlds.
* communication happens over document transfers, not real-time streams.
* 3D requires its own custom plug in any way, which are usually
awkward to install, and amounts to little more than using the web
browser as a plugin launcher.
So basically I felt it made sense to have a "web engine" (something
that does speaks HTTP, renders HTML, and runs JS) in a VW client, but
not a VW client in a browser. It'd be like making a truck by fitting
an auto-mobile around a box, rather than fitting the box onto the back
of the auto-mobile.
However with HTML5 and WebGL, that equation is changing slightly.
WebGL gives you 3D in JS, without any awkward plugins -- heck you can
even just download your rendering engine embedded into a webpage! Yet
even that is clearly not enough. IIRC all the O3D demos used a scene
rendered from a static document still. Not a streamed interactive
world.
But now with Web Sockets coming soon, you a proper two-way protocol
suitable for streaming a world. It remains to be shown whether it's
feasible, but I like the possibilities.
My current vision is essentially that web browsers are morphing into
two parts: a "web browser" and a "web engine". A web engine a back-end
application host/sandbox that runs applications built on HTTP, HTML5,
JS, WebGL (and others: SSL, Web Sockets, etc). A web browser is the
front-end UI (plus ad-block, password/form field saving, etc.) that
most of us consider a web browser.
I still feel that the front-end is mostly unsuitable for serious VWs
(although it hits maybe 80-90% of the casual "light" use cases, which
is important), but that the back-end is for the first time capable of
hosting a fully functional VW viewer.
The way I see this proceeding through history, is that a "web
engine"-based viewer will be *the* "light" to "medium" VW viewer going
forward. Most people will use these to consume the content of a VW and
participate in 80% of the use cases. However, I still feel for
"heavier" use cases, a dedicated client, with a dedicated UI will be
required. I cannot imagine that HTML5 will exceed what say Qt or WPF
etc.
I'd like to participate with all you guys on a web client, as I think
it's smart, and I can imagine realXtend using this web client in
*many* cases. But I do not believe that we will stop work on our
current efforts.
Cheers,
Hurliman, John
John
Henrik Bennetsen
Alon Zakai
I am doubtful about being rendering-system agnostic here. OpenGL and DirectX are a clear parallel of each other - their calls are so similar, you can even translate them 1-to-1 (as Wine, in fact, does). But WebGL and O3D are not like that. For one thing, O3D stores the state of all the rendered objects and issues calls itself, while in WebGL you need to issue them. In other words, WebGL and O3D are like OpenGL and Ogre, not OpenGL and DirectX. And I am unaware of engines that are rendering-system agnostic for things like OpenGL and Ogre.
Second, Flash does not worry me. Flash's 3D capabilities are limited, and even should they add more, it is far from a full game engine (and building one in ActionScript won't work either). What does worry me is Unity. We need something open source to counter that. And, to have decent multiplayer capabilities+performance, I don't see how we can avoid creating a new browser plugin - since we need UDP, fast physics in native code, etc. The performance just isn't there, our tests show, for a pure WebGL+JavaScript solution. But I think we *can* succeed with a browser plugin, if done right.
- kripken
Alon Zakai
If you want 3D rendering for a thin client for a virtual world, then WebGL is certainly the way to go. You will need to wait a while for it to mature, but it will get there.
On the other hand, if you want a 'thick client' with client-side physics, the possibility for fast-paced games, and more complex rendering, then WebGL will not allow that, even after an arms race to speed it up. What *might* help here is something like NaCl. But barring that, really the only option is a browser plugin, and especially if we want something that works now, which I believe is important given the state of the closed-source competition.
- kripken
Daniel Reiter Horn
> I think it really depends on your goals here.
>
> If you want 3D rendering for a thin client for a virtual world, then
> WebGL is certainly the way to go. You will need to wait a while for it
> to mature, but it will get there.
The conversation I'm starting here is about a thin client that will
serve 50-80% of the use cases... because remember 50% of 10x the users
who will refuse a plugin download is still 500% of what you'd get if you
got 100% of the users willing to download a plugin.
>
> On the other hand, if you want a 'thick client' with client-side
> physics, the possibility for fast-paced games, and more complex
> rendering, then WebGL will not allow that, even after an arms race to
> speed it up. What *might* help here is something like NaCl.
NaCl will get there eventually--and if we have something to drop it into
and understand the bottlenecks (so we can say: get nacl and our
javascript based client is 10x faster) it will be smoother
> But barring that, really the only option is a browser plugin, and
> especially if we want something that works now, which I believe is
> important given the state of the closed-source competition.
I fear this is something that will be difficult to catch up with. The
unity folks have dozens of engineers working on this full time. We have
at best a handful of folks who each have a different engine preference
(try getting ryan and co to switch from RealXtend--try getting us to
switch from our sirikata client, etc).
The way to "win" in an open source way is to compete in a different
niche, win there..and use the new resources to win in the original
place. If the commercial products are going thick client, we should win
at thin client while it's ripe and spread our influence to thick client
once the thin client is solved.
It's also easier to get everyone on board if we're all on an equal
playing field of 0 code, 0 investment.
> --
> http://groups.google.com/group/kyoryoku
Ryan McDougall
> http://groups.google.com/group/kyoryoku
The next step in this discussion is to start benchmarking WebGL and
WebSockets to see just how feasible a real time engine would be. Are
there any implementations of web sockets? I think at least chrome has
one.
In a similar vein, here is freeciv testing svg performance for their
client: http://code.google.com/p/freeciv-forever/wiki/FreecivBenchmarkResults
Cheers,
Ewen Cheslack-Postava
http://blog.chromium.org/2009/12/web-sockets-now-available-in-google.html
-Ewen
Alon Zakai
On Thu, 2010-01-28 at 22:14 +0200, Alon Zakai wrote:The conversation I'm starting here is about a thin client that will
> I think it really depends on your goals here.
>
> If you want 3D rendering for a thin client for a virtual world, then
> WebGL is certainly the way to go. You will need to wait a while for it
> to mature, but it will get there.
serve 50-80% of the use cases... because remember 50% of 10x the users
who will refuse a plugin download is still 500% of what you'd get if you
got 100% of the users willing to download a plugin.
Ok, fair enough. Sorry if I was changing the focus of the discussion.
Just to clarify, though: From our side the goals are different. For one thing, I think I am the only one present here with short-term financial concerns (the Intensity Engine has so far no funding or sponsorship of any sort). So aside from the goal of getting more users and pushing forward FOSS in this space, I am also thinking about ways to turn a profit in the near future, so we can continue to work on our project full time. With games I can see how to do that; with a thin virtual world client I don't. So 500% more users is less important to me than making the Intensity Engine self-sustaining with a smaller audience. (Alternatively, is anybody here hiring? ;)
But in any case, I disagree with the premise that it limits the userbase. The opposite, I think, is true: there is simply a much larger potential userbase for games than for virtual worlds. Virtual worlds is a niche, while games aren't. So the people that want to play games *and* are willing to use a plugin, might well be more than the people that want virtual worlds altogether (plugin or no).
NaCl will get there eventually--and if we have something to drop it into
>
> On the other hand, if you want a 'thick client' with client-side
> physics, the possibility for fast-paced games, and more complex
> rendering, then WebGL will not allow that, even after an arms race to
> speed it up. What *might* help here is something like NaCl.
and understand the bottlenecks (so we can say: get nacl and our
javascript based client is 10x faster) it will be smoother
I fear this is something that will be difficult to catch up with. The
> But barring that, really the only option is a browser plugin, and
> especially if we want something that works now, which I believe is
> important given the state of the closed-source competition.
unity folks have dozens of engineers working on this full time. We have
at best a handful of folks who each have a different engine preference
(try getting ryan and co to switch from RealXtend--try getting us to
switch from our sirikata client, etc).
Well, I don't know if I agree with that. Your argument might seem to imply open source can never compete with closed source development - which always has more money behind it. But open source does win out in many cases.
And I believe it can do so here as well. In particular, one advantage is that Unity costs a lot of money (for the non-crippled and non-free version). But open source products are free.
The way to "win" in an open source way is to compete in a different
niche, win there..and use the new resources to win in the original
place. If the commercial products are going thick client, we should win
at thin client while it's ripe and spread our influence to thick client
once the thin client is solved.
That is a valid approach. But I personally favor the opposite: Get part of the much larger gaming market, and from that position refocus on virtual worlds.
It's also easier to get everyone on board if we're all on an equal
playing field of 0 code, 0 investment.
I don't understand what you mean here.
daniel miller
> But in any case, I disagree with the premise that it limits the userbase.
> The opposite, I think, is true: there is simply a much larger potential
> userbase for games than for virtual worlds. Virtual worlds is a niche, while
> games aren't. So the people that want to play games *and* are willing to use
> a plugin, might well be more than the people that want virtual worlds
> altogether (plugin or no).
I disagree with the premise that games cannot work in webGL. It
depends of course on what kind of games you are talking about. I've
put maybe 100 hours into fantasticcontraption, a flash game with
simple graphics. "Games" such as Club Penguin and Habba Hotel are
both popular and profitable (also that Pirate guy).
I think there's a *huge* niche for those kinds of 'casual games' to go
3D. No, they won't have 10,000 trolls with shadows, fog, and specular
glints on their shields, but visual 'bling' is not the only factor on
which games can compete. By adding the MMO capabilities and providing
a sensible content pipeline, this could be the platform that finally
puts Flash into the dustbin of proprietary stopgaps (along with
RealPlayer and IE6).
-dan
Ryan McDougall
> On Fri, Jan 29, 2010 at 3:23 AM, Alon Zakai <al...@syntensity.com> wrote:
>
>> But in any case, I disagree with the premise that it limits the userbase.
>> The opposite, I think, is true: there is simply a much larger potential
>> userbase for games than for virtual worlds. Virtual worlds is a niche, while
>> games aren't. So the people that want to play games *and* are willing to use
>> a plugin, might well be more than the people that want virtual worlds
>> altogether (plugin or no).
>
> I disagree with the premise that games cannot work in webGL. It
> depends of course on what kind of games you are talking about. I've
> put maybe 100 hours into fantasticcontraption, a flash game with
> simple graphics. "Games" such as Club Penguin and Habba Hotel are
> both popular and profitable (also that Pirate guy).
>
> I think there's a *huge* niche for those kinds of 'casual games' to go
> 3D. No, they won't have 10,000 trolls with shadows, fog, and specular
From my perspective, I would like to have a general idea of just *how
many* trolls we can get (compared to say OGRE3D); ie. some
benchmarking to demonstrate feasibility and scope.
> glints on their shields, but visual 'bling' is not the only factor on
> which games can compete. By adding the MMO capabilities and providing
> a sensible content pipeline, this could be the platform that finally
> puts Flash into the dustbin of proprietary stopgaps (along with
> RealPlayer and IE6).
>
> -dan
Cheers,
Daniel Reiter Horn
> On Fri, Jan 29, 2010 at 11:10 PM, daniel miller <danb...@gmail.com> wrote:
> > On Fri, Jan 29, 2010 at 3:23 AM, Alon Zakai <al...@syntensity.com> wrote:
> >
>
> From my perspective, I would like to have a general idea of just *how
> many* trolls we can get (compared to say OGRE3D); ie. some
> benchmarking to demonstrate feasibility and scope.
number.
Problem is that GLGE for instance has a number of inefficiencies we're
going to have to hammer out. Same could definitely be said about the
WebGL implementations in the browser
We can probably get you some test numbers fairly soon, but we probably
have an order of magnitude head room--I can imagine a ton of ways we
could bake together functions at runtime that optimize a code path for
a particular object draw (much like a jit does), etc.
and then you could take groups of objects and bake those together.
With a highly dynamic language like javascript, the sheer complexity of
optimizations is endless--so anyone who says that because some demo goes
slow webGL is never going to be fast has probably not investigated all
the options.
Chrome can do a great job optimizing straightline code--and scene graphs
can be rendered with essentially straightline code
But we're definitely not near that point and are still getting rid of
string->float conversions, etc, so lets wait on the overly pessimistic
benchmarks for just a bit longer ;-)
Alon Zakai
On Fri, Jan 29, 2010 at 3:23 AM, Alon Zakai <al...@syntensity.com> wrote:I disagree with the premise that games cannot work in webGL. It
> But in any case, I disagree with the premise that it limits the userbase.
> The opposite, I think, is true: there is simply a much larger potential
> userbase for games than for virtual worlds. Virtual worlds is a niche, while
> games aren't. So the people that want to play games *and* are willing to use
> a plugin, might well be more than the people that want virtual worlds
> altogether (plugin or no).
depends of course on what kind of games you are talking about. I've
put maybe 100 hours into fantasticcontraption, a flash game with
simple graphics. "Games" such as Club Penguin and Habba Hotel are
both popular and profitable (also that Pirate guy).
I think there's a *huge* niche for those kinds of 'casual games' to go
3D. No, they won't have 10,000 trolls with shadows, fog, and specular
glints on their shields, but visual 'bling' is not the only factor on
which games can compete. By adding the MMO capabilities and providing
a sensible content pipeline, this could be the platform that finally
puts Flash into the dustbin of proprietary stopgaps (along with
RealPlayer and IE6).
I didn't mean to imply games can't work with WebGL. Casual games can and will, and much better than with Flash (and indeed good riddance).
But any kind of game with action (sports, FPS, platformer) would not work in multiplayer (nor singleplayer against a remote server-run world), and the worlds would necessarily be small due to physics limitations. That is all I was trying to say before.
In summary, in terms of market,
Casual games >> Action games >> Virtual worlds
And exactly as you say, the casual games approach is the big winner here. But on the other side though,
1. We currently have working FOSS solutions for action games (Intensity Engine) and virtual worlds (Second Life/OpenSim, etc.), but not for web-based casual games. So writing a casual games client entirely using web technologies would take longer than a simple port of an existing, working solution to a browser plugin.
2. The casual games approach relies on WebGL, which is a work in progress, and has some question marks before it:
2.1. Lack of Internet Explorer support - not even planned. (Or, will we rely on Google Chrome Frame - a browser plugin?)
2.2. OpenGL issues on Windows: Often users must manually install OpenGL drivers from the manufacturer's website, which is no better than installing a browser plugin and in many cases worse. (Gamers might already have it installed, but not the target audience of casual games.)
2.3. Unclear performance limits, and an unclear timeline for when we will get clarity on that.
(2.4. Or we can use O3D, but that is yet another browser plugin.)
For these reasons I think a WebGL client is problematic. So I believe FOSS efforts would be best spent on moving our existing action gaming/virtual world technologies to the web as a plugin. And out of those options, I prefer to start with action gaming, as it is the far bigger market of the two.
- kripken
Alon Zakai
Video: http://www.youtube.com/watch?v=BcDeJq38oVA
More details: http://syntensity.blogspot.com/2010/02/browser-plugin-proof-of-concept.html
- kripken
Toni Alatalo
of view to this discussion:
On pe, 2010-01-29 at 13:23 +0200, Alon Zakai wrote:
> <dani...@graphics.stanford.edu> wrote:
> >The conversation I'm starting here is about a thin client that will
> >serve 50-80% of the use cases... because remember 50% of 10x
> Just to clarify, though: From our side the goals are different. For
> one thing, I think I am the only one present here with short-term
> financial concerns (the Intensity Engine has so far no funding or
Also in ReX development we have quite real very short term goals. The
core dev is funded, but we also need to use tech in business. Even Naali
now at 0.1 is being used to deliver apps for customers. And we need more
functionality in it this spring to satisfy upcoming cases. This is why I
think choosing to start writing a new fat client from scratch in March
2009 was not a mistake - we got it done and it works, looks good
too :) .. perhaps something with O3D might have been possible as well,
but also it is quite recent and requires installation etc. Was most
straightforward for us to get going with Ogre where all our scenes and
assets etc. already worked.
That said, the upcoming browser-native webgl is certainly interesting.
So are plugins like O3D and possibly packaging own clients like
Syntensity or perhaps Naali as plugins too. We can not do actual
concrete development work on those right now, at least till the end of
March are keeping the current focus on standalone Naali. But we
certainly want to coordinate enough so that would be compatible with
upcoming browser integrated solutions too.
UI widget development may be one concrete way to collaborate in Naali &
browser client development. We discussed it on irc with one of the
sirikata devs (sorry, I don't know the name! .. but i guess you are
here). We already have written a fair emount of tools to Naali, for
terrain editing and setting materials, and the inventory UI and
mesh&material assignment etc. We now happily use qt for that, most of
the code being c++ with some py too - I tested that javascript via
qtscript works too.
The idea in the discussion back then that we would use html+css+js,
webviews, for widgets in Naali so they'd be reusable in browser clients
too. I was sceptical because many Naali devs so far are happy with c++
and quite productive with Qt - am quite sure that trying to do something
like tabs or treeviews in html+js would be just difficult and cumbersome
for them (I know there are js libs for that, but still). Quite often it
is the case though that people making UIs are different, and those
people are familiar with the web techs - a reason why some game makers
have integrated Qt to Ogre is exactly to get webviews so their designers
can use those to make the UIs. We are now just starting to implement and
further design upcoming Naali UI work (first targeted for late march) so
this is something we can consider now. In any case we want to support
webviews for UIs for apps that open custom UIs from the server.
So we won't be participating in something like webgl renderer writing at
least right now, but are definitely hoping to use it later. And what we
can do now is to consider adjusting our plans and techs so that would
help with the common cause - insights about this UI matter and hints
about other possible areas for code sharing etc. are very welcome.
~Toni