Hey Everyone -
I want to address a few things as a means of an update on this issue. So, this is going to be a length response, hold on to your hats.
First, when I call it an issue I am referring to the popping in and out of shadows and not the fading out of shadows. Shadows will always fade out at an extreme distance, this has been a function of lighting in the Unreal Engine since UE3 and I do not see it changing until we all have the equivalent of Titan GPUs our higher as a standard in CPUs; and by that I mean it is a performance issue. BUT, before you mass email me with the hate mail, I want to explain how shadows are rendered in the engine so we can all be talking on the same page.
Shadows in UE4 whether Stationary or Movable are rendered on a per object basis and the resolution is derived from the caster’s screen size. The resolution of which is mapped to fade opacity by the two console variables:
r.Shadow.FadeResolution - which says at which shadowmap resolution the fade begins
r.Shadow.MinResolution - which says at what resolution the fade ends
I know we all have had issues with setting these variables and this area is one in which I am still testing to make sure they are working as intended in 4.4.0. However, it is the “derived from the caster’s screen size” that I want to focus on. If your object is, like the cube in our test map, 100 uu x 100 uu(Unreal Units) which is to say 1 m x 1 m in real world dimensions as 1 uu = 1 cm. Now, that box, let’s say fills the camera’s screen at a distance from the camera of 1 m or 100 uu. Obviously in that instance, shadows will render fine as the caster is close to or at 100% of the screen size; our shadows are taking up, let’s say 1000 pixels. However let’s pull our camera back in a straight line to say 100 m or 10,000 uu. The box is still 1 m x 1 m, but now it is taking up only 10% of the screen size, give or take a few % points; our same shadow must now take up only 100 pixels. To grossly over simplify the math done in the engine to derive the shadows, you are multiplying now by .1 and not by 1 (I cannot stress the gross oversimplification of this statement, but the principle stands.)
Lets take this to the extreme though, our same 1 m x 1 m cube with the camera at 1,000,000 uu (I do believe there is a View Limit well below this setting though). So now your cube is taking up only 0.000001 % which means your shadow must be rendered in 0.001 pixels. As we all know, we do not render at anything lower than 1 pixel, so the engine is culling the shadow completely.
In my example, we’ve been dealing with a straight camera move, so essentially a top down scenario, but as most of the people in this thread have been talking about an RTS which has the camera at a isometric angle to the playing space. This means that you are not measuring the straight downward vector for distance, but the hypotenuse vector and this amplifies the problem as now the items further back in the scene (which you would not have in the top down method) are actually further back and take up less screen space then the items in the foreground closer to the camera.
I can hear you all now, “But Eric, doesn’t that mean we cannot do an RTS?” No, it means we have to take advantage of LODs and gamestate changes to allow you to deal with larger items when we zoom out and smaller and more detailed items when zoomed in. You can see this sort of effect in most Sims or Sim City Games. You zoom out to a set distance and then the game will actually change states, will ask you if you want to proceed to city zone or world map. You get the illusion that you are zooming further out, but in fact you are changing to a different map with a different scale in models setup. Its these challenges which make an RTS a difficult game type to create.
Specifically to Neil though, the issue with your CubeBPs where the shadows are culled on a per object basis, there is a flag, checkbox, to force the light to treat as attachment. In the blueprint you will need to parent all the meshes to a base mesh(all cubes under one cube) then make sure that the “Light Attachment as Group” flag is checked true under Lighting in your Base Mesh’s properties. Remember, however, that what every your base mesh is will determine the shadow culling based on distance, so what your base mesh may be important.
In summary, I am still looking into the popping issue, but I feel that the ultimate result of this is going to be a screen size ratio issue with no fix. I am also looking into the use of those 2 console variables to ensure that they are working correctly. The Dynamic Shadow Distance setting appears to be working as intended and the limit you are seeing is based on the size of your object to the distance from the camera (with the exception of the popping in and out which is something, as I said, I am looking into.)
Thank You
Eric Ketchum
