Category Archives: WebGL

Material Viewer

For a while now I’ve wanted to write a simple editor/viewer to show simple, basic interaction between light and materials (based in no small part to this web page,

I also noticed that even simple default scenes rendered very differently with Three.js, Babylon.js and PlayCanvas engine (referred to as PlayCanvas.js from hereafter). So once I started, I got the idea that it would be interesting to compare how different libraries rendered lights and materials. This would give me an opportunity to learn, compare and contrast each, as well as (hopefully) learn and apply some new ES6 features.

Use cases
 1. Investigate material properties
 2. Investigate light properties
 3. Show and compare how different renderers implement lighting

Light Properties
The following light types are supported:
 ● ambient
 ● spot
 ● point
 ● directional
 ● hemi-sphere ¹
¹ Babylon.js only

Material Properties
The following material properties are supported:
 ● ambient ²
 ● diffuse
 ● specular
 ● emissive
² Not Three.js, the ambient colour interacts directly with the diffuse material

I like dat-gui, but I’ve wanted a floating control for a long time, after several abortive attempts at writing my own (I just got bored dealing with all the fiddly bits) I finally found an old but working solution that resizes to its content. There were a couple of bugs but they were readily sorted
(e.g. dat-gui hangs over the bottom of a containing div but this was easily dealt with by adding a bottom border).

Still, I’m unhappy with both DraggableLayer and dat-gui. DraggableLayer will only work with one element, and dat-gui has limited input options (e.g. no vector entry) and colour selection can be fiddly.

Renderer Controllers
In “JavaScript: the Good Parts” Crockford eschews the use of new, using constructor functions instead. I try to follow suit with makeXXX functions. All the renderer specific code is localised to a single file, although this is rather spoiled by the matching <script> tag polluting the global space.

Each renderer has the same interface and hides any workarounds (e.g. each renderer implements ambient lighting differently). Adding a new renderer should be straightforward.

Three.js and Babylon.js were generally easy to code for, but PlayCanvas.js kept throwing up little issues and I found it’s syntax less intuitive.

PlayCanvas.js problems
PlayCanvas uses degrees rather than radians. While more an idiosyncrasy than a problem, it necessitates conversion between radians and degrees.

Despite providing a torus primitive in the editor (along with a capsule) there is no equivalent addComponent method. Using the createXXX method requires additional code to add it to the render list, etc. and maintain it. However, there was work round — generating an arbitrary mesh then replacing it with a “created” meshInstance.

var mesh1 = new pc.Entity('cube');
mesh1.addComponent('model', {
  type: 'box'
var node = new pc.GraphNode();
var mesh = geometryTypes[type](app.graphicsDevice, geometryDefaults[type]);
var material = new pc.StandardMaterial();
var meshInstance = new pc.MeshInstance(mesh1.model.meshInstances[0].node, mesh, material);
mesh1.model.meshInstances = [meshInstance];
material.fresnelModel = pc.FRESNEL_NONE;
material.shadingModel = pc.SPECULAR_PHONG;
mesh1.model.material = material;

To get the ambient material setting working required fiddling around with material properties. The default material is physical which needed to be switched to Phong (not a single switch but setting a couple of properties, see lines 18-19 above).

The createCylinder method had a bug and used opts.baseRadius rather than correct opts.radius. I actually raised a PR to fix this (yipee!).

I still can’t figure out how to set the rotation of the orbit camera correctly, I suspect it may be related to rounding errors when converting between degrees and radians.

After some initial work in my mega-repo, I split it off into it’s own — always fun. It can be found here and the live version here and mirrored here.

Future work
Sort out the camera rotation bug in PlayCanvas (der).

Either find better UI libraries that support draggable elements and more input types or D-I-Y my own.

Use glTF as the interchange format rather than my own. However, there may be some unique settings that aren’t supported. Further investigation is needed.

Add more light types — directional, spot, etc.
Add light parameters — position, fall off, penumbra, etc.
Add interactive control — click ‘n’ drag
More advanced lighting/shading/materials (AO, PBM)

Pop up info/help

Add/delete models
Import models

Down the rabbit hole with FBX


PlayCanvas does an admirable job of importing FBX models and animations, but animation control seems limited. In particular, there seem to be no events for animation start, end, etc.

Animated Sackboy

This immediately prompted me to stop and reassess all my requirements (and not just animation).


  1. I felt that I would almost certainly need more control over animation events than PlayCanvas provides.
  2. PlayCanvas only has version control (very important) for legacy scripts.
  3. A fall back is needed if PlayCanvas fails for some reason (e.g. it’s cloud based, so poor internet or even just high contention would be problematic).

Using an API would immediately address issues 2 and 3. This leaves FBX support as the main issue.

It’s apparent that game creation requires a smooth workflow. Easily getting assets into the game is very important, regardless of their source. Be it pre-existing from a store or newly created by an on-site 3D artist, assets have to come from somewhere, and FBX is one of the more common formats particularly for animation. FBX support is very important.

Checking out the main alternatives:


Babylon.js doesn’t support FBX directly. I was advised to use the Babylon exporter for Unity or Blender. Alas, the results were not impressive.

Source model (Pearl.fbx) as should be

Model after exporting to Babylon (from Unity and Blender) has an “export to Babylon” option, unfortunately its own FBX import is lacking, and I’m still trying to work out how to add animation to a model.

Model after import into


Three.js currently only supports ASCII FBX not binary (Takahiro is doing some sterling work to add binary FBX).

Current state of FBX import to Three.js (not released yet)

So, it may be a contender if support is available in time, but for now it’s back to PlayCanvas.

Conclusion (if you can call it that)

Converting 3D assets seems inevitable, to reduce file size and minimise load time (even PlayCanvas converts FBX to JSON).

I will look into FBX – glTF or JSON converters, but for now I’m returning to PlayCanvas (in fact, PlayCanvas engine is also available, so it’s its own fallback).

Choosing a framework/engine

Naturally, I want to work on a WebGL based game. This automatically makes it web based with all the attendant benefits and disadvantages.

My first choice is PlayCanvas (free version), which is like a (simplified) on-line Unity. The only alternative that I know of, GooCreate, sadly declared bankruptcy a few months ago.


  • on-line editor (drag ‘n’ drop)
  • six years old (so relatively mature and stable)
  • support is through forums for free accounts
  • FBX support
  • collaboration


  • no download for off line storage
  • no version control
  • limited animation control

Develop Game Jam

I’ll be attending this year’s (2017) Develop Game Jam in July.

I usually just ruck up on the day and use the opportunity to learn a bit about some game development technology or techniques.

While fun and educational, this is not the ideal way to compete. Frequently, I achieve little by way of a final result.

This year, I thought I’d actually do some real preparation and take a real stab at completing a “proper” game.

I plan to use WebGL (naturally), so I’m focusing on PlayCanvas, along with Three.js and Babylon.js as possible fall backs.

If things really go pear shaped there’s always Unity (or possibly Unreal or CryEngine).

I intend to blog the process for reference purposes and I’ll add links to blog/articles as I progress.

Develop 2017 Game Jam Preparation

OK, so, the Develop 2017 game jam “looms” and this time around I thought I’d do some prep to give me a chance at finishing a game. (At past jams I’ve been up against some seriously talent jammers, while I try to not be competitive I do feel I should try harder.)

Past experience has shown me that using tools is enlightening – highlighting possible problems and their solutions ahead of time, so reducing friction development during the jam. Something that this exercise has reminded me of.

I want to work on a WebGL based game. This automatically makes it web based with all the attendant benefits and disadvantages.