Hi,
I think that it’s time to show our project here and gather all media we recently post here in various topics. And to show something new.
// Link to our latest video //
Our old video:
And some screens…
Doors: 
Latest version of our gui: 
Red light: 
Dark corner: 
Some shadows: 
More shadows: 
Soon we will show a new video.
Very nice, all the best!
I like the look you are going with for navigation. The GUI layout looks to be good, as well.
the click buttons might not be necessary if you have an intuitive “WASD+QE” keyboard control, or even if you zone the screen correctly for mouse drags n clicks to navigate.
Other than that, I can tell you are going into the dungeon with a party, a shared inventory, and possibly a map.
Good calls. 
Ofc we have WASD and QE keys mapped.
This looks very nice, I love the art style and oldschool dungeon crawlng mechanics.
Keep us updated, I am very excited how the gameplay part will become.
Pretty cool!
Since we are working on some internal things, there are no new things to show, so I put here a scene with invalid camera position, caused by the bug 
Btw, we switched from png/jpg to dds and did few tricks to completly remove the initial ‘lag’. Now the game starts to render just after the models are loaded.
This particular light uses only one shadow camera. Customized light position and small modification of the shader provides light on every wall in the hole. Of course the light will not bleed out into nearest hole, if there is any.
We find that using many lights causes performance issues, actually I’m not able to handle that, but we have some ‘safe value’, we can keep an decent fps with about 3 lights.
I’m also surprised that there is no visible difference in performace between one-shadow-cam light and the standard 6-shadow-cam light. Why?
Well…there are so many reasons that it could happen. It depends a lot on the scene, on the light position, how many objects are in its range, on where your bottleneck is (CPU, GPU), etc…
So, reducing shadowcams gives performace boost only if that particular, removed shadowcams generates much more shadowy pixels than normal ones?
Ok, here we go:
Every torch have 6 shadow cams but only 5 are used in complex shadowing, the sixth one (the cam index depends on wall’s direction) is almost unused. Its shadowmap lights up a small rectangle and covers in shadow the rest of the scene (behind the wall).
So, lets disable rendering of particular shadowmap and dont send it to shader. Inside shader lets check if the shadowmap is present: Example, modified Shadows.glsllib:
#ifdef SHADOWMAP3
shadow = GETSHADOW(shadowMap3, projCoord3 / projCoord3.w);
#else
shadow = -1.0;
#endif
Inside fragment shader:
#if !defined(SHADOWMAP0) || !defined(SHADOWMAP1) || !defined(SHADOWMAP2) || !defined(SHADOWMAP3) || !defined(SHADOWMAP4) || !defined(SHADOWMAP5)
if (shadow == -1.0)
{
if (dist < 0.5)
{
shadow = 1.0;
}
else discard;
}
#endif
This one gives me about 4 more fps in the scene with 4 lights.
Note: “4 more fps”… “more fps” is not a unit of measure but especially without a basis. For example, if you only had 2 FPS before then getting “4 more” would be spectacular.
You can see the average amount of fps on every screen. In this case it was 46 to 50fps.
Well the shadow cams for a point light does frustum culling, so in many case I guess that you only have the wall geometry in the 6th cam frustum. So by removing it, you just save 1 draw call. Which is nice…but not fantastic in term of fps gain.
In 6th cam frustum I have wall geometry and some things behind that wall. Geometries of walls, floor etc are batched together (5x5 map squares) so I have less objects on list.
I was trying to cut that 6th cam’s far frustum but in most cases it not helps (because of geometries batch). And I found that (at least in my case) an alternative way for getReceivers is a bit faster, so I replaced
ShadowUtil.getGeometriesInLightRadius(sceneReceivers, _shadowCams, lightReceivers);
with
BoundingVolume bv = null;
for (int i = 0; i < inputGeometryList.size(); i++)
{
Geometry g = inputGeometryList.get(i);
bv = g.getWorldBound();
if (bv.distanceTo(light.getPosition()) < light.getRadius())
{
outputGeometryList.add(g);
continue;
}
if (bv.distanceToEdge(light.getPosition()) < light.getRadius())
{
outputGeometryList.add(g);
}
}
In the above screen you can see what part of the dungeon is lightened up if there is no shadowmap on 6th cam and the (dist < 0.5) condition is removed. It also represents how many pixels are checked for shadow (heavy Shadow_DoPCFPoisson function) when everything goes its normal way.
Of course I’ll try to optimize everything much more, but for now I don’t have any idea where to start my next attempt.
In 3.1 we now have a reliable way to render several lights in one pass. That can be a huge perf boost on some scenes.
But you’d have to make it work with your shadows processing that attenuate shadows when they are in another light influence area.
We’re seriously thinking about the best way to implement this in stock shaders.
How to test if camera1’s frustum overlaps camera2’s frustum in most fast and elegant way?
Since I have good solution to disable shadowmap rendering for any shadowcam it may be a good idea to use it for next customization.
What I want to do? For example, if there is a torch behind my back I only see the effect of 1-4 shadowmaps (it depends on the distance and angle). I want to test it’s every shadowcam and if it not generates any visible shadow nor light - i want to disable it. Remember that I’m in a dungeon made of large batched blocks so it is very likely that the camera see at least one geometry - the dungeon block.
EDIT:
So far i have a bit complex algorithm to test if the particular light should be visible. First I’m testing if it (including its light range) is in player’s camera angle (casting everything to 2d - dungeons are flat). After that I’m using Bresenham’s algorithm (that one for drawing lines) to check if the light source and/or any lightened square is visible or behind a wall. It works great, so the above trick with shadow cams is the obvious next step.
As far as I rmember @pspeed is a math guy. Would you please help me with some calculations?
Heaven help us all… there are some guys I used to work with who would be laughing pretty hard at that. 
I guess I got to sit at the big table long enough that I learned some things…
I wasn’t exactly sure what you needed my help with, though.
I came here for help and not just to be ridiculed …
Ok, forget that I asked for.
??? I wasn’t ridiculing you. I’m, in fact, not very good at math… I just know a few tricks. But I worked with some guys who were legitimately good at math. (one solved math theorems as his hobby… notebooks full of the stuff).
I’m willing to help… I just don’t know what exactly you need help with.