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)





Comments:


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
NVIDIA GT 330M

My guess: GLSL issue, the fact that every driver can compile GLSL with different errors was always a challenge.
steve
Quote
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!
niko
Quote
2011-07-27 13:12:00


Update: Has been fixed now.
niko
Quote
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.
Quote
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.
niko
Quote
2011-07-28 07:22:00


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


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


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


Add comment:


Posted by:


Enter the missing letter in: "Inter?ational"


Text:

 

  

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]

Emoticons