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:
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:
Comments:
steve
Quote2011-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
Quote2011-07-27 13:12:00
Update: Has been fixed now.
niko
Quote2011-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?
"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.
Quote2011-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
Quote2011-07-28 07:22:00
So if deleting the buffers didn't help, what's the work-around that did it for you?
Phil
Quote2011-07-29 03:04:00
Simply reusing old buffers works :)
niko
Quote2011-07-29 08:39:00
Thought so... a buffer of buffers then :)) awesome. ^^
Phil
Quote2011-07-29 14:26:00
Add comment:
|
|
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
 |  |  |  |  |  |  |  |
 |  |  |  |  |
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.