Dynamic shadows artifacts

[Chosker]

wait, no. just because we've waited months/years and haven't even had a response, would make this issue any more acceptable if they would just come over and say "we wont fix it'.
the issue is real, it's jarring, it screams low quality, and there isn't even an acceptable workaround. so please guys, don't let the lack of acknowledgement of the problem block you from the actual problem

[Kalle_H]

I know it's ugly but it's not a show stopper for gamers. Fortnite use these ugly shadows and I have never heard any of the players(from +50millions) to complain about it.

[William K]

I know it's ugly but it's not a show stopper for gamers. Fortnite use these ugly shadows and I have never heard any of the players(from +50millions) to complain about it.

Well just because its no show stopper doesn't mean its not a big deal. I wouldn't consider Fortnite or even Paragon or even any other MMO as a good example of having bad shadows or visual artifacts not stopping a game, in fact these are the type of games that anyone cares the least about the visuals in the first place. You can give them a 90's model and they could care less I mean just look at player unknown it looks so average and at times way below average yet no one cares! All they care about is the multiplayer aspect of it.

What if you have a narrative based character and visual driven mood lit game (Like Epic advertises UE is the best choice for)? What's anyone's excuse when these artifacts start making your 150K + detailed hero character model which took 2 month to rig another month to model shade and texture, and yet another 6 months to animate and cost $$$$$$ turn up to have faceted polygons staring at your face through a 4K TV? From the body, clothing to the face that kills the expectations that you had of all the work you put in. Now consider the other whole set of problems in UE that you have to deal with: lighting, cascades, shadows, lack of realtime GI or equivalent, ancient and slow light baking engine, issues with the type of temporal AA implementation etc.. and add this one on top to start breaking the camel's back, I am not surprised why people can be upset about it including us.

It's not that these problems exist it's the lack of feedback on them and priority onto other areas (ehem VR) , that gets people going. But again UE is not my company, but then gain they do get roughly 10% of a game's cut. Maybe they do aught to pay some attention and prioritize these issues over others that can certainly wait perhaps?

[Maximum-Dev]

I know it's ugly but it's not a show stopper for gamers. Fortnite use these ugly shadows and I have never heard any of the players(from +50millions) to complain about it.

For Epic and Fortnite players it might not be a big deal if shadows look like 2004 quality. But some other developers that develop high end realistic games it does matter and their audience will also get disappointed if such issue exists i.e imagine playing Crysis 3 with Psycho's bare head looking as blocky as spheres do in UE4. It breaks the immersion.

[BrUnO XaVIeR]

There is always Lumberyard or Unity

https://aws.amazon.com/lumberyard/

Just thinking of working without Persona and without Animation Blueprints already make me wanna cry...
I study those other engines, compared to Unreal they "have no tools" :[

[William K]

they

Just thinking of working without Persona and without Animation Blueprints already make me wanna cry...
I study those other engines, compared to Unreal they "have no tools" :[

are improving a lot, give them another year or so, things are going to get really really hot.

[DamirH]

wait, no. just because we've waited months/years and haven't even had a response, would make this issue any more acceptable if they would just come over and say "we wont fix it'.
the issue is real, it's jarring, it screams low quality, and there isn't even an acceptable workaround. so please guys, don't let the lack of acknowledgement of the problem block you from the actual problem

Personally I am more shocked by the lack of any communication because as I said, my existence hinges on UE4 and the handling of this issue really points at much bigger infrastructure issues that outweigh a single graphical bug.

[IronicParadox]

It's really not as big of a deal as people are making it out to be. Yeah, under some lighting conditions+bland pale material+certain viewing angles, you'll get some horrible faceting, but it's not the end of the world. I'm sure they will get around to fixing it some day, but I have a strong feeling that it's going to involve making frame times ~15-30% slower to handle the filtering. So ask yourself this: is the cost worth the minor change in fidelity that consumers don't seem to be complaining about?

[NilsonLima]

It's really not as big of a deal as people are making it out to be. Yeah, under some lighting conditions+bland pale material+certain viewing angles, you'll get some horrible faceting, but it's not the end of the world. I'm sure they will get around to fixing it some day, but I have a strong feeling that it's going to involve making frame times ~15-30% slower to handle the filtering. So ask yourself this: is the cost worth the minor change in fidelity that consumers don't seem to be complaining about?

Since Unreal is moving each day to be real-time rendering engine for movie production, it is expected at least the option to turn the filtering ON and OFF, at least while GPUs are not the dream of being 200% faster than they are today.

[Deathrey]

I'm sure they will get around to fixing it some day, but I have a strong feeling that it's going to involve making frame times ~15-30% slower to handle the filtering. So ask yourself this: is the cost worth the minor change in fidelity that consumers don't seem to be complaining about?

A shot in the dark without having a clue and completely unrelated, random numbers, taken off the wall yet again?

Personally I am more shocked by the lack of any communication because as I said, my existence hinges on UE4 and the handling of this issue really points at much bigger infrastructure issues that outweigh a single graphical bug.

Frankly, I don't think that any communications are necessary here. The problem exists. The cause is known. Denying it is pointless. Not having a single doubt, that relevant personel is aware of that and reading the thread.

As for priority of dealing with things, this does not look like the most urgent one, but it kinda has been here for a while, along with requests to support baking physical surface ID from landscape material and texture arrays/3d textures. The issue surely deteriorates visual quality, but not even nearly to consider it a major flaw.

I'd like to say, that there are few other shadow - related things, that I would warmly welcome in stock UE4, such as having a choice between several shadow filtering methods, like it used to be in UDK. There are still users, who would prefer rotated disk filter over box one and the reason why it was left out in stock UE4 is somewhat unclear to me.

[IronicParadox]

A shot in the dark without having a clue and completely unrelated, random numbers, taken off the wall yet again?

No, it actually has some basis to it. Obviously, there is going to be a HUGE variance in shadow frame times, from scene to scene, but from what I've seen, shadowdepths+shadowedlights can run you around 25% of the frame time in a dynamically lit scene(at least in some of my forest heavy scenes that I've been working on and with the hardware I'm using right now). Now it's hard to profile it specifically, but I'd assume that shadow filtering takes up a lot of the shadow frame time; due to the sampling techniques that have to be performed.

Using my example, let's say you've got a frame time of 16ms, that would mean 4ms would be eaten up by shadowing. If you increase the filtering math and it bumps up the shadow frame cost by let's say 2x, due to more sampling math and a wider kernel, you'll see frame time increases of +4ms, which would equate to ((20-16)/16)*100=25% increase in overall frame time...

[Deathrey]

Now it's hard to profile it specifically, but I'd assume that shadow filtering takes up a lot of the shadow frame time;

No, it is not hard at all. There is a dedicated entry in built-in profiler for that, which you are unaware of, leading you to:

but I'd assume that shadow filtering takes up a lot of the shadow frame time

assumptions, like that one, based on random myths. That is a wrong one, in any case.
Filtering part, as a rule, takes less time, than depth rendering.

If you increase the filtering math and it bumps up the shadow frame cost by let's say 2x, due to more sampling math and a wider kernel, you'll see frame time increases of +4ms

Which part exactly of the so-called filtering math are you intending to increase, that would result in 4ms shadow filtering rendering time inflation, while addressing the issue discussed and what part would a wider kernel play in it?

[Kalle-H]

With proper slope scaled depth bias filtering could be cheaper than it's now. Filtering also could be optimized by using hardware bilinear comparision sampler where it is possible. Currently every sample is separately doing soft comparision.
Related code.

        // The standard comparison is SceneDepth < ShadowmapDepth
        // Using a soft transition based on depth difference
        // Offsets shadows a bit but reduces self shadowing artifacts considerably
        float TransitionScale = Settings.TransitionScale; //SoftTransitionScale.z;
        float ShadowFactor = saturate((ShadowmapDepth - Settings.SceneDepth) * TransitionScale + 1);

[Deathrey]

With proper slope scaled depth bias filtering could be cheaper than it's now. Filtering also could be optimized by using hardware bilinear comparision sampler where it is possible. Currently every sample is separately doing soft comparision.
Related code.

// The standard comparison is SceneDepth < ShadowmapDepth
// Using a soft transition based on depth difference
// Offsets shadows a bit but reduces self shadowing artifacts considerably
float TransitionScale = Settings.TransitionScale; //SoftTransitionScale.z;
float ShadowFactor = saturate((ShadowmapDepth - Settings.SceneDepth) * TransitionScale + 1);

I'd tend to agree here. It is just that the actual performance gain is hardly measurable. This is mostly due to the fact that large part of 4 in 1 comparison gain is the actual 4 in 1 texture fetch, which is already used. It boils down to 1 MAD and 1 SUB instructions less minus cost of hardware comparison per 4 samples, which is... well.. not much these days, but still something.

But following the same logic, I'd say that ditching whole TransitionScale, and letting user tweak the depth bias per-cascade(not a replacement for slope-scaled bias, just alternative approach to the goals, that are set for existing system) would be good alternative, don't you think?

[Kalle-H]

I'd tend to agree here. It is just that the actual performance gain is hardly measurable. This is mostly due to the fact that large part of 4 in 1 comparison gain is the actual 4 in 1 texture fetch, which is already used. It boils down to 1 MAD and 1 SUB instructions less minus cost of hardware comparison per 4 samples, which is... well.. not much these days, but still something.

But following the same logic, I'd say that ditching whole TransitionScale, and letting user tweak the depth bias per-cascade(not a replacement for slope-scaled bias, just alternative approach to the goals, that are set for existing system) would be good alternative, don't you think?

Yeah sample Gather is used SM5 platforms but not on mobile. IOS supports: sample_compare(), gather() and gather_compare() fetches.