3D Web Games ante portas: Dynamic Light in WebGL and Flash/Molehill

Posted on:July 27 2011

I added a new feature to the 3D editor CopperCube and its free JavaScript 3D engine CopperLicht which should be included in the next update: Dynamic light when publishing as WebGL or Flash application. I expected it to be slow and complicated to implement, but fortunately, everything went fine, see this WebGL demo for yourself:

The renderer now supports 4 dynamic lights at the same time per mesh, which should be enough for most 3D scenes. You will be able to place many more dynamic lights in the editor of course, but the renderer will take only the first 4 nearest lights for every object. If you distribute the lights in your 3D world a bit, you shouldn't even notice this and it should look like your world has many more lights. With this, I think it should be possible to start writing nice looking, half decent games already.

The dynamic light shader code takes about 50 AGAL instructions for a standard solid material shader, which is pretty ok, I think. In WebGL, it only needs 34 lines of code, thanks to the for-loop feature in GLSL. (Which gets unwrapped and extended in asm then anyway, I think).

When implementing this feature, I also worked around a bug in Firefox which leaks memory in its WebGL implementation. After the fix, now Firefox is very fast in this demo: It gets about 100 frames per second while Chrome only has about 40 frames. But still enough to do 3D games, I think. Firefox apparently really now has a pretty impressive JavaScript engine.

Note: What you see in this demo isn't yet available in CopperCube yet, but it will be in the next update. If you would like to get a mail once this new version of CopperCube is released, you can subscribe to the friendly Ambiera Newsletter:
Your email adress:

(will open the ambiera.com website for confirmation)


FYI I get an unlit, completely black scene with just the light flares here.

Chrome 12.0.742.122
Mac OS X 10.6.8

My guess: GLSL issue, the fact that every driver can compile GLSL with different errors was always a challenge.
2011-07-27 11:41:00

Yes, I already had that problem. Happens on Mac OS X, where the Nvidia drivers do something completely different. Going to have a look into that. Thanks for reporting!
2011-07-27 13:12:00

Update: Has been fixed now.
2011-07-27 15:00:00

Hi Niko, love to hear about the lighting! Although I'm a "happy CopperLicht licensee" I'm not using it in all WebGL projects... some need to be done with raw manual WebGL. Can you enlighten us about the following leak issue:

"When implementing this feature, I also worked around a bug in Firefox which leaks memory in its WebGL implementation" -- in cases where we can't use CL, what do we need to be aware of?
Philipp S.
2011-07-27 19:54:00

Firefox seems not to like it when you create lots of buffers using createBuffer(), even when you delete the previous ones. The more you create the slower it gets. In chrome, this is no problem at all.
2011-07-28 07:22:00

So if deleting the buffers didn't help, what's the work-around that did it for you?
2011-07-29 03:04:00

Simply reusing old buffers works :)
2011-07-29 08:39:00

Thought so... a buffer of buffers then :)) awesome. ^^
2011-07-29 14:26:00

Add comment:

Posted by:

Enter the missing letter in: "Internation?l"




Possible Codes

Feature Code
Link [url] www.example.com [/url]
Bold [b]bold text[/b]
Quote [quote]quoted text[/quote]
Code [code]source code[/code]