Note: the following contains some spoilers – if you haven’t played Mindless yet go check it out.

When I first learned about the js13KGames competition I asked Nick Anderson if he would like to help come up with a compelling game and story. A few weeks before this we had been talking about video games and some different elements he has wanted to see. After some discussion we landed on a zombie apocalypse with a twist – you are one of the infected and are being instructed to kill healthy civilians and scientists.

Nick’s idea was to see how people react to a story where what the “tutorial” is telling you doesn’t match what the characters are saying. We were relying on people’s trust of the introduction messages we have all grown accustomed to at the beginning of games. In Mindless, you are introduced as one of the last healthy people in town and are tasked with killing the scientists who created the virus. After walking down the first hallway, the player has killed a guard, a scientist, and a couple “infecteds” who are actually healthy civilians. The game play is established and nothing has contradicted expectations that the prompt is telling the truth.

The first room has a few (truly) infected people and one scientist. When you walk up to the scientist he pleads for you to stop and spare his life. This is the first time one of the characters talks to the player, and if you don’t kill him or walk away he speaks again. Moving on the player encounters a good mix of guards, scientists, civilians, and infecteds. If the player does not immediatly kill the scientists or civilians (who we are told are actually infected) then some dialog is shown, expressing what is really happening. These characters explain that there is a room on the other side of the lab where scientists have the solution and are trying to heal everyone, introducing the second possible ending.

Response to the story line has been mixed. Some people got it and were really excited about what was going on. Others blasted through the dialog and walked around stabbing everyone. Generally, those who didn’t read much of the dialog were confused about what they were supposed to do, thinking it was a run-and-slash which would have clear direction. It didn’t help that we had to remove 70% of Nick’s dialog to squeeze everything into 13Kb. Overall we learned that people really trust what is said in the introduction and anything which contradicts it should be killed.

In case you missed it – Play Mindless

If you have been anywhere but under a rock then you have heard about Javascript’s new requestAnimationFrame function. You have probably used the shim posted by Paul Irish, may have tinkered with the version created by Opera developer Erik Möller, or even read various articles explaining how to best use it.

I think requestAnimationFrame is a great addition to Javascript, but these two points need some emphasizing:

• Use requestAnimationFrame for animations / screen updates

• Do not use it for anything else (especially game logic!)

Seems kind obvious, right? requestAnimationFrame has the word “animation” right in its name. However, examples and articles have been circling the net which talk about completely replacing setTimeout with requestAnimationFrame. In some cases this is indeed the best thing to do, but I would argue that most of the time you will need to use setTimeout or setInterval as well.

Quick example

What exactly does this mean? Here’s a short demonstration; the top code block relies on requestAnimationFrame to handle everything while the second block has the game logic separated out from the graphics.

function render() {
    [...] // Code to update the DOM, or Canvas,
          // or anything else graphics-related

    [...] // Update the player's location, health,
          // or anything else logic-related
    
    requestAnimationFrame( render );
}

function render() {
    [...] // Code to update the DOM, or Canvas,
          // or anything else graphics-related
    
    requestAnimationFrame( render );
}

function gameStep() {
    [...] // Update the player's location, health,
          // or anything else logic-related
    
    setTimeout( gameStep, 1000 / 60 ); // process the game logic
                                    // at a target 60 FPS.
}

The Growing Trend

I’m just as guilty of abusing requestAnimationFrame as anyone else. In my physics plugin for Three.js I’m still using requestAnimationFrame to schedule both the physics updates as well as the rendering. The physics is handled in a web worker to avoid slowing the graphics framerate, but that simulation is still bound to the rendering because it is called from requestAnimationFrame. If the physics engine isn’t ready for another update until after the graphics render then it will sit around doing nothing for 10-15ms until requestAnimationFrame fires again. Changing the simulation loop to use setTimeout separates the logic from the graphics code and speeds up the whole demo by more than 30% in my tests – increasing the simulation’s effective FPS from 14 to over 20.

One common way to use requestAnimationFrame for game logic is to use a delta value to determine how much time has actually passed since the last update; in fact this is a smart thing to do whether your use the requestAnimationFrame or setTimeout method. However, relying on just this delta means your logic code is still bound to the graphics loop which can cause unexpected results – say in a multiplayer environment when the user will want their actions to be reflected immediately on the server instead of waiting for some graphics layer to first run.

You might think that this use of requestAnimationFrame is only an isolated issue but recently more people have been noticing its impact. Just a couple of days ago someone came into the #threejs IRC channel with this question:

Hi there, I’ve a short question…

I recently updated my code using requestAnimationFrame(), now my animation runs as fast as possible, where before it was running at fixed 30fps

i implemented a navigation through the space using the cursor-keys, but now the navigation-speed depends on the speed of the browser/computer

The solution was to move his game logic out of the requestAnimationFrame loop and put it in a separate loop driven by setTimeout. There are in fact a few things which will cause a requestAnimationFrame-based loop to run at different speeds.

• requestAnimationFrame is designed to speed up and slow down to match the monitor’s refresh rate. If you rely on it to drive logic then your game will play at different speeds depending on how quickly the monitor updates.
• When a brower tab other than your page is selected the browser will slow down calls to your requestAnimationFrame loop – typically dropping to once per second. When your page is not being displayed there is no point in rendering anything on it.
• A browser may throttle calls to your render function if the computer is in battery conservation mode. One of the biggest drains on a laptop battery is graphics and reducing how often draws occur has a big impact on battery life. If your code depends on requestAnimationFrame then it could slow down dramatically when the battery level is low.

Take away

If you need to make recurring updates to something on the screen such as DOM changes or canvas drawing then you should definitely use requestAnimationFrame. But if you need to regularly make updates to data then setTimeout is still your friend. Using requestAnimationFrame and setTimeout together is not evil nor is it duplicating functionality. These functions are allies, not enemies, and when used together properly they can create robust user-friendly applications with the best of both worlds.

What is it?

Physijs brings a very easy to use interface to the three.js framework. One of the reasons three.js is so popular is because it is so incredibly easy for graphics newbies to get into 3D programming. Physijs takes that philosophy to heart and makes physics simulations just as easy to run. In fact, there are just five easy steps that must be taken to make a 3D scene come alive.

How does Physijs work?

Physijs is built on top of ammo.js and runs the physics simulation in a separate thread (via web worker) to avoid impacting in your application’s performance and taking up your your 3D rendering time.

A lot of effort has been made to keep the style of code the same when using this plugin. Apart from updating an object’s position, all of the normal three.js conventions remain the same. If you are used to three.js, you already know how to use Physijs.

Who is this for?

You, hopefully. If you are familiar with three.js and want to add physics to your scene, this is the plugin for you. No mucking about with shape definitions, keeping objects in their correct positions, or identifying collisions – simply use a few Physijs objects in place of three.js’s and you’ll automatically have a dynamic environment.

If you need (or want) a feature not already included then add it to the issue tracker or implement it yourself and send over a pull request at the github repo.

Examples

Features

• Support for multiple object shapes, including custom convex objects.
• Material system provides simple control over friction and restitution (“bounciness”)
• Integrated collision detection and events
• Compound objects using the hierarchy system in three.js
• Rotations using either euler or quaternion systems – your preference
• Built seamlessly on top of three.js to keep the same convention and coding style

In the Future

• More (and better) optimizations
• Constraint systems such as point-to-point and hinge.
• Vehicle systems
• Heightfield/heightmap shape
• It would be awesome to have concave shape decomposition

Go to GitHub repo »

For my entry to the Pokki 1UP contest I rushed out a simple physics-based WebGL game. From start to finish I had 9 days left until the game needed to be submitted. I broke that down into one day for the initial setup, a couple days for physics, one day for sound, one day for interface, and the last day for minute touch ups. Turned out to be the perfect timeline. The setup consisted of creating a Three.js environment within the Pokki framework. I also spent that first day hashing out the basic ideas, inspired by a “reverse Tetris” plan.

The second day was my first real attempt at using any physics library. Right now the most popular Javascript physics library is probably Box2D, as long as you don’t need to simulate a full 3D world. My game didn’t need an entire 3D simulation – the player can only move blocks along the X axis and gravity only applies to the Y axis; no simulation was needed across the Z axis. However, the results I got from Box2D were poor. It seemed to detect collisions a bit late and I wasn’t able to coerce any of the boxes to interact in a believable way. I attribute that to my unfamiliarity with the library, but I was on a very tight time table and I had spent a full night failing to achieve decent results.

Next night I found my winner – Ammo.js – which is a direct port from the C++ library Bullet physics. An added benefit is Ammo.js does simulate a full 3D environment, not just 2 dimensions like Box2D; this gave my game more realism as the blocks aren’t constrained to just XY coordinates. I was able to get all of the necessary physics setup in just a few hours – from a static ground plane to placeable blocks and a tipping tower. In this post I am leaving out any of the scene management of creating and adding the 3D objects themselves; if you are not familiar with Three.js I highly suggest doing yourself a favor and learn how to setup a simple scene, and then play with some of the included examples.

Setting up the scene

In order to use Ammo.js in your 3D scene you must first create the simulation world. These six lines create a default environment and add it as a property to the THREE.Scene object, making it simple to interactive with later. The only customization you need to do here is adjust the gravity vector on the last line.

var collisionConfiguration = new Ammo.btDefaultCollisionConfiguration();
var dispatcher = new Ammo.btCollisionDispatcher( collisionConfiguration );
var overlappingPairCache = new Ammo.btDbvtBroadphase();
var solver = new Ammo.btSequentialImpulseConstraintSolver();
scene.world = new Ammo.btDiscreteDynamicsWorld( dispatcher, overlappingPairCache, solver, collisionConfiguration );
scene.world.setGravity(new Ammo.btVector3(0, -12, 0));

Creating the ground

For the second part of creating a scene we need to initialize the ground object. This takes a few more lines of code than creating the world, but not by much. Again, most of the code is simply creating the default configuration. One important thing to remember here is that the shape measurements used on the first line is half of the full ground’s box. This is the case in both Ammo.js and Box2D when creating either a box or a sphere – the size you pass in is either the sphere’s radius or half the box’s measurements. Second, remember to set the ground’s mass to 0 so that gravity cannot affect it. Basic principle of physics: an object without mass cannot move (or exist, usually… but hey, this is just a simulation!)

var groundShape = new Ammo.btBoxShape(new Ammo.btVector3( 25, 1, 25 )); // Create block 50x2x50
var groundTransform = new Ammo.btTransform();
groundTransform.setIdentity();
groundTransform.setOrigin(new Ammo.btVector3( 0, -1, 0 )); // Set initial position

var groundMass = 0; // Mass of 0 means ground won't move from gravity or collisions
var localInertia = new Ammo.btVector3(0, 0, 0);
var motionState = new Ammo.btDefaultMotionState( groundTransform );
var rbInfo = new Ammo.btRigidBodyConstructionInfo( groundMass, motionState, groundShape, localInertia );
var groundAmmo = new Ammo.btRigidBody( rbInfo );
scene.world.addRigidBody( groundAmmo );

Creating boxes

So far we’ve created a 3D scene and a 3D world. They know nothing about each other, and there’s nothing going on physics-wise anyway. Now it’s time to create a box and add it to the world. There is one major point to pay attention to here: Ammo.js uses quaternions to represent an object’s rotation. Three.js models use Euler rotation by default, but you can change that by setting mesh.useQuaternion = true; You’ll see in the next section how to update a Three.js scene from the Ammo.js world.

var mass = 3 * 3 * 3; // Matches box dimensions for simplicity
var startTransform = new Ammo.btTransform();
startTransform.setIdentity();
startTransform.setOrigin(new Ammo.btVector3( position_x, 20, position_z )); // Set initial position

var localInertia = new Ammo.btVector3(0, 0, 0);

var boxShape = new Ammo.btBoxShape(new Ammo.btVector3( 1.5, 1.5, 1.5 )); // Box is 3x3x3
boxShape.calculateLocalInertia( mass, localInertia );

var motionState = new Ammo.btDefaultMotionState( startTransform );
var rbInfo = new Ammo.btRigidBodyConstructionInfo( mass, motionState, boxShape, localInertia );
var boxAmmo = new Ammo.btRigidBody( rbInfo );
scene.world.addRigidBody( boxAmmo );

boxAmmo.mesh = box; // Assign the Three.js mesh in `box`, this is used to update the model position later
boxes.push( boxAmmo ); // Keep track of this box

Lights, camera, action!

“Wait just a minute,” I hear you exclaim, “that does nothing, the box just floats in the air not moving at all!” You are correct, and it is now time to run the physics and update the 3D scene. To do that I have a function which is called from the render loop.

updateBoxes = function() {
	scene.world.stepSimulation( 1 / 60, 5 ); // Tells Ammo.js to apply physics for 1/60th of a second with a maximum of 5 steps
	var i, transform = new Ammo.btTransform(), origin, rotation;
	
	for ( i = 0; i < boxes.length; i++ ) {
		boxes[i].getMotionState().getWorldTransform( transform ); // Retrieve box position & rotation from Ammo
		
		// Update position
		origin = transform.getOrigin();
		boxes[i].mesh.position.x = origin.x();
		boxes[i].mesh.position.y = origin.y();
		boxes[i].mesh.position.z = origin.z();
		
		// Update rotation
		rotation = transform.getRotation();
		boxes[i].mesh.quaternion.x = rotation.x();
		boxes[i].mesh.quaternion.y = rotation.y();
		boxes[i].mesh.quaternion.z = rotation.z();
		boxes[i].mesh.quaternion.w = rotation.w();
	};
};

Finishing touches

Finally, add in some user interaction and you have a nice little demo. After the basics are in place you can begin expanding to your heart’s content. Maybe it’s as simple as dropping boxes from the air, or maybe you’d be more interested in creating a bowling ally. Perhaps a game of ping pong or air hockey? Whatever it is, using Ammo.js with Three.js is simple and there’s no reason not to try it.

If you’re anything like me, looking at an example’s source code is just as much help as a blog post introducing some concepts. An example using the code from this post can be viewed over on this page.

Where in the world have I been the past two months?

Late last December Pokki announced their 1UP HTML5 game contest, which ends today. I started working on a World War II themed RTS. As it turns out, making a real time strategy game requires more than 2 months if you’re starting from scratch. So one week before the contest deadline I scrapped that idea and started work on a completely different game.

Fortunately I was able to complete the second concept in time. The game is called Tower and the aim is to build the tallest stack of wooden and stone blocks as you can while racing the clock. For now Tower is only available to Windows users through the Pokki store, but I will put it online for others when the contest is over.

I will put up another post in a week or so detailing how I put Tower together. It was the first time I worked with any of physics libraries (happily decided on ammo.js) but overall everything was straightforward.

Click here to download Tower for Pokki

Download ThreeCSG.js

First, an example of what code using just the CSG library looks like:

var cube = new CSG.cube();
var sphere = CSG.sphere({radius: 1.3, stacks: 16});
var geometry = cube.subtract(sphere);

 
 
 
 
Let’s add in Three.js and my CSG wrapper:

var cube = THREE.CSG.toCSG(new THREE.CubeGeometry( 2, 2, 2 ));
var sphere = THREE.CSG.toCSG(new THREE.SphereGeometry(1.4, 16, 16));
var geometry = THREE.CSG.fromCSG( sphere.subtract(cube) );
var mesh = new THREE.Mesh(geometry, new THREE.MeshNormalMaterial());

It’s that simple. The toCSG function accepts objects of both THREE.Geometry and THREE.Mesh types. Objects can be positioned either by the mesh’s position or by supplying a second parameter to the toCSG function. Both methods are shown below. (rotation can be set from the mesh’s rotation property or through a supplied third parameter)

var cube_mesh = new THREE.Mesh(
	new THREE.CubeGeometry( 2, 2, 2 )
);
cube_mesh.position.x = 1;

var cube = THREE.CSG.toCSG(cube_mesh);
var sphere = THREE.CSG.toCSG(new THREE.SphereGeometry(1.4, 16, 16));
var geometry = sphere.subtract(cube);
var mesh = new THREE.Mesh(geometry, new THREE.MeshNormalMaterial());

var cube = THREE.CSG.toCSG(
	new THREE.CubeGeometry( 2, 2, 2 ),
	new THREE.Vector3(-1, 0, 0)
);
var sphere = THREE.CSG.toCSG(new THREE.SphereGeometry(1.4, 16, 16));
var geometry = THREE.CSG.fromCSG( sphere.subtract(cube) );
var mesh = new THREE.Mesh(geometry, new THREE.MeshNormalMaterial());

In these examples I only used the built in primitive objects but the same functionality should work for any Three.js compatible models. UV coordinates are not generated (all values are set to 0) but everything else related to THREE.Mesh works as you would expect.

Links, resources
Live demo of the last example
CSG wrapper for Three.js

([^\s][\s\S]{0,20}(?!=[^\s]))([\s]|$)

This magical regex will trim & truncate text down to 20 characters without breaking apart the last word. Need a different number of characters? Just change the “20″ to whatever you need. Here are some quick examples:

"I'm sorry Dave, I cannot let you do that." -> "I'm sorry Dave, I"
"Top 'o the morning to ye!" -> "Top 'o the morning to"
"             Testing the trimming out!       " -> "Testing the trimming"

View demo.

After my last post about a basic parallax shader I have been working on implenting a steep parallax shader in WebGL. This shader is a lot more computationally intense than normal parallax because it uses ray tracing to find the correct UV values and to cast shadows onto itself. There is only one big change between the original shader and my WebGL implementation and that is using for loops instead of whiles. This change had to be made because WebGL’s specifications don’t support while loops. This is for security reasons, so that a website cannot create infinite loops in the GPU and hang the user’s system. Likewise, for loops must loop over constants. This change makes the shader less efficient but it isn’t too much of an impact and requires the number of ray trace steps to be hard-coded in the shader.

As this shader ray traces each individual pixel it is best used on objects which take up a smaller amount of the screen real estate. When viewing the example I see 60fps at 800×600 but it drops to around 30fps at 1920×1200.

Vertex Shader

	uniform vec3 LightSource;
	
	attribute vec4 tangent;

	varying vec2 vUv;
	varying vec3 vPosition;
	
	varying vec3 vNormal;
	varying vec3 vTangent;
	varying vec3 vBinormal;
	
	varying vec3 tsPosition;
	varying vec3 tsCameraPosition;
	varying vec3 tsLightSource;
	
	void main( void ) {
		
		vUv = uv;
		vPosition = position;
		
		gl_Position = projectionMatrix * modelViewMatrix * vec4(vPosition, 1.0);
		
		// Find & normalize the plane's normal, tangent, and binormal vectors
		vNormal = normalize( normal );
		vTangent = normalize( tangent.xyz );
		vBinormal = normalize( cross( vNormal, vTangent ) * tangent.w );
		
		// Convert vertice, camera, and light vector positions into tangent space
		mat3 TBNMatrix = mat3(vTangent, vBinormal, vNormal);
		tsPosition = position * TBNMatrix;
		tsCameraPosition = cameraPosition * TBNMatrix;
		tsLightSource = LightSource * TBNMatrix;
		
	}

Fragment Shader

	uniform sampler2D base;
	uniform sampler2D map;
	
	uniform vec3 ambientColor;
	uniform vec3 diffuseColor;
	uniform vec3 specularColor;
	uniform float shininess;
	uniform float scale;
	uniform float shadow;
	
	varying vec3 vNormal;
    varying vec3 vTangent;
    varying vec3 vBinormal;
	
	varying vec3 vPosition;
	varying vec2 vUv;
	
	varying vec3 tsPosition;
	varying vec3 tsCameraPosition;
	varying vec3 tsLightSource;
	
	void main()
	{
		float bumpScale = scale;
		
		// normalize the other tangent space vectors
		vec3 viewVector = normalize(tsCameraPosition - tsPosition);
		vec3 lightVector = normalize(tsLightSource - tsPosition);
		
		vec3 tsE = normalize(tsCameraPosition);

		const float numSteps = 30.0; // How many steps the UV ray tracing should take
		float height = 1.0;
		float step = 1.0 / numSteps;

		vec2 offset = vUv;
		vec4 NB = texture2D(map, offset);

		vec2 delta = vec2(-tsE.x, -tsE.y) * bumpScale / (tsE.z * numSteps);

		// find UV offset
		for (float i = 0.0; i < numSteps; i++) {
			if (NB.a < height) {
				height -= step;
				offset += delta;
				NB = texture2D(map, offset);
			} else {
				break;
			}
		}
		
		vec3 color = texture2D(base, offset).rgb;
        
        
        	vec3 normal = texture2D(map, offset).rgb * 2.0 - 1.0;

		// calculate this pixel's lighting
        	float nxDir = max(0.0, dot(normal, lightVector));
        	vec3 ambient = ambientColor * color;

        	float specularPower = 0.0;
        	if(nxDir != 0.0)
        	{
                	vec3 halfVector = normalize(lightVector + viewVector);
                	float nxHalf = max(0.0, dot(normal, halfVector));
                	specularPower = pow(nxHalf, shininess);
        	}
        	vec3 specular = specularColor * specularPower;
        
        
        	vec3 pixel_color = ambient + (diffuseColor * nxDir * color) + specular;
        
		// find shadowing if enabled
        	if (shadow == 1.0) {
	        	vec2 shadow_offset = offset;
			vec3 tsH = normalize(lightVector + tsE);
			float NdotL = max(0.0, dot(normal, lightVector));
			
			float selfShadow = 0.0;
			
			if (NdotL > 0.0) {
				
				const float numShadowSteps = 10.0;
				step = 1.0 / numShadowSteps;
				delta = vec2(lightVector.x, lightVector.y) * bumpScale / (numShadowSteps * lightVector.z);
				
				height = NB.a + step * .1;
				
				for (float i = 0.0; i < numShadowSteps; i++) {
					if (NB.a < height && height < 1.0) {
						height += step;
						shadow_offset += delta;
						NB = texture2D(map, shadow_offset);
					} else {
						break;
					}
				}
				
				selfShadow = float(NB.a < height);
				
			}
			
			if (selfShadow == 0.0) {
			pixel_color *= .5;
			}
		}
		
		gl_FragColor = vec4(pixel_color, 1.0);
		
		if (offset.x < 0.0 || offset.x > 1.0 || offset.y < 0.0 || offset.y > 1.0) {
			gl_FragColor.a = 0.0;
		}
	}

There are the same seven parameters passed in as the normal parallax shader plus an additional one, shadow

• base – the texture
• map – normal map in RGB space, height/bump map in the alpha channel
• ambientColor – ambient color in a vec3
• diffuseColor – diffuse color in a vec3
• specularColor – specular color in a vec3
• shininess – how shiny the surface should appear
• scale – float indicating how deep the surface is
• shadow – if equal to 1.0 the surface self-shadows

As before, these uniform values can be played with in the example to see how they affect the texture.

View demo.

Update 8/22/2011: I have updated the vertex/fragment shaders so they work with rotated/positioned objects. Previous version especially didn’t like rotations. Two additional demos have been added as well to show how the scale/bias can be used to change the texture depth.
Horizontal Plane – showing a stone walkway
Cube Geometry – multi-face geometry

It’s been too long since my last post. I’ve been working on some proof-of-concepts for a couple WebGL projects I have going on. One of those concepts is Parallax Mapping, which transforms a flat plane surface into a 3D projection – kind of hologram style. This method passes memory and processing use from the RAM and CPU onto to the GPU. When dealing with Javascript based games, this is very helpful. You can define a plane with the 4 corner vertices and the graphics card will handle creating the 3D surface. Parallax mapping differs from bump maps by adjusting the texture itself based on the camera’s perspective. Bump mapping applies different lighting based on the perspective, parallax mapping actually shifts the texture’s perspective. The best way to understand what this means is to see it for yourself. In that example move your cursor around the window; the camera will move along with you and the texture will be adjusted based on the new perspective.

The parallax shader is actually quite simple.

Vertex Shader

	uniform vec3 LightSource;
	
	attribute vec4 tangent;

	varying vec2 vUv;
	varying vec3 vPosition;
	
	varying vec3 vNormal;
	varying vec3 vTangent;
	varying vec3 vBinormal;
	
	varying vec3 tsPosition;
	varying vec3 tsCameraPosition;
	varying vec3 tsLightSource;
	
	void main( void ) {
		
		vUv = uv;
		vPosition = position;
		
		gl_Position = projectionMatrix * modelViewMatrix * vec4(vPosition, 1.0);
		
		// Find & normalize the plane's normal, tangent, and binormal vectors
		vNormal = normalize( normal );
		vTangent = normalize( tangent.xyz );
		vBinormal = normalize( cross( vNormal, vTangent ) * tangent.w );
		
		// Convert vertice, camera, and light vector positions into tangent space
		mat3 TBNMatrix = mat3(vTangent, vBinormal, vNormal);
		tsPosition = position * TBNMatrix;
		tsCameraPosition = cameraPosition * TBNMatrix;
		tsLightSource = LightSource * TBNMatrix;
		
	}

Fragment Shader

	uniform sampler2D base; // base texture
	uniform sampler2D map; // normal map in rgb space, heightmap in alpha channel
	
	uniform vec3 ambientColor; // color of ambient light
	uniform vec3 diffuseColor; // color of diffuse lighting
	uniform vec3 specularColor; // color of specular highlights
	uniform float shininess; // how shiny the surface is
	uniform vec2 scaleBias; // x = scale, y = bias
	
	varying vec3 vPosition;
	varying vec2 vUv;
	
	varying vec3 tsPosition;
	varying vec3 tsCameraPosition;
	varying vec3 tsLightSource;
	
	void main()
	{
		// calculate the UV offset
		float height = texture2D(map, vUv).a;
		float v = height * scaleBias.r - scaleBias.g;

		// normalize the camera's tangent space position
		vec3 eye = normalize(tsCameraPosition);

		vec2 newCoords = vUv + (eye.xy * v);
		
		vec3 color = texture2D(base, newCoords).rgb; // default color 
		vec3 normal = texture2D(map, newCoords).rgb * 2.0 - 1.0;
		
		// normalize the other tangent space vectors
		vec3 viewVector = normalize(tsCameraPosition - tsPosition);
		vec3 lightVector = normalize(tsLightSource - tsPosition);
        
		// calculate lighting values
        float nxDir = max(0.0, dot(normal, lightVector));
        vec3 ambient = ambientColor * color;

        float specularPower = 0.0;
        if(nxDir != 0.0)
        {
            vec3 halfVector = normalize(lightVector + viewVector);
			float nxHalf = max(0.0, dot(normal, halfVector));
			specularPower = pow(nxHalf, shininess);
        }
        vec3 specular = specularColor * specularPower;

        gl_FragColor = vec4(ambient + (diffuseColor * nxDir * color) + specular, 1.0);
        
		
	}

There are seven parameters passed in through the uniforms:

• base – the texture
• map – normal map in RGB space, height/bump map in the alpha channel
• ambientColor – ambient color in a vec3
• diffuseColor – diffuse color in a vec3
• specularColor – specular color in a vec3
• shininess – how shiny the surface should appear
• scaleBias – a vec2 where x = scale and y = bias

These uniform values can be played with in the example to see how they affect the texture. That’s how simple it is to incorporate parallax mapping into a WebGL application.

I have seen quite a few people ask how to build there own versions of the three.js library from source. Some of them want to have the latest and greatest code, others want historical versions to compare their code to. There are a number of reasons to have historical versions of a library easily available, and that is what ThreeBuilds aims to do. Builds are available from each three.js tag and the most recent code is rebuilt each night.

Each build tries to include as many of the build configurations as possible, but it wasn’t until recently that some of that functionality was added to the build script. Going forward all builds will include the uncompressed and minified files for each build configuration (All, WebGL, Canvas, etc).