INsanityDesign » opengl http://insanitydesign.com/wp The Imagination Enhancer Sat, 31 Dec 2011 22:14:05 +0000 en hourly 1 http://wordpress.org/?v=3.3.1 WebGL – Part 2: In the beginning there was… http://insanitydesign.com/wp/2011/02/27/webgl-part-2-in-the-beginning-there-was/ http://insanitydesign.com/wp/2011/02/27/webgl-part-2-in-the-beginning-there-was/#comments Sun, 27 Feb 2011 10:24:39 +0000 NeA http://insanitydesign.com/wp/?p=818 …a Triangle! In the previous part I presented WebGL, a new competitor in the graphics programming market. You got to know some history and parallel branches in the history of 3D graphics in the browser environment. Now, in this part you will see how to get a WebGL application into your browser.

The beginning

Last time was historical, this time we will get practical. In this part we will write one HTML page with embedded JavaScript code to draw a simple triangle through WebGL into an HTML5 Canvas. For that we will see how to set up a canvas, create a WebGL context, embed shaders and create a draw loop to present our triangle. Especially the shaders are an important topic regarding WebGL as WebGL is based on OpenGL ES 2.0 and OpenGL ES 2.0 does not support the fixed function transformation and fragment pipeline of OpenGL ES 1.x. Therefore, everything has to be done through shaders.

Note: What I present is an overview and user guide of WebGL, not OpenGL (nor OpenGL ES Shading Language)! WebGL could be seen as a wrapper for OpenGL ES 2.0 in your browser (and in the current state programmable by JavaScript). Therefore, I will not explain every OpenGL command or speciality. What is pointed out is just how to get your OpenGL knowledge into your browser. General programming knowledge and some HTML/JavaScript expertise may help. If you need help with OpenGL please refer to the masses of great tutorials in the net, especially NeHe and the OpenGL ES 2.0 Programming Guide (the main inspiration for this).

The Page

First of all we will set up our frame, our basic HTML file which we will use throughout this post. To write and develop HTML, JavaScript and therefore WebGL yourself you are pretty open to what to use. You can use a normal text editor or rely on a WebDevelopment environment but there are no distinct WebGL IDEs.
For WebDevelopment you can use Aptana or the direct Eclipse JavaScript Development Branch IDE. Both are fully fledged IDEs with great support, refactoring, auto-completion etc. Always a good simple helper is also Notepad++.
Everything shown here has been developed in Eclipse, Notepad++ and tested in Chrome 9. Chrome 9 is currently the only release browser download with enabled WebGL and has very good Developer Tools. Both is recommended for JavaScript development as debugging is kind of a pain in the a** (we will come to this in later parts).

If you have everything ready, have a look at the initial HTML scaffold:

  1. <!DOCTYPE html>
  2. <html>
  3.  <head>
  4.   <meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />
  5.   <meta name="keywords" content="altdev,webgl,insanitydesign" />
  6.   <meta name="author" content="INsanityDesign" />
  7.  
  8.   <title>WebGL – Part 2: In the beginning there was…</title>
  9.  
  10.   <style type="text/css">
  11.    #canvas {
  12.     width: 640px;
  13.     height: 480px;
  14.    }
  15.   </style>
  16.  
  17.   <script type="text/javascript" src="webgl-utils.js" />
  18.  
  19.   <script type="text/javascript">
  20.    …
  21.   </script>
  22.  </head>
  23.  
  24.  <body>
  25.   <canvas id="canvas">
  26.   </canvas>
  27.  </body>
  28. </html>

This is the scaffold we will use throughout this part to show how to embed WebGL in a HTML file. You can copy it and save it as e.g. an webgl-part2.html file to open it with your WebGL enabled browser. At the moment, there is nothing to see or do. We will consequently fill it up and start using WebGL to draw our triangle.

One thing you might notice immediately if you have seen or written HTML pages before is the first line: <!DOCTYPE html>! This is the reduced Doctype used to init a HTML 5 page. You no longer have to write these long Doctype XHTML 1.0 transitional etc. Just that! Afterwards comes pretty general HTML stuff and nothing very special for our test.
Between lines 11 and 14 we define the width and height of our canvas we want to draw in through CSS. For now and the following we will stick with a classic 640×480. There are several ways to define the width and height of the canvas. As it is an HTML entity you can use everything that HTML allows. Regarding the WebGL drawing viewport we can refer to this size later on, increase or decrease the glViewport.
At line 17 you can see how to embed external JavaScript files into the page. We already embed one .js file in this case: webgl-utils.js! These utils provide some common methods for creating a WebGL context on a canvas. These are cross-browser compatible and actively maintained at Khronos, therefore it is unnecessary to rewrite these by yourself. You can download the original file from the Khronos CVS. Download and save the file at the same location where you put your HTML file. I will rely on these in this and the following parts.
The lines 25 and 26 define the initial canvas which we will use to draw in. It is just a simple HTML entity. We identify it by the id attribute as “canvas” but the naming is up to you (but you would have change other occurrences).

Now, the interesting things will happen in between line 19 and 21. This is where the magic will occur. In this showcase we will fill it part by part to get our triangle in the browser. Every code shown in the following should be copied in between here (or download the full file at the end).

Global Definition

At first, we will add some global variables that we will use in the following WebGL application. In addition, we define our triangle vertices and the mandatory fragment and vertex shader (add this where the dots … are).

  1. <script type="text/javascript">
  2.   //Some global variables
  3.   var gl;
  4.   var width;
  5.   var height;
  6.   var canvas;
  7.  
  8.   //Our triangle
  9.   var vertsTriangle = new Float32Array([
  10.                     0.0, 0.7, 0.0, //Top
  11.                     -0.7, -0.7, 0.0,//Bottom Left
  12.                     0.7, -0.7, 0.0  //Bottom Right
  13.   ]);
  14.   var vertsTriangleBuffer;
  15.  
  16.   //Fragment Shader
  17.   var shaderFS = "precision highp float;\n\
  18.          void main() {\n\
  19.            gl_FragColor = vec4(1.0, 1.0, 0.2, 1.0);\n\
  20.          }\n";
  21.  
  22.   //Vertex Shader    
  23.   var shaderVS = "attribute vec4 position;\n\
  24.          void main() {\n\
  25.            gl_Position = position;\n\
  26.          }\n";
  27.          
  28.   //The shader program
  29.   var shaderProgram;

We define handles for the created GL context we want to re-use throughout this page as well as the width and height of the canvas into which we want to draw. Do not forget the canvas itself, of course. Afterwards we set up the three vertices of our triangle in vertsTriangle.
You may have noticed that we do not type the width/height or gl handle. All variables are just noted as (mutable) var‘s. As JavaScript is a dynamically typed language this is fine. The definition happens as soon as it assigned. But it is never strongly typed for dynamic variables and therefore can rely on different sets of types. Nevertheless, you can also type your variables.
As JavaScript is required to be more and more with high performance inside your browser an initiative started to define some specific arrays to speed up the applications. These Typed Arrays such as the used Float32Array are still in a draft state as well as WebGL but will be released and supported probably in parallel to it.

After the vertices array you can see the fragment and the vertex shader code. Here, it is assigned as String to a JavaScript variable. If you would copy these and remove the special symbols you will get a normal shader as you might know. Here, we explicitly define the end of each line through \n\. This looks odd but is required to compile it later on as the shader source is required to be an array. Therefore, you could also write:

  1. var shaderFS = [
  2.     "precision highp float;",
  3.     "void main() {",
  4.     "gl_FragColor = vec4(1.0, 1.0, 0.2, 1.0);",
  5.     "}"
  6. ];

Both things would work. It may seem pretty odd to write everything directly into these arrays/variables but for now it’s enough as we only need one shader each. In a ladder part we will see how to load/reload specific shaders into your application.
The last thing we already pre-define is a variable for our later assigned shader program.

Entry point

JavaScript itself and in its browser environment have no specific entry point such as a classic main method. Therefore, we have to create an entry point ourself based on the principles of the DOM loading of the WebPage. As we want to start our WebGL application as soon as the actual body of the page (with our canvas) has been loaded, we add a trigger to the body itself. The trigger is docked onto the onLoad delegate of the body:

  1. <body onload="main();">

By that we listen for the body to be loaded (the canvas has to be created in the DOM up to that) and fire our main() method where we start with our part of the application:

  1. /**
  2.  * The main entry point
  3.  */
  4. function main() {
  5.   //
  6.   canvas = document.getElementById("canvas");
  7.   gl = WebGLUtils.setupWebGL(canvas);
  8.   //Couldn't setup GL
  9.   if(!gl) {
  10.     alert("No WebGL!");
  11.     return;
  12.   }
  13.  
  14.   //
  15.   width = canvas.width;
  16.   height = canvas.height;
  17.  
  18.   //
  19.   if(!init()) {
  20.     alert("Could not init!");
  21.     return;
  22.   }
  23.  
  24.   //
  25.   draw();
  26. }

In the first 8 lines we init our canvas and the WebGL context for it. First, we retrieve the canvas element from the DOM through its id “canvas”. Then we call a method from the downloaded WebGL Utils to create and enable the WebGL context of that canvas. Please have a look at part 1 to see what is done in that method. Basically, we utilize the generalized setupWebGL(canvas) method to be cross-browser compatible as there is still no distinct method to init a WebGL context.
Afterwards we retrieve the width and height from the canvas (as defined in the CSS) to reuse these in our glViewport later on. Then we fire a general init() method to setup everything WebGL we need:

  1. /**
  2.  * Init our shaders, buffers and any additional setup
  3.  */
  4. function init() {
  5.   //
  6.   if(!initShaders()) {
  7.     alert("Could not init shaders!");
  8.     return false;
  9.   }
  10.  
  11.   //
  12.   if(!initBuffers()) {
  13.     alert("Could not init buffers!");
  14.     return false;
  15.   }
  16.  
  17.   //
  18.   gl.clearColor(0.0, 0.0, 0.0, 1.0);
  19.   gl.viewport(0, 0, width, height);
  20.   gl.clearDepth(1.0);
  21.  
  22.   //
  23.   return true;
  24. }

In general, the init method follows three steps:

  • Init our shaders
  • Init our buffers (our triangle buffer)
  • Set up the clear color, depth and our viewport

Step 3 should be self-explanatory, therefore we will continue with loading and setting up our shaders.

Load the Shaders

You already saw our two shader variables. Now, we want to compile, attach and link these. For that we require two methods: initShaders() and createShader().

  1. /**
  2.  * Init our shaders, load them, create the program and attach them
  3.  */
  4. function initShaders() {
  5.   //
  6.   var fragmentShader = createShader(gl.FRAGMENT_SHADER, shaderFS);
  7.   var vertexShader = createShader(gl.VERTEX_SHADER, shaderVS);
  8.          
  9.   //
  10.   shaderProgram = gl.createProgram();
  11.   if(shaderProgram == null) {
  12.     alert("No Shader Program!");
  13.     return;
  14.   }
  15.  
  16.   //
  17.   gl.attachShader(shaderProgram, vertexShader);
  18.   gl.attachShader(shaderProgram, fragmentShader);
  19.   gl.linkProgram(shaderProgram);    
  20.  
  21.   //
  22.   if(!gl.getProgramParameter(shaderProgram, gl.LINK_STATUS)) {
  23.     alert("Could not link shader!");
  24.     gl.deleteProgram(shaderProgram);
  25.     return false;
  26.   }
  27.  
  28.   //
  29.   gl.useProgram(shaderProgram);
  30.  
  31.   //
  32.   shaderProgram.position = gl.getAttribLocation(shaderProgram, "position");    
  33.   gl.enableVertexAttribArray(shaderProgram.position);
  34.  
  35.   return true;
  36. }
  37.  
  38. /**
  39.  *
  40.  */
  41. function createShader(shaderType, shaderSource) {
  42.   //Create a shader
  43.   var shader = gl.createShader(shaderType);
  44.   //
  45.   if(shader == null) {
  46.     return null;
  47.   }
  48.  
  49.   //
  50.   gl.shaderSource(shader, shaderSource);
  51.   gl.compileShader(shader);
  52.  
  53.   //
  54.   if(!gl.getShaderParameter(shader, gl.COMPILE_STATUS)) {
  55.     alert("Could not compile shader!");
  56.     gl.deleteShader(shader);
  57.     return null;
  58.   }
  59.  
  60.   //
  61.   return shader;
  62. }

At the beginning of initShaders we call our createShader method with the type of the shader and the according shader source variable. The called method createShader does exactly what the name suggests: It creates a shader based on the given type, compiles the given source and returns the created glShader.
Actually nothing special here as it is just a helper method. If we would hand over the shaderSource in a different format we will probably extend this method to convert the given shader source to a common format. But for now this is fine.
One speciality you can find is the error handling: Throughout the page you can find alerts and empty returns. As we have no specific exit() call in JavaScript or HTML (there is a possibility, but we will not use it later on) we alert the user, firing a MessageBox and empty return. As catched in higher instances this will result in a jump out of the application which leads to a manually “stopped” application. As we entered by ourself through the main() method, we can jump out any time we want. An alert() may not be the nicest way to show errors and exit the application but it at least gives feedback. Later we will see how to combine HTML entities, CSS and WebGL and will use the normal HTML functionality to fire error messages and according to the error lead the user to a solution or mail these errors to the developer.

After we loaded and created our shader we start creating our program at line 10. Again we check for an error that may have occurred. If no error happened we attach both shader objects, link the program and if nothing happened, use it.
If you know OpenGL you might say: Still nothing that special here!… and this is intended. WebGL was intended as a low-level programming opportunity without too many specialities away from the original uses of OpenGL. This was done with VRML and many other special plug-ins but never lead to what was expected as commonly used 3D in the browser.

Nevertheless, one speciality about JavaScript is being used now: The dynamic prototyping. You can see at the end that we return “the index of the generic vertex attribute that is bound to that attribute variable” and we assign it to the shaderProgram as position.

  1. shaderProgram.position = gl.getAttribLocation(shaderProgram, "position");    
  2. gl.enableVertexAttribArray(shaderProgram.position);

This is possible even if we haven’t predefined that variable in the shaderProgram object. We dynamically extend and create a new prototype by assigning the position without prior definition.
This should never be used as best practice as there is no contract we can rely on, e.g. through a specifically defined class, structure or interface. In this simple case as we do not need reusable and generic objects we just assign the handle for later reuse in our own “knowledge space”. Regarding classes and interfaces for contracts, these are all possible in JavaScript and we will come to that in a later part.

But now our shaders are (hopefully) all loaded and assigned so that we can continue setting up our triangle vertices buffer.

Setup the Buffer

To set up the buffer based on our vertices we go straight forward:

  1. /**
  2.  * Init our required buffers (in our case for our triangle)
  3.  */
  4. function initBuffers() {
  5.   //
  6.   vertsTriangleBuffer = gl.createBuffer();
  7.   gl.bindBuffer(gl.ARRAY_BUFFER, vertsTriangleBuffer);
  8.   gl.bufferData(gl.ARRAY_BUFFER, vertsTriangle, gl.STATIC_DRAW);
  9.  
  10.   //
  11.   return true;
  12. }

Absolutely nothing special here! We create the buffer and assign it to our global variable, bind and set the according data. This will become more complicated in later parts, when we define structures, load models etc. But as we just want to draw one triangle this is enough.

Let’s draw

What we really want to do after all this work now is to draw. Therefore, we define our draw() method:

  1. /**
  2.  * Our draw/render main loop method
  3.  */
  4. function draw() {
  5.   // request render to be called for the next frame.
  6.   window.requestAnimFrame(draw, canvas);
  7.  
  8.   //
  9.   gl.clear(gl.COLOR_BUFFER_BIT | gl.GL_DEPTH_BUFFER_BIT);
  10.  
  11.   //
  12.   gl.bindBuffer(gl.ARRAY_BUFFER, vertsTriangleBuffer);
  13.   gl.vertexAttribPointer(shaderProgram.position, 3, gl.FLOAT, false, 0, 0);
  14.  
  15.   //
  16.   gl.drawArrays(gl.TRIANGLES, 0, 3);
  17. }

As you can see no immediate drawing here for this very simple example. This again relates to WebGL and its origin OpenGL ES 2.0: Besides no fixed-function pipeline there is no immediate drawing. We just clear, bind our buffer and draw!
But wait, how do we draw? I said we have no specific entry point and created one ourself. If we have no specific entry point we probably also have no specific draw() loop we can rely on. Again, we have to create on our own. Here again we will rely on a method from the WebGL Utils and the according best practice from Khronos.

In the end of our main method, after all initiations we call our draw() method once:

  1.   //
  2.   draw();
  3. }

After the initial call, in the first line of the draw method we call up a utils method: requestAnimFrame(draw, canvas)! This cross-browser compatible method takes the canvas in which to draw and the according method as callback. Inside is a timeout that will recall and keep the loop running. Currently this is the recommended way to do a loop. But it has to be noted that this not final. You can see the drawbacks immediately in the timeout and in the call directly in the draw method. For now until we see a final call and the draft has been approved we will stick to that as it is nevertheless cross-browser compatible and works fine.

Now, if you copied and setup everything correctly you should see the following:

You can download the full source here. If you downloaded the webgl-utils.js put it at the same location as the HTML file.

This is it… at least for now. There are still some “not so ideal” things here as this is neither best practice nor the only way to program JavaScript and therefore WebGL. Everything is embedded directly into the HTML page, everything is handled as one. The shaders are odd string variables and the process is very focussed around “just work”. But this was intended for now. Now, you have a page you can use as an initial foundation for further experiments. For example, try fooling around with the shaders and see what happens.

Next time we will get into User Input and show how to make the triangle move to the rhythm of our key strokes (and build up our own matrix). In the following parts afterwards I will present how to load textures, load models and operate with several shader files, dynamic loading and obfuscated JavaScript.

Written for #AltDevBlogADay

]]> http://insanitydesign.com/wp/2011/02/27/webgl-part-2-in-the-beginning-there-was/feed/ 1 WebGL – Part 1: A new challenger appears… http://insanitydesign.com/wp/2011/02/13/webgl-part-1-a-new-challenger-appears/ http://insanitydesign.com/wp/2011/02/13/webgl-part-1-a-new-challenger-appears/#comments Sun, 13 Feb 2011 22:51:53 +0000 NeA http://insanitydesign.com/wp/?p=719 As I did not want to be as somewhat polemic as last time I checked several different pragmatic ideas I could post about. I weighted each against the other but with the news that the final draft of WebGL was released I decided to go this route and present some information, basics and a furthermore small tutorial in the following parts about WebGL!

A new challenger appears

Twelve years after HTML4 and eleven years after XHTML1.0 the WorldWideWeb Consortium “finally” dropped all efforts to standardize another, a different and more XML-based standard for the Web and continued where they left off to extend HTML4 to built it up to the requirements of our current time. As we are easily able to define that our current web-browsing habits are influenced by multimedia-based content with YouTube, Facebook, Farmville, Podcasts, … the new standard would have to be more multimedia flexible. And W3C listened!

The consequent successor HTML5 was finally started in 2008. Now, only three years later the standard is seeing the finishing line and most released drafts have already been implemented in common browsers such as Firefox, Chrome or Safari through WebKit. It provides special video, audio and canvas elements, support for codecs such as OGG Theora/Vorbis and MP4 (still a little dependent on decisions and implementation as it is still not final, possibly WebM), semantic support based on RDFa, sectioning etc. and a native 3D API named WebGL!

WebGL is a specification, independent from HTML5 but depending on the Canvas element of the standard. It is implemented as a context of the canvas and can be programmed (for now, actually more will be possible) through JavaScript and shaders. Speed and some specifics are dependent on the actual implementation i.e. the Browser but in general interchangeable in-between different Webengines.

Therefore, WebGL offers native in-browser support for 3D development. But actually the idea of 3D in your Browser is not a new challenge for our beloved internet…

3D on the Web

Already in the early days of the WorldWideWeb several different developers, companies and initiatives tried to establish 3D in the browser to provide a more persuasive environment for the user, correlating what was currently being established in games, that became more and more 3D focused during these years.
Already released in 1995 the Virtual Reality Modeling Language (VRML) tried to bring 3D to the Web. VRML 1.0 allowed to define the geometry, textures, materials etc. and especially scripts to visualize a 3D scene in a common textfile format. This scene was additionally able to retrieve additional data from different URLs as well as to react to events and triggers through special Java/JavaScript programs in its script nodes. Later it was extended to allow animations, sounds and other multimedia assets in 1997 with the VRML 2.0 standard.
The problem with VRML was mainly that it required a plugin to be installed in your browser as well as much processing power. Most plugins weren’t optimized and the scenes described in a very high-level style required too much load. There were some initiatives but besides some world viewers and websites of authorities no one really jumped onto VRML.

In 2001 the Web3D Consortium built a new high-level abstraction for 3D in the Browser: X3D. X3D extended VRML with more standards and especially profiles, shaders, gis and networking. It still requires a plugin or player and was therefore not as perceived as wished for.

As WebGL is more established and well-supported already by nearly every big browser on the market the Web3D initiative now jumps onto that train without giving up VRML and X3D. With X3DOM the initial specification and implementation is now being made available on your browser without the need of plugin a but with the power of WebGL and Canvas.

Nevertheless, in this multi-part series I will only focus on WebGL directly. If you want to know more about these “historic” approaches just follow the given links.

OpenGL in the Browser

In contrast to VRML or X3DOM WebGL follows a more direct (“low-level” in comparison) approach to 3D in the Browser. As the name suggests WebGL is based on OpenGL and specified by The Khronos Group. It is based on OpenGL ES 2.0 (nowadays good known from iOS and Android) and supports GLSL in version ES1.0. It docks onto the HTML5 canvas as a drawing context and with that it is fully integrated in the Document Object Model (DOM) and therefore allows full interaction with the general HTML Layout and Objects (e.g. overlaying, CSS styles, …).

As mentioned, as well as OpenGL WebGL is low-level and fully based around shaders. Therefore, things like defining simple geometry and scenes in an easy XML format as it is possible with X3D is not part of the WebGL standard itself. Possible implementations and APIs on top are nevertheless feasible (and already developed to some degree).

You can nearly cope everything you know about OpenGL ES 2.0 into WebGL. But there are some limitations (besides what is currently still different in-between the different Browser implementations). One important difference is that WebGL has no support for non-power-of-two textures (you could disable mipmapping). You have to resize dynamically. But in general you can feel with WebGL as you do with ES2.0 in other programming languages. It even looks similar. Let’s have a look at an exemplary draw() method (taken from the OpenGL ES 2.0 Programming Guide):

  1. function Draw(esContext) {
  2.    var userData = esContext.userData;
  3.  
  4.    // Set the viewport
  5.    gl.viewport( 0, 0, esContext.width, esContext.height );
  6.  
  7.    // Clear the color buffer
  8.    gl.clear( gl.COLOR_BUFFER_BIT );
  9.  
  10.    // Use the program object
  11.    gl.useProgram( userData.programObject );
  12.  
  13.    // Load the vertex position
  14.    gl.bindBuffer( gl.ARRAY_BUFFER, userData.vertPosObject );
  15.    gl.vertexAttribPointer( userData.positionLoc, 3, gl.FLOAT, false, 0, 0 );
  16.    gl.enableVertexAttribArray( userData.positionLoc );
  17.  
  18.    // Load the index buffer
  19.    gl.bindBuffer( gl.ELEMENT_ARRAY_BUFFER, userData.indicesObject );
  20.  
  21.    // Load the MVP matrix
  22.    gl.uniformMatrix4fv( userData.mvpLoc, false, getAsFloat32Array(userData.mvpMatrix) );
  23.  
  24.    // Draw the cube
  25.    gl.drawElements( gl.TRIANGLES, userData.numIndices, gl.UNSIGNED_SHORT, 0 );
  26. }

Looks pretty familiar, doesn’t it? A description of what this all means and how to really program it in JavaScript and embed it into a WebSite will follow in the coming parts.

Browser support

For the User
First of all you have to be able to see and test WebGL developments. Currently the easiest way to use WebGL is to install the current Chrome Browser. Since version 9 it has enabled WebGL support in its stable release. If you want to use other Browsers such as Mozilla or Safari you would have to get the according nightly builds. In each case you might need to configure the according download. For a small “manual” have a look here or be lazy and use Chrome.

For the Developer
If you want to develop WebGL in a supporting Browser, you check for and enable WebGL through JavaScript by actually just trying and checking for success. There are two things you have to do:

  • Check if the browser supports WebGL in general
  • Find/Get a canvas and enable the WebGL context for it

To check if your browser or more specifically the current window you are in allows WebGL you check for a specific window flag:

  1. if(window.WebGLRenderingContext) //This Window supports WebGL in general!

If this context returns true at least the Browser does support WebGL. Now, you need to check a canvas and enable the WebGL context in that canvas. Normally, you would specify a <canvas> element and hand this to a check and enabling function:

  1. function(canvas) {
  2.   //Several names to check because of still diverse implementations
  3.   var names = ["webgl", "experimental-webgl", "webkit-3d", "moz-webgl"];
  4.  
  5.   //The context we want to fill
  6.   var context = null;
  7.  
  8.   //Iterate over all names and test for success
  9.   for(var i = 0; i < names.length; ++i) {
  10.     try {
  11.       context = canvas.getContext(names[i]); //Optional parameters can be handed to the implementation
  12.     } catch(e) {}
  13.    
  14.     //As soon as we got one -> SUCCESS!
  15.     if(context) {
  16.       break;
  17.     }
  18.   }
  19.  
  20.   return context;
  21. }

If no context can be received but the WebGLRenderingContext says it may do WebGL, some other problems occurred. If the browser supports, you have enabled and retrieved the WebGL context and can start developing applications in your browser with fancy JavaScript.

The “new” power of JavaScript

Actually, nothing is “new” about JavaScript. The JavaScript used to first make a clock tick down on a Website, later to “do AJAX” or now to develop WebGL is pretty much all the same and based around the ECMAScript standard. Even if it contains Java in its name it has nothing to do with it. The former LiveScript is supposedly just named JavaScript to establish it with the already established Java… and probably because of a somehow Netscape/Sun partnership. But do not hesitate: The interpretation of JavaScript during runtime has been incredibly speeded up especially over the last years as more and more client programming is now part of normal websites and administrative interfaces reload and rebuild many things on-the-fly.

For JavaScript itself, it is first and foremost a prototyping programming language. This means that instead of developing a class-based architecture structure that is instanciated and dependent to the initial implementation and used throughout your development, in JavaScript you “re-use” the same classes for all instances with all given methods (called behaviours) that are added at first or also during runtime. These can be extended by the developer. Further the instances made from the structure are the states. In general you could say that prototyping is based on copying: It copies the “prototype” over and over again! Now, the most important thing about the prototype implementation of JavaScript is that it also holds a link to its “prototype” and therefore derives recursively through the prototyping hierarchy to find what we request.

A very simple example: We define a Blog!

  1. var personalBlog = { title="Personal Blog", author="Savas Ziplies" };

Now we define a second blog:

  1. var altDevBlog = { title="AltDev Blog" };

and assign our personalBlog as prototype:

  1. //This does not work in all JavaScript implementation (as not all have the direct prototype to be settable), but for the example we rely on it!
  2. altDevBlog.__proto__ = personalBlog;

Now we query

  1. alert(altDevBlog.author + "@" + altDevBlog.title);

and will get the following result: Savas Ziplies@AltDev Blog! As you can see, even if I have not defined “author” in altDevBlog I may still access it as I specifically set the prototype of altDevBlog to personalBlog, therefore the “author” not available is resolved at the prototype personalBlog and printed. This hierarchy can go on and on forever and can be a performance issue if not consciously developed against. But in general prototyping and JavaScript itself offers many patterns that go well with WebGL and designs in general.

Therefore, JavaScript depends on a little different “thinking” approach. But besides that JavaScript also provides “somehow” object-oriented principles, delegation, dynamic typing, closures, run-time evaluation (very helpful indeed) and much more. Actually, JavaScript is a very powerful and somewhat interesting programming language but just seems awkward to most people because of its syntax, the name and because it is an interpreted language. Nevertheless, you can do practically everything with it, also relying on nearly every design pattern described.

To be concluded…

As I do not want to write a book as I did last time (yeah, hard to believe ^^’), this is it for today. You now know some history, the basic standard and how to “use” WebGL applications. The next parts will feature of course further explanations of WebGL, an additional introduction to JavaScript (and some of the creepy stuff you can do with it), presenting already existing WebGL libraries and an exemplary tutorial game developed fully in WebGL (as well as some twists and tweaks around networking and dynamic loading). In addition we will try to clarify how WebGL stands against other 3D in the Browser such as Flash3D, Unity3D and Shiva3D.

To already give you a taste of what to come and what is possible with WebGL, have a look at these publicly available WebGL Samples over at Googlecode, the astonishing Google Body example or the nice presentation of GLGE in the video.

Written for #AltDevBlogADay

]]> http://insanitydesign.com/wp/2011/02/13/webgl-part-1-a-new-challenger-appears/feed/ 2 New Android OpenGL ES Port – Stencil Shadows http://insanitydesign.com/wp/2009/12/08/new-android-opengl-es-port-stencil-shadows/ http://insanitydesign.com/wp/2009/12/08/new-android-opengl-es-port-stencil-shadows/#comments Tue, 08 Dec 2009 19:24:09 +0000 NeA http://insanitydesign.com/wp/?p=476 Greetings to all of you. Unfortunately long time no “port” see! I had a lot on my mind (something got posted beneath ^^) and a lot to do (many travels, many projects, new horizon). But now I am back in full glorious “in”sanity to enhance your (Android) imagination ^^#

So, first let’s recapture some things about my NeHe Android Ports: To my surprise they were accepted good and got some publicity. I am happy about that… not so much that I had too little time to continue the series like I hoped for. But now I am back and will continue to translate as many NeHe lessons as possible.

But first, I uploaded another port but no NeHe Lesson. The new port is based on code from Apron and his OpenGL tutorial codes and deals with Stencil Shadows. This is definitely something interesting and missing besides what is covered by the NeHe tutorials so far. Therefore, I decided to do this first and then continue with other ports. So, head over to the new section of general Android tutorials and ports under Projects and check out finest stencil shadows on your phone.

PS: I will continue with the NeHe lessons but I will also keep an eye open for other feature/functionality tutorials that could be interesting to know about and are relevant for 3D development on mobile phones.

]]> http://insanitydesign.com/wp/2009/12/08/new-android-opengl-es-port-stencil-shadows/feed/ 1 Android and the (OpenGL) issues http://insanitydesign.com/wp/2009/12/06/android-and-the-opengl-issues/ http://insanitydesign.com/wp/2009/12/06/android-and-the-opengl-issues/#comments Sun, 06 Dec 2009 19:15:12 +0000 NeA http://insanitydesign.com/wp/?p=487 As most people know I pretty much dig Android. I also have been a friend of OpenGL. As I come from the Java side (we have cookies ^^’) and there are two good wrapper implementations with JOGL and LWJGL, I found the perfect combination in OpenGL on Android, hence the tutorial ports.

Over the time I did some tests on Android. Not only with OpenGL but mainly overall to see what could work and how. Unfortunately Android is far from perfect (what ever is?) and has some issues also affecting OpenGL development on Android.

3D Games on Android…
Ravensword - Town BlacksmithGames are probably the main market working with 3D on Mobile Phones nowadays. On the iPhone we have some great examples of cool and nice looking 3D games such as Ravensword and many others. They look good and also run very smoothly (especially on a 3GS, loading times are most of the times much better).
Now, for Android we also have some good Game examples with the just announced winner of the Android Developer Challenge 2 in the category of games: Speed Forge 3D. The really beautiful WipeOut clone gives you a nice 3D game example on Android. Another example is Mystique by Bendroid. The 3D Ego-Survival-Horror in the style of Silent Hill and The Ring is sure to give you some creeps if you play it in a dark room, at night, feeling lonely.

…and the issues!
Now if you compare Speed Forge 3D or Mystique with Ravensword or Gameloft’s upcoming N.O.V.A you probably will get jealous and drool all over the videos. No question: SF3D and Mystique are great, Kudos to the developers, but compared to the iPhone they are far behind.
The big question should be: Why? And the answer is neither simple nor a single one in my opinion.

1. Heterogeneous Phone Market
One big thing coming up with the release of new Android handhelds is the inconsistency throughout the phones. Android itself is a specification and a referential implementation. Now, most phone manufacturer alter some things or add their own implementations of something such as OpenGL. Therefore, it is already the case that with every new release of a mobile phone based on Android you see updates of many Apps popping up because of problems or even crashes on the new device.
Let’s have a look at Speed Forge 3D: I have a HTC Magic and it runs… OK. Not absolutely fluently but playable. Now, a friend of mine has a Samsung Galaxy (or i7500) and he can barely play it until it crashes. Now the Droid from Motorola entered the market with another graphics chip and a larger screen. Many new “properties” to test against and to deal with. The iPhone on the other side may have been updated over the time but the environment stayed nearly the same. And something that runs on the 3GS will also run on the 3G, just load a little longer. So, as time goes by more and more Android devices will come out and will further diverse the market.

2. The Dalvik VM
As always when it comes to Java you will hear people say:

It’s slow because it’s Java!
Java will always be slow!
Forget Java, use the NDK!

(just saw the same posts pop up on the newsgroups and forums again)
They will argue that a Virtual Machine can never give the speed you need (some also tend to forget that .net is a VM interpreted environment). They will argue that the Garbage Collector slows everything down. And if we look back about 10 years they really had a point, but nowadays that may not be total crap but is just not that easy to say.

Poisonville by BigpointFirst of all let’s have a look around at Java-based 3D games, based on the very popular, updated and fast libraries JOGL and/or LWJGL. There would be the experiment Jake2: A Quake2 clone made in Java based on JOGL and LWJGL to have a comparison. If you have a look at the benchmarks you will see it is hard to argue that Java is that slower over the native implementation. And engines such as jMonkeyEngine support the Java faction. The demos over there such as Spirits and other games like Trible Trouble and Poisonville on the other side show that there are very good possibilities to use this object-oriented programming language as your development base.
The thing is that not Java per sé is the problem but as with every programming language the code optimization and the execution environment, in this case the Virtual Machine. Even Tim Sweeney from Epic Games suggests that functional programming and Garbage Collection is the future. The newest Sun Java VM and other VM implementations show what is possible to do with optimization within a managed environment. A good Garbage Collector (GC) and a very good Just-in-Time (JIT) Compiler such as in Suns current Java implementation speed up not only the application but also development itself because of less time spending for the memory management.
But why still the speed problems? As already said, even if Java is interpreted and helps with the memory management you still have to think about what is happening beneath. Most applications tend to just create one instance after the other and do not really care about memory management. This may work on a desktop system but will bring problems to you on Mobile Phones. Things like weak references, caches, volatile and transient are forgotten but highly important terms in Java development. Especially Mobile Applications still have to really care about memory even with all this technically highly fledged phones. Care about the memory more than about computation on modern smartphones.

Nevertheless, even with these more or less “simple” tricks Android still has some problems that you need to remember during development. Most of these result from the Dalvik VM. The current Dalvik implementation on Android phones does not support JIT nor is the Garbage Collector any good.
As no JIT is available all code is interpreted on time and not pre-compiled or anything. On a limited device such as a mobile phone this results in slowdowns. Therefore, it is important to pre-load everything you need and cache as much as you can to have a fluent gaming experience during e.g. a level.
Another thing is the current GC in Dalvik: Avoid it ^^’ Sure, you cannot really avoid the GC directly but try to not release too many objects during gameplay (or fire it by yourself) as the GC will slow your phone so down that even the OS will need time to react. This is also something that can be managed with caching and a good manual memory management. Currently, up to Android 1.6 an application may use up to 12MB of memory. With Android 2.0 this has been upped above 20MB, but as a game should support many platform versions (the issue why I am posting this), 12MB will probably be the limit for a while.

3. The Android OpenGL ES implementations
Another thing that bothers the development of OpenGL ES applications on Android is the again heterogeneous availability of specifications. Android itself by SDK supports OpenGL ES 1.0 and 1.1. The official current OpenGL ES version is already at 2.0. While 1.1 is backwards compatible to 1.0, 2.0 has no backwards compatibility. OK, its to note that 2.0 is somehow pretty fresh and you cannot ask for the newest technology in Mobile Phones. But most Android phones at the moment only support 1.0, for example the HTC Magic whereas the Motorola Droid should be able (hardware-based) to support 2.0.

As 2.0 introduced programmable shaders to the hardware the step is a large one. That is probably also the reason why OpenGL ES 2.0 is the foundation for WebGL, the upcoming and already beta-available 3D JavaScript interpreter for Browsers such as Firefox and the WebKit Engine. So, even if you argue that the newest technology may not be always available in Mobile Phones, as 2.0 is progressing so fast at the moment the diversity between 1.0 on current phones and 2.0 on more and more platforms can result in “support” or portability problems of applications.
The support/portability problem is one of the issues. But more relevant is the functionality available in 1.0 and 1.1. The iPhone is based on OpenGL ES 1.1 and by that it has a big advantage over most Android phones: Vertex Buffer Objects (VBO)! As posted before my tutorial ports, OpenGL ES does not support primitive rendering (glBegin/glEnd). This is good as it will nevertheless be dropped out of the OpenGL standard. In OpenGL ES you have to use Vertex Arrays and/or Vertex Buffer Objects, which are faster anyway. BUT 1.0 only supports Vertex Arrays and no VBOs. This is one big disadvantage not only in speed but in development. You can argue that it is possible to program an application that supports both with tagging the sections but as it comes to mobile development you always try to comprehend everything as much as possible without acting on too many specifics.
Two other important things when it comes to game development are that 1.0 does not support multi-texturing on its own (there are ways, but those are tricks) and it does not support the automatic mipmap generation. Both are necessities if you want to do such nice things like Ravensword or N.O.V.A.
Another thing are the phone specific OpenGL ES implementations. Not only versions but also manufacturers provide different implementations with their phones. For example the Samsung Galaxy has a known very weak OpenGL implementation. There are already several published articles on how to add the HTC implementation to a rooted Galaxy. And as more and more manufactures will enter the Android market in the coming month this will probably get worse.

So, what can be concluded from this? Actually not much but 1.0 <= 1.1 < 2.0! There are some tricks here and there to deal with some things under 1.0 but overall you just have to accept the fact and optimize around what is missing. Or you limit your development to 1.1 (at least for now). But by that you will loose many phones such as the Magic or G1, which probably are the most widespread Android phones at the moment.

4. General and Specific OpenGL (ES) Paradigms and Tactics
As with every programming language or library there are several Best Practices that should be remembered during development. The same thing applies to OpenGL. There are many posts in the net on how to optimize your OpenGL code and you should definitely use Google to keep you up-to-date. I just want to point out two important things (in my opinion) for mobile development.

The first thing is to reduce your draw calls! This is not limited to mobile devices but OpenGL in general. But because of the limited hardware versus a Desktop system, this is even more important. Each draw call is not necessarily bad but in sum are slow. Now, most people do enormous, cool architectures with self-drawing objects that are instanced over and over again. This is nice from an object-oriented point of view but is bad on a mobile device. If you want to do something good and fast for Android work with overall handlers. This relates to what I said about caching. To have super classes, handlers or factories that collect all changed elements or all objects that need to be drawn and only that Object fires the draw call is the way to go. This may look like a limitation but this is not only good for the speed of your application but also reduces the possibility of asynchronous errors when instances of deep objects are computed while the rest already handles another request.
The second thing correlates with what I said about memory handling and caching: Reduce your texture binding calls! To rebind your textures again and again and switch them back and forth is also bad for the overall performance. I know that it is tempting and Android with its nice resource loader somehow invites you to have hundreds of single texture files and load them again and again. But this will get you into trouble really fast. First of all, reduce the calls by utilizing again a super class, a texture handler with some kind of caching mechanism. Another possibility is to merge several textures into one large texture and offset the texture mapping coordinates accordingly. This is easy to do and just requires a small asset pipeline but the advantage is huge.

Both things suggest some very important points that have to be taken into account in the architecture and early development. Therefore, always tend to fulfil the mentioned points already while you are planing.

5. General Mobile Development Paradigms
As well as for OpenGL there are some rules regarding Mobile Development in general. There are also several posts on the net about this topic but just to sum up what I already coped in the above text: A Mobile Device is no Desktop!
Many people come from the Desktop development and are real geniuses there. They make the best applications, fast, functionality perfect and have wonderful graphical user interfaces. BUT what works on a Desktop does not necessarily work like that on a mobile device.
JavaME made it necessary to go back to Java 1.3.1 programming style; To forget about Generics; To forget about Enumerations and just use the “old ways”. Now, with something like the Android SDK, which allows to use nearly the full Java5 specification people just copy their desktop applications into the Android projects and this will make problems. All the things I pointed out above result from that premise as the desktop is the more forgiving (because more powerful) platform.
Things like creating hundreds of instances, using hundreds of different files, not working with in-memory data but reloading everything over and over again are bad… bad… and even worse, really bad! Do not get fooled by all the technical specifications of the mobile devices. You cannot compare the CPU and the RAM with the desktop pendent. I recommend to have a look “back” at the JME development and the experience people made there. Do not copy it one-to-one but use it as a guideline and convert it into a comprehensible Android project. Most problems, most errors, most failures that are posted and reported result from the unused experience made in that mobile development area. Reuse that knowledge, reuse their principles, their ideas and you will avoid many problems. And as there are enough “new” problems do not trip into the old ones.

In conclusion
Please do not get me wrong: My opinion about Android is high, I have one on my own and I love it. Love developing on it, love the SDK updates. The only thing I want to point out is that development on Android phones and Android itself has to start to keep these five things in mind. The next three to six month mark an important state with Android where to go and with at least the noted points you should be good to go.
So, go out there and really work on it to do the best f***in’ 3D Android game of them all (and comment about it here ^^’)!

]]> http://insanitydesign.com/wp/2009/12/06/android-and-the-opengl-issues/feed/ 6 The first 10 NeHe Android tutorials http://insanitydesign.com/wp/2009/08/08/the-first-10-nehe-android-tutorials/ http://insanitydesign.com/wp/2009/08/08/the-first-10-nehe-android-tutorials/#comments Sat, 08 Aug 2009 22:14:09 +0000 NeA http://insanitydesign.com/wp/?p=447 Finally! This is again a short but important post. The first 10 NeHe Android ports have been completed. You can find these over at the project page.

This is an important Milestone of the porting, because now you can get a complete overview of the most important things you need to build your own application. I will continue with the porting. Also, I am currently looking at some other tutorials I have learned OpenGL with besides NeHe, and I will try to find time to port these too, as they focus around other specifics (e.g. Models, Animation, Camera, etc.).

So, stay tuned for more and head over to the current ports.

]]> http://insanitydesign.com/wp/2009/08/08/the-first-10-nehe-android-tutorials/feed/ 0 Two new NeHe Android Ports http://insanitydesign.com/wp/2009/08/06/two-new-nehe-android-ports/ http://insanitydesign.com/wp/2009/08/06/two-new-nehe-android-ports/#comments Thu, 06 Aug 2009 19:20:17 +0000 NeA http://insanitydesign.com/wp/?p=431 Just a short notice: I added two additional NeHe Android Ports. One is Lesson 09, showing some more blending and working with many star objects. Therefore, continuing the tutorials. The other is Lesson 16. This I added as it only requires minor changes to the tutorials 07 and/or 08. This was a quick port but maybe represents a nice “Cool Looking Fog” ^^.

So, just head over to the page and have a look. Again, more to come…

]]> http://insanitydesign.com/wp/2009/08/06/two-new-nehe-android-ports/feed/ 0 NeHe Android Ports http://insanitydesign.com/wp/2009/08/02/nehe-android-ports/ http://insanitydesign.com/wp/2009/08/02/nehe-android-ports/#comments Sun, 02 Aug 2009 21:32:14 +0000 NeA http://insanitydesign.com/wp/?p=401 NeHe Android PortsAs some may have noticed, I am experimenting with Android, especially with its OpenGL functionality. As I am not inexperienced with OpenGL and Java through my “playing around” with JOGL, I thought I may get a quick access to Android and OpenGL. Cannot be that hard… it is not exactly hard, but it is different. Android supports OpenGL ES as part of its system, framework and SDK. OpenGL ES is not OpenGL, and principles as well as things you do with OpenGL to quickly achieve results cannot be done with OpenGL ES the same way.

NeHe ProductionsThere are actually some minor OpenGL ES tutorials out there and some very basic Android OpenGL tutorials, but none of them show a wide range of functionality. As I am personally a big fan of probably the best OpenGL tutorials in the net, NeHe, I wanted to stick with these and try to adapt these onto Android. This is not exactly the most difficult task but you have to think around the corner at once. The NeHe tutorials are more OpenGL functionality test beds, to show of what could be done and could be combined. The style is straight forwards and very easy to understand but does not work without some rework with Android.

Therefore, I started porting the NeHe tutorials to Android. First, just for myself, to get used to Android and OpenGL, but I think they may be helpful to others, too. That is why I started a project page for this, currently coping the first eight tutorials of NeHe ported to Android with a little explanation what has been changed regarding the platform requirements. I will continue to expand the tutorials and port all others that can be done on Android. I hope anybody looking for help in that area can be helped with the ports.
If any questions should occur, problems, comments, good or bad, just comment to the NeHe Android Ports page and I will get to it. In the meantime I will continue experimenting and porting the rest of the NeHe tutorials. I try to keep this up-to-date on a regularly basis but I cannot promise anything.

]]> http://insanitydesign.com/wp/2009/08/02/nehe-android-ports/feed/ 0 Android OpenGL ES – Mipmaps http://insanitydesign.com/wp/2009/08/01/android-opengl-es-mipmaps/ http://insanitydesign.com/wp/2009/08/01/android-opengl-es-mipmaps/#comments Sat, 01 Aug 2009 22:02:08 +0000 NeA http://insanitydesign.com/wp/?p=128 I am currently a little bit experimenting with Android and its SDK as I am proud owner of a HTC Magic as well as I am pretty impressed by the SDK, Android itself and the ideas and principles it follows.
More precisely I am playing around with the graphical functionalities of Android, especially OpenGL. Android contains an OpenGL ES implementation, therefore I am playing around with some OpenGL codes and test the capabilities and results.

So, I was testing some texturing and of course wanted to test the mipmapping possibilities. Here I tripped over some “problems” you have to avoid by going another way.
In a probably classical way you could use glu to build the mipmaps 

gluBuild2DMipmaps(GL_TEXTURE_2D, 3, sizeX, sizeY, GL_RGB, GL_UNSIGNED_BYTE, data);

You hand it the width and height and the texture data and it creates all your needed mipmaps. Problem solved! Unfortunately Android only provides a very small GLU implementation with some helper functions and does not provide you that functionality. Therefore, you would have to go another way.
A possibility on an Android system could be to test for version 1.1 of your GL and use the according hint, as 1.1. adds automatic mipmap generation 

gl.glBindTexture(GL10.GL_TEXTURE_2D, textureID);
gl.glTexParameterf(GL10.GL_TEXTURE_2D, GL10.GL_TEXTURE_MAG_FILTER, GL10.GL_LINEAR);
gl.glTexParameterf(GL10.GL_TEXTURE_2D, GL10.GL_TEXTURE_MIN_FILTER, GL10.GL_LINEAR_MIPMAP_NEAREST);
if(gl instanceof GL11) {
  gl.glTexParameterf(GL11.GL_TEXTURE_2D, GL11.GL_GENERATE_MIPMAP, GL11.GL_TRUE);
  GLUtils.texImage2D(GL10.GL_TEXTURE_2D, 0, bitmap, 0);
} else {
  buildMipmap(gl, bitmap);
}

For the emulator this might work but not every mobile device running Android must have a GL11 instance. Therefore, this solution can work but does not necessarily have to.
Mike Miller had a similar problem/idea and suggested the following functionality 

private void buildMipmap(GL10 gl, Bitmap bitmap) {
  //
  int level = 0;
  //
  int height = bitmap.getHeight();
  int width = bitmap.getWidth();

  //
  int[] textures = new int[1];
  gl.glGenTextures(1, textures, 0);
  textureID = textures[0];

  //
  gl.glBindTexture(GL10.GL_TEXTURE_2D, textureId);

  //
  while(height >= 1 || width >= 1) {
    //First of all, generate the texture from our bitmap and set it to the according level
    GLUtils.texImage2D(GL10.GL_TEXTURE_2D, level, bitmap, 0);

    //
    if(height == 1 || width == 1) {
      break;
    }

    //Increase the mipmap level
    level++;

    //
    height /= 2;
    width /= 2;
    Bitmap bitmap2 = Bitmap.createScaledBitmap(bitmap, width, height, true);

    //Clean up
    bitmap.recycle();
    bitmap = bitmap2;
  }

  return textureID;
}

The code is pretty straight forward. It just creates always the mottled bitmap and adds it using GLUtils to the according level, beginning from 0 to whatever level the size 1 for width or height will be.
Unfortunately again, this did not work for me. I tried this in an existing code I had, a special plain project just for mipmap testing, with different AVDs and with different circumstances. Nothing worked! As soon as I added another layer the texture stayed white. I am aware that as soon as you set the texture parameters for mipmapping 

gl.glTexParameterf(GL10.GL_TEXTURE_2D, GL10.GL_TEXTURE_MAG_FILTER, GL10.GL_LINEAR);
gl.glTexParameterf(GL10.GL_TEXTURE_2D, GL10.GL_TEXTURE_MIN_FILTER, GL10.GL_LINEAR_MIPMAP_NEAREST);

it wants all layers. The function posted by Mike provides these but still it did not work for me. I had no idea why it did not work, because that it is a common solution, trivial and eventually should work. (Nevertheless, I solved it. Read at the end of this post why it did not work for me.)
I do not remember why I tried the following, but after many hours and lost hair I replaced the line of GLUtils.texImage2D(GL10.GL_TEXTURE_2D, level, bmp, 0); with the following, actually resembling what GLUUtils should provide, but based on an older SDK version 

ByteBuffer bytebuf = ByteBuffer.allocateDirect(bmp.getHeight() * bmp.getWidth() * 4);
bytebuf.order(ByteOrder.nativeOrder());
IntBuffer pixelbuf = bytebuf.asIntBuffer();

for(int y = 0; y < bmp.getHeight(); y++)
  for(int x = 0; x < bmp.getWidth(); x++) {
    pixelbuf.put(bmp.getPixel(x, y));
  }
pixelbuf.position(0);
bytebuf.position(0);

gl.glTexImage2D(GL10.GL_TEXTURE_2D, level, GL10.GL_RGBA, bmp.getWidth(), bmp.getHeight(), 0, GL10.GL_RGBA, GL10.GL_UNSIGNED_BYTE, pixelbuf);

This basic self-implementation of what should be done by GLUtils works for me. But please note that it is just a working example and does is neither optimized nor necessarily the finite solution to this task.

I also figured out why the GLUtils did not work for me: It was only in the Emulator and it was only on one of my machines. And especially that machine it did not work on has a very basic, cheap, old graphics card. But for a whole overview and if you step into the same trap, I posted everything so you know what could be a reason and how to solve it.

So, now after all these tests I have done I have three implementations that work for me. On the one hand side, the use of GL11 and the self-implementation of a mipmap building method in two ways. In conclusion after all these tests and also minor performance tests I did, use one of the suggested methods from above or let me know of other possibilities. I would start with the GL11 test and then go over to the implementations. GLUtils should always work. Hope this helps…

]]> http://insanitydesign.com/wp/2009/08/01/android-opengl-es-mipmaps/feed/ 9