Monday, April 27th, 2009

Google and Mozilla 3D Round-up

Category: 3D, Canvas, SVG

<p>About a month ago, we covered an announcement about Mozilla’s plans to basically put OpenGL ES in the browser and call it Canvas 3D and to do so working with a new working group over at the OpenGL standards body, Khronos.

This week, we covered Google’s own 3D announcement, a plug-in offering a high-level scene graph API and embedded V8 run-time.

And of course, don’t forget about Opera’s 3D work, which we covered back in November 2007.

So now there are three approaches to 3D:

  • Mozilla: Low-level, OpenGL wrapper
  • Opera: Mid-level proprietary scene-graph-ish API
  • Google: The full COLLADA monty

Where should the web go? Mozilla’s Chris Blizzard compares the debate to Canvas vs. SVG:

Canvas is a very simple API, much like what we’ve proposed to Khronos for 3D support. It’s well-scoped, well understood and integrates very well with other web technologies. And it’s been getting a huge amount of traction on the web. People are writing all kinds of really neat technology on top of it, including useful re-usable libraries for visualization. Have a look through Google’s own promotional site for Chrome – a huge number of them use canvas. It has traction. And we’ve gone through a couple of iterations – we’ve added support for text and a couple of other odds and ends once we understood what people were trying to do with it.

Now compare this to SVG and SMIL. Each of those specs are multi-hundred page documents with very large APIs and descriptions of how to translate their retained-mode graphics into something that’s usable on the web. (SVG 1.1 is a 719 page PDF. SVG 1.2 Tiny is 449 pages. The spec for SMIL is a 2.7MB HTML file.) We’ve seen some implementation of SVG and SMIL in browsers, but it’s been slow in coming and hasn’t seen full interoperability testing nor any real pick up on the web. The model for these specs was wrong, and I think it shows.

Chris doesn’t directly say that Google’s approach is “wrong”, but he wonders if the Google proposal of a bigger and more ambitious API would represent too great a compatibility burden for browser vendors and developers.

In the comments of his post, Henry Bridge of the Google O3D team replied; here’s a lightly edited excerpt:

We agree that to keep a standards process focused, APIs should be as minimal as possible while remaining useful, and so we would likely keep things like that out of any first attempt at a standard and, as you say, let it evolve over time. But the usefulness question brings up an important, and we think, unresolved point. We’d love to build the animation and skinning system in JS, but we just couldn’t get a JS-based animation system fast enough — even on our retained-mode API. Javascript is getting faster all the time and we love that, but until someone builds some apps it’ll be hard to know what’s fast enough.

Standardizing [an Open GL-like] immediate mode API for JS makes total sense. It’s a well defined problem, lots of people know GL, and we think it will be useful. But some of the demos we wrote _already_ don’t run well without a modern JS implementation, and moving to [Open GL] won’t help that (but we’d love to be proven wrong). That’s why we think it makes sense to explore both an immediate and a retained mode 3D, and make sure they work well together.

What do you think?

Related Content:

  • Product roundup headquarters
    Staying up to date on new products for your SMB can be difficult and time-consuming. We've consolidated our collection of recent product announcements...

Posted by Ben Galbraith at 7:00 am
14 Comments

+++--
3.7 rating from 34 votes

14 Comments »

Comments feed TrackBack URI

I honestly think that this is a great way for the open web to work. Competing standards, competing ideas. Let’s get some implementations out there for people to try, and not just one. Just make sure that they are all clearly labeled experimental so that nobody feels so tied to a single implementation that they can’t budge on it. Thats really the key to success, I think. Do some experimenting, but keep the experimentation time short so it doesn’t grow legs, and then get together and standardize on something. We need interop, but we also need to make sure that whatever gets made, people will want to use.

Comment by genericallyloud — April 27, 2009

Which approach is IE taking?

Comment by Nosredna — April 27, 2009

So, three different ways of doing things in 3 different browser and none of them being implemented in the world’s most popular browser.

Way to go, guys!

Comment by TVIdesign — April 27, 2009

Actually, Googles O3D-plugin works with Firefox, Safari, Google Chrome, and Internet Explorer.

Comment by iceydee — April 27, 2009

I really wish they had all taken more of a Mozilla approach. 3D is such a difficult topic – why not author the api to take advantage of a lot of the existing literature and tutorials? Going the Opengl route would at least help existing Opengl programmers make the transition to the web if they wanted to.

Comment by ilazarte — April 27, 2009

>> Which approach is IE taking?
The “let them do it so we can send a lot of cakes” one …

Comment by WebReflection — April 27, 2009

The SVG spec is a little bloated but seriously, at one point Canvas couldn’t even display text. The length and complexity of the SVG spec is irrelevant anyway, because browser implementors implement whatever subset of it they feel is important or gets the most bang for the buck. How is that different from Canvas? They started with the smallest, most important parts, and add functionality as they go along. Is Chris Blizzard really complaining that he’s got a blueprint to work with for SVG that defines exactly what to build? Or that SVG is a mature spec with several proven reference implementations? Once Canvas is as feature-complete as SVG does anyone really think it will be better given its ad-hoc development model? Also SVG fits better with (X)HTML because of its declarative style. Canvas fits for things that need to programmatically generate graphics, but whether its a better fit than SVG for that task is up for debate.

Comment by JonathanLeech — April 27, 2009

I tried the Google plug in on a couple of computers and it was miserably slow. Even on computers that can play 3D games reasonably well. Why would that be? Support for particular 3D cards? I admit I didn’t look into the reasons. Just made me think…OK, it’ll be awhile before I do this.

Comment by Nosredna — April 27, 2009

The more models the better. That’s what the standardization process is about. Try some stuff, and then pick the one most agree is best (or heck, standardize them all three!), and standardize it for implementation by others (except stubborn MS – but their users are used to installing random binary blobs from anywhere they happen to be, so we’ll just give them a plugin or 3). It all sounds good to me. I welcome all three approaches.

Comment by CaptainN — April 27, 2009

Who wants 3D anyway? The best games ever were all 2D :) Tron, Vanguard, Karate Champ, Barbarian II, Impossible Mission… none of them needed no stinkin’ 3D! Ok, yes, there’s Rescue On Fractalus, I’ll concede that one, but still :)

Comment by fzammetti — April 27, 2009

Aside of 3D discussion: How on Earth you could compare Canvas and SVG? It is like comparing HTML and JavaScript. These are different tools for different tasks. The only similarity: they bring dynamic graphics to the web. If you will write *proper* spec for canvas it will be even bigger than SVG one. SVG is just older and more mature, that’s all.
“nor any real pick up on the web” Are you kidding? What web you are browsing? May be it is just an excuse for bad SVG support in Firefox?

Comment by DmitryBaranovskiy — April 27, 2009

IE has already took the VRML approach in 1995! Afer that there was X3D, which is an ISO standard. Why to develop another web 3D standard?

Comment by Rugby — April 28, 2009

ilazarte:

The constraints of the web are different. The amount of code you send down the wire is a primary constraint, and what you do to make C++ fast isn’t what you do to make JavaScript fast. In a different environment, it’s appropriate to make different trade-offs to get to a (hopefully) better level of developer productivity and encourage a broader group of people to build content than existing OpenGL hackers. Bringing them along is indeed important, hence O3D has a shader compiler system and a lot more control in graph traversal than most scene-graph style APIs. As Henry said, it’s clear that there’s room for both styles of API, but assessing the constraints of the environment and apps that will live in it can lead to different opinions about which approach will get the most exercise. O3D providing higher-order primitives just gives us a way to experiment with that set of trade-offs before making developers pay a lot for them in terms of code and speed. If they pan out, they deserve to be standardized.

Regards

Comment by slightlyoff — April 28, 2009

O3D really rocks, yes.

I sure don’t mind using that plugin in other browsers, and I do trust the people at Google, but I’m waiting for some bug reports to pile up to see just how well this thing goes

Comment by hdragomir — April 30, 2009

Leave a comment

You must be logged in to post a comment.