it is really prevalent on finalized assets and scenes in our project at work (can’t show anything atm tho)
I think PCSS will be just a high-end feature as shadows are already expensive on their own (i.e. wouldn’t solve the problem on mid/low-end PC’s), and if anything I think it would only solve the issue at very close range (I don’t expect PCSS to be usable at all distance ranges on full-scene Cascaded Shadows)
I think it’s better you guys post on the report instead of the thread.
Report: Blocky shadowing - AnswerHub - Unreal Engine Forums
Does anyone from epic actually look at stuff on the answerhub that’s not under “bug reports”? It doesn’t seem like they do.
They do, I got many answers this way. But…
Once my friend-artist posted issue. No answer at all.
After 2 weeks I posted the same bug report, but I described it like programmer. Got answer the same day 
But wait… isn’t this like bug? Does look like new feature to implement, just malfunction
It depends on your definition. It’s not a bug in the usual way, as the problem is the lack of a feature - normal offset or slope bias
However every other engine from the last decade has this, so it’s absence could be seen as a bug.
you could say it’s not a bug if the implementation is working as intended.
however you could say it’s a bug if it’s a regression (people have mentioned that this issue first appeared in some release, i.e. it wasn’t noticed in earlier versions of the engine, though it’s not clear when).
you could also say it’s a bug if the result is not acceptable in this day and age, from an engine with quality standards such as UE4’s (which is advertised as “the most powerful creation engine”, “photoreal rendering in real-time”, etc) 
It’s not a regression, as the feature never existed in ue4. People are just starting to expect high enough shadow quality to notice it.
You can hide the problem by globally increasing shadow bias, but then it looks like everything is floating instead and you get much less detail.
You BRUTAL fan!
This was always an expectation! Like you know, some threads regarding this date back to 2015 and older! 
Edit: If Epic decided to fix the issue, I think implementing an interface like this for tweaking all the values will be very handy.
Yeah but for some reason they were happy when told to just increase the bias until it goes away. Clearly that doesn’t fly in 2017!
Not relevant to shadowing problem in particular, but I’d join you in welcoming being able to adjust such settings for each cascade individually.
Crysis 2 had dynamic shadow penumbras as a feature back in 2011. There is no gaming rig on earth anymore that shouldn’t be able to run it, if optimized well.
Depends on how do you treat the term bug.
Pretty sure, that blocky shadowing can’t be described as “intended behaviour”.
the feature never existed in UE3 either and yet the shadow acne issues were acceptable, in a state comparable to other engines (which isn’t the case here)
Shadowmaps were introduced in 1978 and Cascaded Shadowmaps were introduced in 2007. That doesn’t mean that in 2017 you can in UE4 make a big scene with fully dynamic lights using CSM with Skylight + DFAO, and then dance happily about the performance.
My point being that adding more features that have ‘some’ cost (i.e. PCSS, contact shadows, POM or tessellation, to name a few) on top of other features that already have a fair cost, isn’t exactly going to be forgiving with performance
Actually in 2017 you should be able to make big scenes with fully dynamic lighting, dynamic GI, large scale AO, soft shadows, POM, Tessellation, Volumetric lighting, volumetric fog, volumetric clouds etc. and happily dance while looking at something beyond 60 frames on mid range hardware. Most of these features were in other engines way before 2017 as well.
Edit: The performance problems with UE4 mostly is because nobody really knows why things run so slow, you look at the code and it’s flawless, you compare the same feature with other engine it’s probably 3 times heavier. But since the code looks flawless that performance difference is accepted without question.
Like the tessellation problem, it’s been around since UE4’s existence and still engineers don’t really know why ~4000 tris would cost around at least 5ms to render. While in other engine like frostbite’s battlefront even the rocks and trees are tessellated, let alone the landscape.
Yeah… well, fortunately or unfortunately, not everyone submitting bug report/feature request is a coder.
Every single feature you just listed was in Crysis 2. Crytek did -exactly- what you’re describing 6 years ago in fully dynamic scenes and got 60 fps performance on high end hardware of the day. The UE4’s -minimum- recommended requirements exceed what Crysis 2 needed for its highest settings to get all of those fancy effects at 60 fps.
I’m not denying that there’s a cost to these features, I’m not even saying that it’s easy getting it running this well, all I’m saying is that historically, it’s been done before. It’s a solved problem, and has been for 6 years. Even mid range gaming hardware today is faster than the GTX 480 that game needed.
we’re both hinting at the same thing: Unreal’s graphics not being optimized enough. however I don’t think Crysis 2 had DFAO, which is also costly in UE4.
but I’m just saying that adding more features on top will just make it slower, and as such will only be considered “high end” - even though as you say, it was “high end” 6 years ago which nowadays should be “mid range”
DFAO is new, yes. I may be wrong, but if the UE4 wasn’t the first engine to have it, it was certainly the first I’ve heard of it. It’s an amazing system for ambient occlusion, I’m glad it exists.
And just to make one thing completely clear, myself and I’m sure Maximum-Dev are on the same page when I say we left using the CryENGINE for a reason. Unreal’s actual tools are superior in almost every way to what the CryENGINE had, I even remember a release where the resource compiler to import assets was broken completely. We don’t, or at least I don’t, always bring it up to put Unreal down, but to show that the most common problems people have with the engine are possible to solve. Fully dynamic scenes don’t -need- to be the performance killer it currently is on even top of the line hardware. Tessellation and POM don’t -need- to be features you only use as a last resort. Dynamic shadow penumbras don’t -need- to be a high end feature only.
Even a GTX 950, the lowest end desktop video card of that series, beats a GTX 480 in performance, it’s completely outclassed in every way. It isn’t even “mid range” anymore, it’s bottom of the barrel.
These ‘high end’ features need a serious look from Epic on their performance. Things like dynamic shadows are so heavy that part of me actually suspects a second pass to put PCSS support in them will somehow lead to them getting faster just from finding something slowing it down.
I sincerely hope that things start to get better. Every single person using the engine will only benefit from it.
Frankly, I do not understand objective reason for dropping out SlopeScaledDepth bias. It was primary designed to overcome this kind of artifacts. Changing it surely requires additional rasterizer state change, but I refuse to believe not doing it is worth the visual regression. I would be happy just to know the reasoning behind it for I might be overlooking something.
