Hi,
I noticed that you said something about being careful with light because they are so expensive. I suggest you try to implement deferred lighting and/or rendering to eliminate excessive draw calls. I was working on something similar to this at work. Our entire system was based on deferred rendering. This makes it possible to have many multiple lights because there are no draw calls until the last rendering stage.
Hi @Brian_Perry.
Thank you for suggesting. We do actually look at deferred rendering direction, but so far there are major restrictions within WebGL world, that stops us from taking that direction, biggest is: support of certain extensions. They are not available everywhere, and there is no efficient fall-back for those. Which will lead to pretty big chunk of older devices not able to keep up with performance, as deferred rendering even will full on support will have some overhead on simple scenes against forward renderer, which for mobile is very noticeable straight away.
Deferred Renderer pays off only on scenes with complex lighting.
So with good support around, we definitely will go for it.
This still does not improve cost associated with real-time shadow maps.
It will only improve complexity of lights (without shadows) we can create in scenes, simplifying complexity of shader will improve loading (shader compilations) times, and will allow more dynamically manipulate lights in scene without shader recompilations (it freezes!).
But as mentioned already, it is unfortunately not possible today if we want to keep supporting all devices that handle WebGL. And for us it is very important to be able to render anything on even the worst devices, as far as they handle WebGL.