WebGL

[m3xican]

Today I noticed this article in my RSS reader:

"(PR) Khronos Details WebGL Initiative to Bring Hardware-Accelerated
3D Graphics to the Internet" - http://is.gd/22mp6

I was wondering if that will mean (sooner or later) the end of O3D and
maybe if O3D will be merged/adapted to WebGL in some way, also
considering this excerpt from the article: ”Google is committed to
open web standards and is very excited to be part of the WebGL
initiative”.

Of course nothing is going to change in a near future (WebGL first
public release will be in first half of 2010), but I'd like to know
what the O3D team thinks about it.

--
Davide "M3xican" Coppola

--------------------------------------------------------------------
email: viva...@gmail.com
web: http://www.m3xbox.com
twitter: vivaladav
--------------------------------------------------------------------

[Gregg Tavares]

On Tue, Aug 4, 2009 at 9:37 AM, m3xican <viva...@gmail.com> wrote:

Today I noticed this article in my RSS reader:

"(PR) Khronos Details WebGL Initiative to Bring Hardware-Accelerated
3D Graphics to the Internet" - http://is.gd/22mp6

I was wondering if that will mean (sooner or later) the end of O3D and
maybe if O3D will be merged/adapted to WebGL in some way, also
considering this excerpt from the article: ”Google is committed to
open web standards and is very excited to be part of the WebGL
initiative”.

Of course nothing is going to change in a near future (WebGL first
public release will be in first half of 2010), but I'd like to know
what the O3D team thinks about it.

O3D is not going away.  WebGL is a very cool initiative but it has a lot of hurdles to overcome. The direction of WebGL is trying to just expose straight OpenGL ES 2.0 calls to JavaScript. JavaScript is still slow in the large scheme of things. Maybe at sometime in the future WebGL will have added enough features over basic OpenGL to be more powerful or JavaScript will have gotten a few orders of magnitude faster but at the moment...

A non-exhaustive list problems WebGL will encounter

*) OpenGL ES 2.0 is not supported on lots of common hardware. That means there are a lot of machines that will not be able to run WebGL.

*) WebGL, being 100% dependent on JavaScript to do an application's scene graph, is going to have serious problems drawing more than a few pieces of geometry at 60hz except in very special cases or on very fast machines. This means WebGL requires JavaScript to:

    *) do all parent-child matrix calculations for a transform graph.

    *) all culling calculations (bounding box to frustum or other)

    *) all sorting calculations for dealing with transparent objects.

    *) all animation calculations.

     As an example the kitty demo in O3D is doing linear
     interpolations on 2710 floats to animate 170 transforms.
     The point is not that the artist that created
     the kitty should probably not have used 170 bones. ;-)
     Rather the point is it seems unlikely that JavaScript
     will be able to do that anytime soon and if it can then
     just add more than one kitty to pass its limits.

*) WebGL, being 100% dependent on JavaScript, means skinning will be hard since you'll have to do it in JavaScript or on the GPU. Doing it in JavaScript will be too slow. Doing it on the GPU has issues because it takes many shader instructions to do skinning and there will not be enough instructions to do both skinning and other effects (like shadow mapping)

*) WebGL requires JavaScript to supply all the shader parameters to WebGL.

That means to draw say phong shaded objects requires about 10 GL calls per object, per frame in JavaScript.

1 call to for each matrix you want to pass to the shader (usually 1 to 4 matrices)
1 call for each color parameter ( for phong the minimum would be 2, color and shininess though most phong shaders have 5, emissive, ambient, diffuse, specular, shininess)
1 call to setup position vertices
1 call to setup normals
If it's textured you'll need another call to supply UVs
1 call to finally draw the object
and then possibly a few calls to restore GL state.

That a minimum of 5 calls and in this case a maximum of 13 per object, per frame. JavaScript is going to have a tough time doing that for more than a few objects and keep 60 or even 30hz.

*) WebGL is not trying to solve the data import problem. At the moment, the only way to get a texture into WebGL is through IMG tags. So, no DXT textures, no precomputed mips, no cubemaps in one file. There is also no way to get geometry into WebGL except as JavaScript arrays. This is an area that needs some attention. I believe WebGL is hoping for extensions to HTLM5 to provide more generic solutions (so they don't have to put networking code in WebGL). That's a great goal and O3D would like that as well if it comes about but it seems like getting HTML5 to add features for downloading generic data and then getting browser vendors to support that feature will take a while.

BTW, the WebGL team at Google and the O3D team are currently the same team. We have every interest in seeing both WebGL and O3D succeed.
 

[Henry Bridge]

To echo Gregg's central point: we're actively working on both WebGL and O3D in parallel.  We think it makes sense to standardize GL for JS since it's a well-known API and it's relatively easy for browser vendors to implement, but there are gaps in performance and capabilities of the two systems that make them suitable for different types of applications at the moment.

We do want to ensure that it's as easy as possible for developers to use both APIs, hopefully simultaneously, so we're definitely looking into how they can best coexist.  Let us know if you have ideas on what would be useful to you in this regard.

Henry
 

[m3xican]

@Gregg Thanks for the very exhaustive and detailed reply!

@Henry my idea, also according to all the performance problems pointed
by Gregg, is that WebGL should be something used to add GL effects/
shaders into websites, while O3D should be used for 3D apps running
into the browser. Of course this is just a guess now, and it will be
so until a WebGL implementation comes out.

Anyway, I'm looking forward to see how both will progress.

Cheers

[jd]

There is a LOT that can be done with shaders, all the javascript is
needed for is setup and loading. If OpenGL ES 2.0 could be extended
with a geometry shader concept, all the above arguments vanish. And
even then, there is still a lot that can be accomplished with just
vertex and pixel shaders.

From what I'm seeing so far, O3D is a kludge. I have higher hopes for
WebGL.

On Aug 6, 9:06 am, m3xican <vivala...@gmail.com> wrote:
> @Gregg Thanks for the very exhaustive and detailed reply!
>
> @Henry my idea, also according to all the performance problems pointed
> by Gregg, is that WebGL should be something used to add GL effects/
> shaders into websites, while O3D should be used for 3D apps running
> into the browser. Of course this is just a guess now, and it will be
> so until a WebGL implementation comes out.
>
> Anyway, I'm looking forward to see how both will progress.
>
> Cheers
>
> --
> Davide "M3xican" Coppola
>
> --------------------------------------------------------------------

> email:  vivala...@gmail.com

[Kumar]

> There is a LOT that can be done with shaders

Part of the problem is the shader language itself. For systems with no
OpenGL support, but with Direct3D support (say), you'll need some form
of shader language translation. Compatibility seems very hard to
achieve in the graphics world and therefore could take up a good chunk
of the project's dev time. OTOH, Adobe has done some of dirty work in
making its shader language runnable (using LLVM, I believe) even if no
GPU is available on the system. Apple's done that too, though limited
to the mac platform at the moment. My old PowerBook G4 which has a
graphics chip lacking hardware pixel shaders suddenly got shader
support in the gl driver after an OS update! Though it was done in
software, 640x480 at 15fps ran fine.

There is something to be said for making a raw binding of OpenGL to
JavaScript though - it will give enough incentive for even greater
improvements to Javascript compared to what Google, Apple, Adobe and
others have accomplished so far.

Another significant point in favour of WebGL is that there are plenty
of app categories that can benefit from hardware accelerated low
complexity 3D scene rendering. For one thing, Flash-like stuff will be
a breeze from the rendering stand point. The web is now chock full of
photos, videos and music. me.com's "gallery views" can be super slick
with hardware acceleration thrown in. There is much to gain from WebGL
even if it is insufficient initially for games. One argument not in
favour of WebGL is that a good part of such low complexity 3D apps
lies in resource management - when to load what into which texture,
when to release textures, managing system memory versus video memory,
etc. Textures tend to be large and polygons few. O3D seems be
slightly more oriented towards easy resource management.

Anyway, these are interesting times indeed! Now, ... to complete the
picture ... we need an audio engine don't we? How about SuperCollider?

[Ged Wed]

Pure openGL from JS is exactly right.

I have read the osd arguments, and how they have put the more complex CPU draining parts inside o3d, so that JavaScript can be used for the control layer only.

i am wondering if i put the complex scene management code for controlling the scene, objects and materials into Flash or Silverlight if this would be an effective way of speed it up.
The question boils down to how many calls across the binary to JavaScript  boundary are going to be make i guess ?

Ged

2009/9/19 Kumar <sriku...@gmail.com>

[craigg...@googlemail.com]

Sorry to barge in and resurrect a two-week-old thread, but I'm
currently researching WebGL for a magazine feature I'm writing (for 3D
World); if anyone's willing and able to talk WebGL, please get in
touch. I'm at craiggrannell AT googlemail.com

Thanks in advance for any help anyone might be able to provide.

Craig