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…
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:
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.
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?
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?
I feel with you. I have spend the past two years intensively learning UE4 to be able to publish my own games and (digital) art projects, not to mention spend a lot of money on the marketplace. And now it feels all of this was wasted because suddenly it seems Epic doesn’t give a **** anymore and I can’t be certain that I can rely on UE4 later on.
Honestly I will finish my current project, hope it will give me some return and then switch to Lumberyard, since Amazon is pouring a **** ton of resources into it, and they don’t do such a thing without a longterm goal.
Before choosing UE4 I have given Lumberyard a shot and I didn’t like it. More than two years later I am not seeing much progress there and maybe because Im not there at all, but I know what progress we are having here and the space it still has to grow here, so shifting is a no no for me. The feeling for the known are much better of the feeling for the unknown…
Yep. No doubt, one way or another SampleCmp is better than Gather plus two vector instructions. Might be even more significant on mobile, but I’m not familiar with mobile shading.
Slope scaled bias would have eliminated the need for that soft comparison thingy, which does not seem to do the job it was intended to do, apart from transitions.
Speaking of soft comparison, the way it works now, it has a linear dependency curve on shadow distance. In reality, one would almost always desire to have exponential curve, that relates shadow cascade number and bias. That is another thing, why having Slope Bias and Bias controls adjustable for each cascade individually would be a one size fits all solution.
Additional thing it might be worth implementing, is ability to adjust filter size depending on the cascade, again with full manual control. This would situationally boost performance as well as eliminate another issue, that some users were complaining, namely over-blurred shadows in the distance. It would be cool, but it tags along some complications with cascade snapping and i’m unaware of reliable methods for handling cascades borders in this case. At least not with a box filter. But IMO, this topic is worth looking into.
Just found another problem that contributes this problem. When Gather4 isn’t used code is calling function. FetchRowOfThree() this always offset towards positive x coords. Calling code always use positive offsets. This Shifts shadows 1-2 texels(on both axis) depending if pcf2 or 3 is used.
Forum still broken. Two-Factor authentification still not implemented (I have to delete my credit card data each time after making a purchase). Sharp decline in responses from Epic. Marketplace-quality control non-existant. Oh and how about a good dynamic lighting solution? yeah no…
And yes, if you keep ignoring a thread where a ton of different users describe how negatively such a problem is impacting their projects, and there is ZERO response from Epic, then I think it is safe to say that they don’t give a **** about this.
I’m not saying they don’t care about the engine or community in general, but it’s clear there is a decline and it makes me sad to see this.
The calling code adds offsets to FetchRowOfFour call, so it does not use only positive offsets.
For 4x4 filter, the sample center is offset is offset by (-1,-1). It matches gather code.
for 7x7 filter, the sample center is offset by (-3,-3), It is half a texel off the gather code.
I don’t see more than half a texel shift anywhere.
Yeah you are right. I tested code a bit and noticed that original and my offset version(-1, 0, 1) was both half texel offsetted. Proper fix was to remove - 0.5f bias and use my offsets.
float2 TexelPos = ShadowPosition * Settings.ShadowBufferSize.xy - 0.5f; // bias to be consistent with texture filtering hardware
