There was one place, however, where 3D made business sense: gaming (well, native gaming). 3D enjoyed, and still enjoys, a happy existence on PC and Console platforms. The question I always wondered was when will 3D in the browser be of high enough performance and quality across all platforms and browsers to support a solid business case for 3D on the Web? I believe the time has finally come. The confluence of mobile gaming, mobile Web app development, and a solid javascript API called WebGL (a biding to the powerful and ubiquitous OpenGL), is fueling its arrival. I’m proud to say that BlackBerry has been very active in providing one of the first complete mobile WebGL implementations on the BlackBerry PlayBook, and has also brought this capability to BlackBerry 10.

WebGL provides developers with the ability to write immersive, high-performance, console-quality, 2D and 3D games accessible directly on your BlackBerry 10 smartphone. This could be done directly though the browser, or even better, directly by a BlackBerry HTML5/WebWorks application. By building and packaging your HTML5 application into a bar file (a BlackBerry app file container), it enjoys the same rights and privileges as a native application. These apps look, feel, and behave as native apps, as they don’t run inside a browser context. They don’t need to be online to work, and they can leverage great BlackBerry services like the Payment Services SDK and the BBM APIs. BlackBerry WebWorks apps can also be certified as Built for BlackBerry affording them additional advantages.

The game shown below is called “Pearl Boy” and is a great example of what a WebGL application can do. It was developed by Goo Technologies, makers of the Goo Engine for GDC this year. It’s a 100% Web application, written using HTML5, Javascript, and of course, WebGL. The graphics and performance on the BlackBerry Z10 look great. Reflections, environment maps, pixel shaders, they’re all there. WebGL is the real deal.

If you want to learn more about programming with WebGL on BlackBerry, check out these additional WebGL resources on the BlackBerry DevBlog. I also recommend you check out the O’Reilly book, “WebGL: Up and Running” by Toni Parisi.

Now with 4500% more unique peaks and valleys.

On November 2nd, PeaksAndValleys 2.0 was uploaded to Github with a number of improvements. In the first release, we relied on a static map that was 150 by 150 vertices (22,500 total vertices.) When we’re talking about a map, we’re just referring to a grid of vertices where each vertex has a specific height.

Bird’s eye view of a 33 by 33 vertex grid (map); each vertex has a specific height associated with it.

These 22,500 vertices were all generated during startup with randomized heights. It was a good initial implementation, but subject to a number of limitations:

• Maybe we want a fixed / persistent world to traverse.
• We can’t expand the map much more due to performance reasons.
• If the player runs in any direction for long enough, they will hit the edge of the map.

Let’s take a look at each of these individually.

Fixed / Persistent World

One of the more common approaches to this problem is the use of a static source of data; in our case, a height map. This is the approach opted for in PeaksAndValleys 2.0. The following is an example of what a height map might look like:

Sample height map (originally 1024 by 1024 pixels).

Each pixel represents one vertex (or point) of the map, and the RGB colour of that pixel is used to determine the height of each vertex. In the case of PeaksAndValleys, the lowest height occurs at pure black (RGB = 0×000000) and the highest height at pure white (0xFFFFFF).

Though the height map is only 1024 by 1024 pixels, we can apply a scaling factor to extend the map across larger distances in our WebGL world.

Depending on how smooth the source image is, we may get areas where there is a very low region next to a very high region. To prevent drastic changes in terrain, a smoothing algorithm was implemented that averages the height of each pixel with that of its neighbours.

And with this, we address the fixed / persistent world by using a static data source. We can quickly see how multiple height maps and randomized starting locations can expand the versatility of this approach.

Performance

As noted, the first release of PeaksAndValleys contained a static 150 by 150 vertex area and expanding to a larger number of vertices would have an impact on performance; so then what good is a 1024 by 1024 height map?

In our case, we’re actually only loading a 121 by 121 region at any given time. As the player traverses the terrain, we are continuously reloading the surrounding region data (with the player at the center.) This means that as the player moves around, terrain in their vicinity is continually loaded from the height map.

There is a lot of processing that needs to go on in order to keep loading terrain — so much that if we do this processing on the main application thread, we’ll see a drop to roughly 30 frames per second. This is where Web Workers come in, for which the implementation can be seen in GLTerrainWorker.js.

A Web Worker allows a separate thread to perform actions without interfering with our main application thread. Our main application thread is where all of our interactions and rendering are performed, so if we can minimize the work being done there, we can improve our frames per second and responsiveness.

Web Workers aren’t without their limitations. Specifically affecting us, we cannot:

• Access the DOM. This eliminates WebGL rendering directly on the Web Worker.
• Pass objects with functions between the main application thread and Web Worker.

These two limitations mean that while we can perform our processing on a Web Worker, we actually need to pass the processed data back to our main application thread in order to update our rendering objects. We do this via the onMessage listener and postMessage initiator to initialize our Web Worker with the data it will need, and then pass subsets of that data at various intervals. You can see this initialization and rendering update performed in GLTerrain.js.

By offloading this processing to a Web Worker, we can continuously load more data off the main application thread, and only pass back the final data results to be assigned to our renderers. The end result is increasing our frames per second from roughly 30 to 50-60 frames per second; a huge win. To learn more about Web Workers, the following HTML5 Rocks tutorial is a great starting point.

Seamless Terrain

The final issue we had with our 150 by 150 static area was that when you run to the edge of the map, you hit the border. Loading data from a larger 1024 by 1024 area certainly extends the time before the player hits the border, but inevitably they will if they keep moving in one direction.

To counter this, the application continuously loads an area of pixels surrounding the player. As you reach any of the edges, data from the opposite side of the map will we used to populate that area. This produces a continuous terrain, even when travelling near the edges of the map.

Red cross represents the location of the player, white area represents the data we’ve loaded.

By wrapping the data that we load as we get close to the edges, we can in essence allow the player to run forever. You may notice that this image isn’t intended to be seamless (i.e. when wrapping around, the colours at the borders do not match up or flow together). This can be overcome by using a height map that is already seamless (i.e. it has already been processed to ensure that the pixels on the north side match those on the south, and those on the east match those on the west). In the case of PeaksAndValleys, our smoothing algorithm was implemented to wrap around the image when necessary (i.e. at the edges), thus turning non-seamless images into height map data that is seamless.

Preprocessing Data

To obtain usable height map data, we must:

• Read a source image; in our case 1024 by 1024 pixels.
• Perform height calculations.
• Calculate the normal (perpendicular vector) of each point.
• Calculate texture coordinates.

This involved quite a bit of math and processing power. Mathematical calculations are an area where JavaScript performance has historically suffered. Attempting to perform these actions while the application loads leads to a PC load time around 5 seconds and a mobile device load time around 20-25 seconds.

This also means that we are re-calculating data on every load just to get the same result as our previous run — a very inefficient approach.

To address this, a Node.js preprocessor tool was created that reads in an image, along with some parameters, and generates a json file with the resulting vertex, normal, and texture data required by our WebGL application. On a 1024 x 1024 image, the resulting file is roughly 50mb in size. Originally, this file was closer to 120mb, however by truncating decimal points to 5 significant digits the overall size was reduced.

As a result our application doesn’t actually process any data on load. Instead of feeding in an image, we are now feeding in the output json file with all calculations already in place. That being said, we are still loading a 50mb file which does take some time, but now we’ve managed to cut the loading time closer to 5 seconds on a mobile device.

Using preprocessed data also minimizes the amount of work the Web Worker has to do, as it will simply retrieve the appropriate data based on the user’s location and pass that data back to the main application thread.

Summary

Ultimately, PeaksAndValleys has seen a large number of improvements in the terrain implementation. From preprocessing / generating seamless height maps to leveraging Web Workers and minimizing strain on the main application thread, we now have a much more versatile world.

There are still some issues such as terrain popping into view as you move about. There is also room for optimization by only loading a cone of data in the player’s field of view (as opposed to a square in all directions around the player). These are topics that will be addressed in the next release.

For more information on this project, be sure to check out the Github release. Feel free to leave questions there, or reach out to me directly on Twitter® via @WaterlooErik.

The gap between the desktop and mobile web is rapidly shrinking as performance and functionality are on a path towards convergence. An area that has been (and will continue to be) heavily impacted by these advancements is the gaming space. I am pleased to be presenting an upcoming webcast on the current state of HTML5 Gaming on BlackBerry® 10 and what the future holds for mobile web game developers.

During the webcast, the primary focus will be on Canvas2D and WebGL, with a deeper look at PeaksAndValleys; an open source WebGL sample created to demonstrate common HTML5 game components. We will also discuss topics such as audio, social integration, and monetization to name a few.

Unlike previous webcasts we will be presenting from the Communitech Hub located in Kitchener, Ontario while live streaming the content to the internet. This means that if you’re in the area, you’re more than welcome to drop in and ask what questions you have face to face!

To join as an online attendee, you can register at the following URL:

http://www.blackberrydeveloperevents.com/events/webcast/attend/1074214004

If you will be attending in person at the Communitech Hub, we ask that you please register here instead:

http://www.eventbrite.ca/event/4782690155

The presentation itself will be held on November 15, 2012 starting at 11:00AM EST and will run for approximately 45 minutes with additional time allocated for question and answer. During that time, we will be taking questions from attendees both in the room and online.

The BlackBerry® PlayBook™ tablet was one of the first mobile devices to introduce full WebGL™ support with the BlackBerry PlayBook OS 2.0 release. However some users on the BlackBerry PlayBook OS 2.1 beta release may have noticed something similar to the following when visiting a website that required WebGL.

Even though the content does actually render, not all WebGL samples present the same behavior. The underlying issues stems from the implementation of the WebGLRenderingContext object. In BlackBerry PlayBook OS 2.0, this object was implemented and exposed, allowing developers and users alike to enjoy the benefits of a platform that supports 3D graphics.

In the subsequent updates to the beta BlackBerry PlayBook OS 2.1, an update to the underlying WebKit engine left the WebGLRenderingContext object implemented, but not publicly exposed. For samples and applications that look to this object as an indicator of whether WebGL is supported on a platform, it appeared as if we did not support WebGL.

I’m happy to announce that in the BlackBerry PlayBook OS 2.1 release, the WebGLRenderingContext object will be exposed once again! Big thanks to the browser teams for making sure that this fix was included in both the coming BlackBerry PlayBook OS update and current BlackBerry® 10 releases.

If you’re working on any WebGL applications, drop us a line and tell us about it!

At FITC Toronto this year, Dustin Malik and I presented a session for developers interested in WebGL — where it is today and where WebGL is headed. I made a promise to open source my WebGL sample (previously known as Webscape) and I’m happy to say that it’s available today!

Two months prior to FITC, I had very little personal experience with WebGL development. I spent two weeks researching WebGL technologies and frameworks with the ultimate goal being to pack as many topics that a typical WebGL game dev might come across into one sample.

Over the next week, I tried various WebGL frameworks. I managed to make quite a bit of progress using Three.js before I hit my first issue and realized that without knowing how WebGL works under the hood, I’d have a difficult time resolving my own issues. Imagine trying to debug a public framework like jQuery without having knowledge of JavaScript®.

So I started over, this time using pure WebGL as my approach and www.learningwebgl.com as my primary resource of information. The next three weeks saw the majority of my coding. I wanted to take the project as far as I could before the FITC conference.

In that time, I managed to implement forms of terrain generation and pathing, ambient and directional lighting, a skybox, virtual controls, and texture blending. It was an adventure, to say the least. I left a week for debugging and touch-ups, and then it was conference time.

Primarily, this sample is intended to be a learning resource. As such, it has been open sourced at our WebGL-Samples Github repository. Feel free to take it, rip it apart, and build up something grander. This sample is not perfect, but it does take a lot of concepts and brings them into one place. Feedback, questions, and contributions are all welcome. If you have your own projects you’re working on, I’d be ecstatic to see them!

Finally, I wanted to say thank you to the following people whose contributions to the online community helped me greatly along my way: Learning WebGL, Brandon Jones, Jerome Etienne, Chandler Prall, Andrea Giammarch, Paul Irish and Erik Möller, Ricardo Cabello, and the Valve Developer Community.

Last month, Adam Stanley discussed the giant leap forward that our WebGL support has brought to web development for the BlackBerry® PlayBook™ tablet, Adam wrote:

“…you could build a standalone BlackBerry application, powered by WebGL, using theBlackBerry WebWorks SDK, and distribute that app to other BlackBerry PlayBook tablet users through the BlackBerry App World™ storefront.”

To get a true understanding of what you can do with WebGL, we’ve made our demo game “TunnelTilt” available for download in BlackBerry App World™ – check it out. This is really the power of our Web tools. This game feels native.

We took the TunnelTilt demo, which we had previously open sourced in the WebGL-Samples repository on our GitHub page, packaged it with our WebWorks SDK, signed the BAR file and submitted to BlackBerry App World – just like any other game. TunnelTilt is implemented completely using WebGL (specification, Wikipedia) and it is indistinguishable from any other BlackBerry PlayBook tablet application in how it performs!

Download TunnelTilt today and see if you can get through all five levels!

This game is also a great example of RIM’s continued commitment to the open source community. The source code, runtime, and tooling are all available on our developer site and Github page.

Additional Readings

• Native WebGL: A giant leap for the web development community on the BlackBerry PlayBook – Detailed overview of WebGL and its support on the BlackBerry PlayBook.
• TunnelTilt – From GitHub to Your PlayBook – Step-by-step on how to compile the sources into an app.

Let us know what you think of our WebGL support and make sure to let us know as your Web apps launch.

BlackBerry® developers, you’re in for a treat. If you haven’t heard already, the BlackBerry web platform for BlackBerry® PlayBook™ tablet OS 2.0 supports WebGL. WebGL is an exciting new technology that is designed to offer advanced rendering capabilities and 3D Graphics for web development. Support for this feature was announced during the BlackBerry DevCon Americas 2011 keynote, and developers can use it as part of their HTML5 and BlackBerry® WebWorks™ web applications.

That’s right – if you wanted to, you could build a standalone BlackBerry application, powered by WebGL, using the BlackBerry WebWorks SDK, and distribute that app to other BlackBerry® PlayBook™ tablet users through the BlackBerry App World™ storefront.

This is a giant step forward for the web development community. As one of the first mobile development platforms to offer a native implementation of WebGL to its developers, BlackBerry provides the web development community a unique opportunity to push the boundaries of what they can do in their application content. WOW!

This is amazing! Wait a sec, what’s WebGL?

WebGL is a cross-platform web standard that is designed to define a specification for enabling 3D graphics, powered by OpenGL ES 2.0. Using WebGL, you can create amazing graphics and subsequently more fun user experiences.

Here is a demo of a game named TunnelTilt running on BlackBerry PlayBook tablet OS 2.0. This sample app was created for the purpose of announcing WebGL at BlackBerry DevCon Americas 2011, and it has since been open sourced as the BlackBerry WebGL-Samples repo in Github:

[YouTube link for mobile viewing]

The 3D graphics are rendered in an HTML5 canvas element that is hardware accelerated. This content can even be interacted with using JavaScript™ and the document object model (DOM).

function webGLStart() {
var canvas = document.getElementById("lesson01-canvas");
initGL(canvas);
initShaders();
initBuffers();

gl.clearColor(0.0, 0.0, 0.0, 1.0);
gl.enable(gl.DEPTH_TEST);

drawScene();
}

Code sample: Learning WebGL Lesson 1 (http://learningwebgl.com/blog/?p=28)

Libraries and Frameworks

The WebGL code that provides highly visual graphics can be very complex, and may present a steep learning curve for new developers who are not familiar with the necessary principles. Building compelling WebGL content may require a deep understanding of trigonometry, geometry and Open GL features.

For example, after reading the following tutorial about how to draw a triangle and square using WebGL, ask yourself if you were expecting to see so many lines of code. There may not be the higher level “draw” or “square” primitives and methods that a developer may find helpful in building real-world applications. WebGL offers lower-level primitives to its developers for building content. Why? It’s because WebGL is a language, not an application framework.

Don’t worry if that’s not what you were hoping to hear! Keep reading.

var square = gl.createBuffer();
var square_vertices = [
1.0, 1.0, 0.0,
-1.0, 1.0, 0.0,
1.0, -1.0, 0.0,
-1.0, -1.0, 0.0
];
gl.bindBuffer(gl.ARRAY_BUFFER, square);
gl.bufferData(gl.ARRAY_BUFFER, new Float32Array(square_vertices), gl.STATIC_DRAW);
square.itemSize = 3;
square.numItems = 4;


Code sample: creating a square using basic WebGL constructs.

Many, and I mean many, developers have recognized the need to simplify WebGL development, and have spent a lot of time and energy building great libraries and frameworks for other developers to use. These libraries translate the low-level functionality of WebGL into higher-level APIs that are easier to use in the context of application development.

Another benefit to developers is that all of this is done using JavaScript APIs. So if you are already familiar with the JavaScript language, you are off to a great start. You can continue to use all of the existing JavaScript development tools that you currently use (e.g. Web Inspector, IDEs, Jslint, etc).

A few examples of community-led projects that web developers can use to build great WebGL content include three.js, CopperLicht, SceneJS, GLGE and Canvas 3d library. There are many more, and the list will continue to grow. These libraries have traditionally focused on desktop browsers, which means authors will need to ensure they have successfully been optimized for mobile too. If you end up using a 3rd party library and find a bug, or if you are concerned about performance, please contact the appropriate author(s) and file an issue with them. Many of these frameworks exist as open source, meaning there is a great opportunity for improvement. As a community, we can work together to ensure these libraries work great on BlackBerry.

var rect = new THREE.Rectangle();
rect.set(0, 0, 100, 100);

Code sample: using three.js library to create a square. Only 2 lines of code!

Performance

So obviously there is a mobile version of the WebGL spec, right? Developers can expect to work with a specification that’s optimized for mobile devices and doesn’t have high memory or CPU requirements as desktop computers?

No, actually, there isn’t! OpenGL ES 2.0 does not have a mobile spec. So the same libraries that are used to produce WebGL content for powerful desktop hardware are also the same libraries used to build content for mobile devices.

What does this mean? It means that WebGL code that was designed for desktop browsers will need to be properly optimized to run on mobile smartphones and tablets. If not, you can expect to experience slow rendering or performance. This is very important for developers to recognize: one cannot assume that if it works on desktop, it will also work on mobile.

Community Activity

Many of you have already seen our web platform team members participating in HTML5 and WebGL developer events worldwide. Recently we had delegates attend and present at events such as onGameStart and New Game Conference. Here are some highlights from these events:

“WebGL is huge!!! And the fact that we will be the first tablet to have it built-in is extra-huge. We need to engage aggressively here to showcase our wares … interest in tablets is high.”

- Laurent Hasson, Director Web Platform, Research In Motion® (RIM®) (onGameStart, Warsaw, Poland)

“Good News! We are actually well positioned in terms of technology … There’s no reason we can’t have the best mobile web platform for gaming and game development.”

- Genevieve Mak, Software Developer, RIM (New Game Conference, San Francisco, USA)

This is awesome. I love WebGL. What should I do now?

The following steps can help you learn how to build a WebGL-powered BlackBerry application:

1. The BlackBerry open source project on Github contains a WebGL-Samples repo where developers can download and/or contribute to code examples. In fact, the source code for the TunnelTilt sample app shown above is available in this repo! Download it today and see how JavaScript, HTML5 and WebGL are being used together to provide an awesome user experience.

2. Log into the DevCon on Demand portal and read through the DEV46 session “Advanced Web Rendering: WebGL, Canvas and Gaming” session that was delivered at BlackBerry DevCon Americas 2011. Don’t miss this session, where Eli Fiddler and Ram Rajagopalan from RIM presented a great overview and best practices about using WebGL as well as some helpful code snippets and examples.

3. Take advantage of the many helpful learning resources you can find online, such as learningwebgl.com by Giles Thomas, which contains many tutorials and sample code. Remember: WebGL is a standard that the BlackBerry web platform supports. This means that most – if not all – tutorials, sample code or labs that you will find can be used to assist you in building WebGL content for BlackBerry. Check out the Mozilla Developer network for a robust collection of WebGL learning resources.

4. Discover how you can use Ripple Mobile Emulator to test WebGL content, and the BlackBerry WebWorks SDK to transform that content into a standalone BlackBerry application.

Did you find a bug? Report bugs in the developer issue tracker. Our goal is to provide developers with a world class WebGL experience on the BlackBerry platform, and we want to hear from you to ensure we are doing so.

Finally, I wanted to extend an invite to you to stay in touch with us. We want to know when you have created a WebGL application, framework and/or game content that runs great on the BlackBerry PlayBook tablet. Send us a message or ask a question in the comments below, or else share a great idea in the forums.

The latest version of the Ripple Emulator v0.9.1 beta for Microsoft® Windows and Mac is now available for download. This beta refresh is designed to add more BlackBerry® WebWorks™ API support, debugging support, bug fixes and a designated area where you can place your application files to use with the Ripple Emulator without configuring your own local web server.

The full list of improvements:

• Support for JavaScript® breakpoints in Web Inspector
• Added SSL support for Microsoft Windows®
• WebWorks File I/O API support
• HTML5 Audio/Video support on Microsoft Windows
• Local solution for emulating your app without configuring your own local web server
• Ability to work offline after an initial connection to the Internet

Did you know that the Ripple Emulator v0.9.1 beta and BlackBerry® PlayBook™ OS 2.0 beta support WebGL in BlackBerry WebWorks?

That’s right! The latest BlackBerry PlayBook tablet OS 2.0 beta developer release has support for WebGL when used inside of an HTML5 application packaged with BlackBerry WebWorks. When packaged with BlackBerry WebWorks, it is the same as any OpenGL based application on the platform.

On top of that, WebGL is also enabled in the Ripple Emulator so that you can test out your application with the desired screen size and incorporate touch events in order to get your application just right. We have even made the source code available for the Tunnel Tilt WebGL demo seen at BlackBerry® DevCon Americas.

How does the Local Solution work?

This latest Ripple Emulator refresh is designed to provide a way to allow developers to emulate and test their applications residing on their development machine. Leveraging node.js which is run as part of Ripple’s build and deploy features, we effectively configure and run a local web server that can be accessed from the Ripple Emulator.

In order to test your local application, ensure that your application is stored on your file system at the locations listed below, and access your application by entering http://localhost:9900//index.html into the URL bar of the tool.

On Microsoft® Windows XP machines: Documents and Settings\<Username>\RippleSites
On Microsoft® Windows 7 machines: Users\<Username>\RippleSites
On Mac OS X machines: /Users/<Username>/RippleSites

Playing HTML5 audio/video content in Ripple Emulator v0.9.1 beta

Ripple Emulator v0.9.1 beta is designed to allow you to play HTML5 audio/video content so that you can ensure your media content is integrated correctly. While the tags are supported in the Ripple Emulator, they rely on the system having appropriate codecs installed for the media content type you are trying to use. The Ripple Emulator does not bundle any media codecs, so in the event that your content is not played in the Ripple Emulator, please download the appropriate codecs.

What will happen to the Google® Chrome™ plug-in?

The existing Google Chrome plug-in will remain available for download up until February 29th, 2012, when it will be removed from the extension store. The stand-alone Ripple Emulator architecture is evolving daily to allow us to provide a more extensive emulation framework with the ability to tailor the rendering and simulation to each platform Ripple supports.

Our goal is to minimize the time our community needs to spend testing on simulators or devices by providing a best in class desktop browser-like emulation environment that comes as close as possible to runtime behavior. We encourage all our developers to make the transition to the current Ripple Emulator tool found on our site at http://developer.blackberry.com/html5/download/ripple.