|
GettingStarted
The WebGL implementation of O3D is a JavaScript library built on WebGL. It implements a subset of the original O3D plug-in API and calls the WebGL library directly from the Google Chrome browser.
IntroductionThe WebGL implementation of O3D is a JavaScript library built on top of WebGL. It implements a subset of the original O3D plug-in API, which includes all O3D interfaces that have an analogous interface in WebGL. For example, the render graph, transform graph, and texture classes are all implemented in the WebGL implementation of O3D. Animation, parameter operations, 2D canvas, and file I/O classes are not included. See Functional Groupings of O3D for details. One major difference between the two implementations is that the WebGL implementation of O3D uses the GLSL shader required by WebGL. This release includes a Cg-to-GLSL converter script to aid in this conversion. SamplesA number of the samples for the plug-in implementation of O3D require only minimal revision to work with the WebGL implementation of O3D. Here are some of the samples that have already been converted to use the WebGL implementation of O3D:
The samples for the WebGL implementation of O3D are in the `o3d-webgl-samples/` directory of the Samples.zip file. The Sample Application page discusses a fully developed game that uses this new library. In particular, this code example illustrates attractive procedurally generated graphics, realistic 3D physics effects, and shading effects using the GLSL shader. Modifying an O3D plug-in appThe steps for modifying an application originally written for the plug-in implementation of O3D are summarized below:
<script type="text/javascript" src="../o3d-webgl/base.js"></script> o3djs.base.o3d = o3d; o3djs.webgl.makeClients(initStep2); <div id="o3d" width="600" height="600"></div> Functional groupings of O3DThe following list groups O3D classes according to their typical use. Parentheses indicate classes that will not be included in the WebGL implementation of O3D.
Class hierarchyThe following class tree diagrams use regular black type for classes included in the WebGL implementation of O3D. Gray type indicates classes not included in this implementation. Top-level O3D classesThe first section of the O3D class tree shows the top-level classes in the O3D class hierarchy:  Classes derived from ParamObjectThis section shows the O3D classes derived from the ParamObjectclass:  Classes derived from ParamThis section shows the O3D classes derived from the Param class:  |
► Sign in to add a comment
Some of the samples under the o3d WebGL Samples trunk are actually o3d plugin examples (not o3d WebGL samples) eg. http://code.google.com/p/o3d/source/browse/trunk/samples_webgl/canvas-fonts.html?r=216
Any guidance on what to do with features that were in the o3d plugin, but aren't in the new framework? Eg. What is recommended alternative to Canvas and CanvasPaint? object? Is there any replacement for the canvas.drawText function?
Hmmm. Perhaps like this: g_canvas2d = document.createElement('canvas'); g_canvas2d.width = 256; g_canvas2d.height = 256; g_ctx2d = g_canvas2d.getContext("2d"); g_ctx2d.fillText("Hello", 10, 10); See: http://webglsamples.googlecode.com/
.... Just a suggestion, but IMHO it would make sense to use a mixed strategy of o3d plugin AND webgl. In this way if the user can be bothered to install the plugin they can benefit from better performance up until such time as the browsers are fully supporting webgl. And in any browser that doesn't not support webgl the user can be prompted to install the plugin. And any browser that does support webgl, the page can run in the browser without the plugin initially but for next 12 months or so offer the user a choice to go either with the plugin or run direct in the browser...
Good idea?
(I mean then we could use pretty much the same project code to target either o3d plugin OR o3d javascript library... which would be a really good reason for using the o3d javascript library in the first place, rather than just going for regular WebGL)
Hi everyone,
I have a question for those, who are developing O3D: Would it not be better to build a homepage for O3D? Something similar to
http://jmonkeyengine.org/
With a forum and dokumentation section. I think a forum would be really useful.
This is silly, they deprecate O3d to port it into WebGL which at some point prolly will be ported back into a separate 03d project.
at this junction why run 3d graphics in the browser at all, and just not run the graphics in a cloud and stream the output into the client using H.264 encoding???? This is what services like OnLive? do.
Hi,
I was just profiling the javascript api's in o3d application samples, but found that the data given by web inspector (google chrome's tool) is incorrect.
As the performance was taken for 30 sec's but the tool was showing more than 30 sec's for many of the Js fundtion's in app. Any idea? Is it a problem with tool or o3d app's itself ?
You can attach a dom canvas to a texture in o3d with this code:
var canvas2d = creatDomCanvas(); var texture = g_pack.createTexture2D(32, 32, g_o3d.Texture.XRGB8, 1, false); texture .setFromCanvas(canvas2d, true, true);
var sampler = g_pack.createObject('Sampler'); sampler.texture = texture; sampler.minFilter = g_o3d.Sampler.ANISOTROPIC; sampler.maxAnisotropy = 4;
rawsonk, the whole point of it is that you can access the GPU without needing to download any plugins. OnLive? needs a plugin, just like o3d used to. It puts people off using the website.