[Public WebGL] 3D Game Platform for the Open Web?

Kripken [email protected]
Thu Jan 28 00:34:22 PST 2010


Chris, thanks for the detailed explanation! That was very helpful.

- kripken


On Wed, Jan 27, 2010 at 1:23 AM, Chris Marrin <[email protected]> wrote:

>
> On Jan 26, 2010, at 12:46 AM, Kripken wrote:
>
> > ...
> > Ok, back to the subject at hand: While we have some open solutions for 3D
> on the web like WebGL and O3D, they are not complete game engines. I don't
> think they are suitable for the kind of content I am talking about here (but
> please correct me if I am wrong!), which is games with full multiplayer
> support, physics and complicated world geometry, AI, etc., like FPS games
> and so forth. Some of that stuff might be added to WebGL and/or O3D using
> JavaScript. However, many games are too computationally intensive, even with
> the best JavaScript engines out there. So, I believe that we need a native
> code game engine for the web, for the other intensive computations game
> engines need aside from rendering.
> >
> > I am therefore asking for feedback about this topic in general, and
> specifically about using the Intensity Engine for that purpose - it's open
> source, and I believe it fulfills the necessary requirements (see below for
> technical details about it). So, to make it relevant for the web, I am
> considering some options:
>
> I think it would be a mistake to try to back port an existing native engine
> to WebGL. This is a personal opinion, but its based on a lot of code I have
> seen out there today. You mention all the different sources you've mined for
> the various capabilities of your engine, and that's a great feature of Open
> Source. But much of the legacy OpenGL I've seen out there is very heavily
> designed for desktop, often fixed function, OpenGL pipelines. You could port
> all that code to WebGL by hand (difficult) or by using shims to adapt the
> desktop OpenGL constructs to WebGL. But the result would be inefficient in a
> part of the code where efficiency is really crucial.
>
> In the coming months and years we'll see many libraries being written on
> top of WebGL. Some will be ports from older systems, but I think the best
> will be new libraries written from scratch designed specifically for WebGL
> and the other technologies that are available in a web browser. If you were
> designing an engine and had Web Workers available, how would you use them so
> you could take advantage of multiple processors? How much work that you now
> do in the CPU could you offload to the GPU if you had shaders available? How
> would FBOs help you improve performance, and could you arrange your VBOs to
> maximize triangles rendered and minimize rendering calls?
>
> We will no doubt hit a wall at some point with JavaScript performance
> limitations. But it's not a straight "JavaScript runs n times slower than
> the native CPU and therefore a game will be n times slower" relationship.
> And as these new libraries are written we will find out where the real
> bottlenecks are and improve on them in future revisions. But first we have
> to get the libraries written.
>
> -----
> ~Chris
> [email protected]
>
>
>
>
> -----------------------------------------------------------
> You are currently subscribe to [email protected]
> To unsubscribe, send an email to [email protected] with
> the following command in the body of your email:
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://khronos.org/pipermail/public_webgl_khronos.org/attachments/20100128/54130997/attachment.html>


More information about the public_webgl mailing list