[ See Vlad's post on this topic, Arun's post in the Mozilla standards blog and the official Mozilla blog post. ]
Today Mozilla and the Khronos group announced that Mozilla will be leading an initiative to bring accelerated 3D to the web. This is a pretty big deal for us and for the web, and is really a reflection of the continued acceleration of open web technology well beyond just the classic HTML and JavaScript that we’ve seen in the past. It’s our intention to include this as base functionality in the release after Firefox 3.5, assuming all goes well on the standards front.
We’ve started to see more and more libraries being built to support use cases with Canvas in a 2D context but we really want to take things to the next level and start to allow people to use 3D capabilities as well. Accelerated 3D graphics with the super-fast next-generation JavaScript engines from nearly every web browser vendor means that we’re going to be able to start to see more and more advanced applications written using open web technologies. 3D is a huge part of that story and we’re happy to bring our proposal to the table.
The proposed spec (found in one of vlad’s post on 3D Canvas) is a pretty light wrapper on top of OpenGL ES 2.0, with some changes to support some JavaScript pleasantries. OpenGL ES is a decent starting point, which is why we picked it. OpenGL is supported as part of every major operating system and in it’s being picked up as a standard on mobile devices as well. Compared to the full OpenGL spec, the ES variant is a smaller subset that reflects the reality of what’s being used on the ground and most hardware and software vendors have actually been re-tooling to support OpenGL ES with support for older versions of full OpenGL emulated on top of OpenGL ES. Mixed with the fact that there’s a decent amount of knowledge out there in the industry of how to use OpenGL, we think that this smooths the integration between the current set of OpenGL users and larger web developer community.
Expect to see some releases of the code to start with in the form of the Canvas3D extension. Vlad has made releases of it in the past and we’ll be able to have something that works as an extension as part of Firefox 3.5 for people to start experimenting with.
No offense… but like I said to Dion… there are a lot of developers and gamers who like to design and think about 3D but (and I really hate to be the downer here)
…until 3D is a full fledged holodeck… it’s a gimmick.
The holodeck is awesome and why so many want 3D to be a big deal but…
It’s like doing Jurassic Park 20 years to early using cartoon drawings inserted over film.
I know I sound like joe business here…and I guess it is good for gamers who are trying to tell immersive stories and the like… and for what is coming in the future…but there are so many more important directions Mozilla should be focused on heavily I hope this is not a priority… otherwise I know a good smell-o-vision theater to sell you too.
sorry but this 3d hype makes me laugh. it effects a very very small population on an important level but I guess it is an investment in the 22nd century.
Alright, alright, if you want me to submit an entry, I’ll make the skin if you find someone to do the back end coding.
Taylor
Anybody remembers VRML? 13 Years ago 3D was all hot on the Internet. And now you are trying to sell this as something new?
Why all the negativity? A few things about the Canvas 3D context (yes, I’ve worked with it before):
This is not VRML. VRML was a start-to-finish solution for displaying objects on the web (one that was provided only through plugins and not natively through the browser BTW). Canvas3D on the other hand is an API. A building block if you want. This is not really meant to be used by typical Javascript developers to display 3D models, but supposed to be a basis which can be used to accelerate many, many tasks that Javascript frameworks usually do. Keep in mind 3D acceleration doesn’t really mean that things actually happen in 3D. In case be used for fast drawing, filling and shading of any kind of data.
RTL text is not possible in 2D SVG/Canvas. Please make sure to fix it before taking it to 3D. Thanks.
Have you taken a look at Clutter?[1] It’s a scene-based 3D API, meant for creating advances user interfaces. It’s probably ill-suited for game development, but wouldn’t 3D user interfaces written in JavaScript be more suitable for web browsers?
1. http://www.clutter-project.org/
Pingback: Mozilla and the Kronos Group Announce Initiative to Bring Accelerated 3D to the Web :: The Mozilla Blog
@Tomer
I’m not sure how context switches between 2D and 3D will be handled, but I would imagine that you’d still use the 2D API for text. Either by obtaining a 2D context after the 3D drawing and just painting over the rendering, or by rendering the text to a 2D context, then using that as a texture. So this would still have to be fixed in 2D.
Yeah, there’s some text apis as part of canvas and I think that the 3D api lets you copy image data in and out of the 3D context.
Following the current spec, you’d have to transfer the canvas context to an image element first if you want to use it as a texture, but I’d say that this is a draft issue and will likely be brought in line with Canvas 2D Context drawImage function, which accepts image, video and canvas. But I think in most cases just switching to the 2D context and drawing the text after rendering will be sufficient anyway.
Pingback: Links 24/03/2009: Mozilla Promotes OpenGL, Oracle-Red Hat Rumours | Boycott Novell
@Tomer
RTL text seems to work for me, using fillText.
@Hans
You can load canvas elements directly as textures. You could load video elements too, but the video element can’t easily be used from an extension, so at the moment you need to route the video through a 2D canvas first.
And I think canvases can only have one drawing context active (at least in the current implementation), so you can’t get a 2D context for a canvas that already has a 3D context. Placing a transparent 2D canvas on top of the 3D canvas does work though. (But IMHO a plain ol’ div is better for that kind of text.)
@Ilmari
Thanks for the clarification. Just wondering… aside from the issues while this is an addon… would it be any trouble to have both contexts available? If I remember Vlad’s posts correctly, he said that everything was rendered to a special buffer anyway, so is there a reason why the 3D context wouldn’t be able to just push whatever it renders into the 2D context so that it could be used from there?
About the images (and specifically cross domain restrictions) Wouldn’t it be best to make this as similar as possible to how drawImage works and allowing VIDEO as direct source as well…. not necessarily while this is still an addon, but ultimately…
And finally: Is anybody building the source right now? It would be great to have a (even very unstable) version to play with until the official addon arrives.
Can someone explain advantages that Canvas3D API has vs FreeWRL or XJ3D API?
I tried to explain iti n my first post, but I’ll try again:
VRML (which seems to be what both these projects are about) defines a format for how 3D models are represented in an XML format. That’s all very well, if all you want to do is display a 3D model, but it’s not very flexible. If you want to do anything even a tiny bit different (say you want to move the camera along a fixed path), then you’re screwed. You can’t go beyond what VRML can do. Now imagine you don’t want to do things just a tiny bit different, but you have a whole different purpose in mind. You don’t want to display a scene, but instead want a video frame to be dynamically deformed based on input. Well, then you’re not just screwed anymore, you’re … (damn, where’s my dictionary of slang?) …
VRML was a nice idea for one specific purpose, displaying 3D models, but it’s no good for all the other great stuff you can do with a 3D accelerator.
Pingback: Freetracking.org » Mozilla, graphics group seek to build 3D Web
I guess this means we’ll finally be able to put teapots on our home pages.
Pingback: IRC: #boycottnovell @ FreeNode: March 24th, 2009 - Part 2 | Boycott Novell
Pingback: Dusan Writer’s Metaverse » 3D in a Browser: Mozilla and Open GL to Build Plug-In Free Virtual World Access
Pingback: Mozilla Standards Blog » Blog Archive » 3D on the Web
@Joshua: Yeah, the proposed API is much like the current Canvas 2D API – it’s a simple API for JavaScript to render using OpenGL. So you write a little program to render. The other specs are more like SVG – describe the model first and then manipulate it later with the DOM API.
@JamesH: _Spinning_ Teapots, even.
Pingback: Ajaxian » 3D APIs are coming to the Web in force
Pingback: 3D APIs are coming to the Web in force | Guilda Blog
It is clear that none of you are gamers. Accelerated 3D will bring epic win to my Javascript games.
Chris, could I get you to make another post about this? The problem is that at least the German media is publishing dozens of articles about how “we don’t need another standard for 3D content”, completely missing the point that Canvas3D is no standard for 3D content and doesn’t even contain one, but is instead a standard for programatically accessing the 3D accelerator in order to do, well … anything, 2D or 3D or maybe even just computation, not just displaying a 3D scene.
Hans, do you have pointers to some of those articles? I can get out PR people to look into this as well.
Sure, the biggest one ist heise.de (probably the most popular German IT magazine), which is probably also the main source for other similarly themed articles:
http://www.heise.de/newsticker/Noch-ein-Standard-fuer-3D-Inhalte-im-Web–/meldung/135201
Thanks, Hans, I’ll look into it.
Pingback: Se il Web diventasse 3D? Mozilla e Khronos Group vogliono farlo - The New Blog Times
Pingback: Google, Mozilla Back 3-D Acceleration Web Standard | VizWorld.com
They posted an update in the meantime
http://www.heise.de/newsticker/Noch-ein-Standard-fuer-3D-Inhalte-im-Web-Update–/meldung/135201
It’s still much too focused on file formats for my taste but apparently it’s the best we can get for now.
I’ve talked with the guy who wrote the article and he basically said that he was mostly using what the Press Release contained.
I sent it along to our press people to try and follow up as well. Thanks for the pointer, btw. Helps a ton.
You should come hang out with us on #devrel on irc.mozilla.org. :)
Pingback: Mozilla and Khronos Hook Up in 3D Graphics Initiative | google android os blog
This is all reinventing the wheel. And I am still searching for an answer to the question – why JavaScript? So much effort goes into making things available for JavaScript, doesn’t anybody realize this is akin to bending over backwards!
Just enable built in support in the browsers for advanced and better scripting languages – Ruby, Lua, Python. That will do away the need to innovate again and agian into JavaScript. As for 3D, writing alibrary to use 3D is much easier in Python that it is ever going to be in JavaScript – hence the point – reinventing the wheel. It is like, we are willingly throwing away all the advancements we made into the languages, and going back to a lame language and then rewriting stuff so that it can work in that lame language.
Popularity of Flash and now Silver light should be enough to open the eyes of these browser developers that there is a huge demand for empowering browsers with a better programming language – and in my opnion, the asnwer is to just make browserer scriptable with any scripting language.
Give web rpogrammers flexibility so that they can built better products and not have to struggle with the limitations and nuances of the only language browser can support.
@vlad
The standard for 3D on the web is X3D – an XML based format. X3D supports animation, interactivity, scripting, extensibility, and a whole lot more, so it does everything you want it to do. Also, it’s been standardized, the specification and schema are published freely online, it has an active working group, and it is in version 3.2 (at the time I’m writing this), so it’s been well vetted. X3D currently requires a browser plugin (or standalone player); however, I’m sure that they would love to get native browser support. Closed source browser plugin implementations exist (such as Bitmanagement’s BS Contact); however, open source implementations of X3D players also exist.
Let me know if you want more information (there is a bunch of online documentation and videos describing the spec).
No Need To Recreate The Wheel,
Joshua Burkholder
@vlad
Also, X3D players that conform to the X3D standard must support EcmaScript (aka JavaScript) … however, bindings for other languages exist.
For instance, Bitmanagement’s BS Contact player, Octaga’s Octaga player, Instant Reality’s InstantPlayer, and … conform to the X3D standard; therefore, they support EcmaScript-ing at a minimum … and some support more languages as well.
Hope This Clarifies,
Joshua Burkholder
Pingback: 3D APIs are coming to the Web in force
With the IE6 still in market, it’s hard to get 3d website deployed.
@Joshua: Based on your description of X3D, I don’t see Canvas3D being at all contrary to it.
First, keep in mind that Canvas3D (being a bridge between canvas+javascript & OpenGL ES) would be relatively simple to implement in comparison to a mark up format+DOM. (Compare the time it took to implement a usable canvas tag in Gecko with the time it took to achieve a remotely usable SVG implementation!)
Second, this effort would be a boon to X3D because someone (such as the Web3D consortium) could rapidly implement the X3D format in the browser with an x3d.js library file. X3D would take off *far* more quickly this way than trying to convince browser makers to spend a lot of resources on 3D markup formats with no proven demand for them.
Ultimately, SVG is to Canvas2D what X3D is to Canvas3D. Yes, Canvas2D is often chosen today over SVG when it shouldn’t be, but IMO that’s simply because it is stupidly difficult to include SVG in an HTML file, even when creating it through Javascript. It should be possible to just say or svgElement.newCircle(100,100,40), but it just isn’t.
So long as X3D is a good, simple format, an x3d.js that utilises Canvas3D will actually be a great way of making it popular.
(sigh) Escape HTML don’t clip it!
That sentence should read: It should be possible to just say [svg][circle r="40px"/][/svg] or svgElement.newCircle(100,100,40), but it just isn’t.
Pingback: Mozilla and Khronos to bring standards-based 3D to the web | WinSoftNews - Computers-Technology-Software
Pingback: Viene en camino una API 3D estándard para la web - FayerWayer
Pingback: Isseu, La Informatica Y Otras Cosas » Viene en camino una API 3D estándar para la web
Pingback: Mozilla, Google, And Khronos Collaborating On Standard For No-Plugin, 3D On The Web « Social Media.Online Games.Virtual Worlds
Pingback: Mozilla, graphics group seek to build 3D Web « Fearless Concepts
Pingback: Google lance O3D, un plug-in pour faire de la 3D dans le navigateur | FredCavazza.net
Pingback: Google lance O3D, un plug-in pour faire de la 3D dans le navigateur | MKT planet - News Web Marketing - Nouvelles Technologies
Pingback: Viene en camino una API 3D estándar para la web
Pingback: Ideal » Archive du blog » Google lance O3D, un plug-in pour faire de la 3D dans le navigateur
Ultimately, SVG is to Canvas2D what X3D is to Canvas3D. Yes, Canvas2D is often chosen today over SVG when it shouldn’t be, but IMO that’s simply because it is stupidly difficult to include SVG in an HTML file, even when creating it through Javascript. It should be possible to just say or svgElement.newCircle(100,100,40), but it just isn’t