Explosions will be per pixel, sorry I wasn't clear. Fog of war will remain texture based, it's rather a gameplay feature than a visual one.
I've mostly finished working on it, it's not ready for usage (I didn't add safety check in shader for buffer bounds so gpu often crashes) but I can détails the implementation :
At first this will concern terrains and terrain decals only. The light positions are passed via uniforms and at the moment uniforms are rebound for every non terrain object ; while it's fine to pass a couple of matrixes for every object light positions do represent 128 vec2+ up to 64 vec3 (color and position) + up to 32 float(range) which is unpractical if there is a lot of units (and unit are composed of 4 objects) on screen. It's possible to bind them only once but I need to tune the API. On the other hand uniforms terrain binding happens only ~10 times per frame.
About the implementation : I'm using a "clustered" renderer : the view frustrum is splitted in 16x8 clusters. Then for every light, light bounding box is transformed according to the view transform and tested against cluster coverage. For every cluster covered, light position color and range is added to a per cluster array. All of this happens on cpu.
The cluster arrays and their size is send as uniform to shader. In shader fragments check in which cluster they belong and iterate on the corresponding vector.
This approach is close to the one used in Doom (2016) and detailed in their publication for Siggraph 2016 : http://advances.realtimerendering.com/s2016/
Since lights computation happens per cluster instead of whole frame this reduce the per light cost. There's only a single z slice since wz2100 is an rts and mostly use a top down view.
The light équations are taken from "Frostbite going PBR" paper http://www.frostbite.com/2014/11/moving ... te-to-pbr/
There are 2 components in light reflection, diffuse and specular. The specular component uses the GGX equation (units currently uses blinn phong) while diffuse uses Burley's equation (a small tweak over the classic lambert equation that acount for energy conservation).
The GGX equation has a roughness input that doesn't exist in wz2100 atm, I'm using 1.0 as a default value. Future development could make possible to pass a texture (as well a normal map) which may greatly improve terrains visual.
PBR model is not completly implementing though, it lacks a tonemap step, a metalness input (which can be again passed as a texture) and cubemap probes for environment reflection. This will likely happen later.
Since PBR is now mainstream (it's the one implemented in Frostbite, Unreal Engine 4, Source 2, and internal Overwatch engine), using it as a base makes sense in my opinion.