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).
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:
eight comments, already:
FYI I get an unlit, completely black scene with just the light flares here.
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 () (link) - 27 07 11 - 11:41
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 - 27 07 11 - 13:12
Update: Has been fixed now.
niko - 27 07 11 - 15: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. () - 27 07 11 - 19:54
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 - 28 07 11 - 07:22
So if deleting the buffers didn’t help, what’s the work-around that did it for you?
Phil () - 29 07 11 - 03:04
Simply reusing old buffers works :)
niko - 29 07 11 - 08:39
Thought so… a buffer of buffers then :)) awesome.
Phil - 29 07 11 - 14:26