I think this is the same bug like here: Flickering Distance field shadows on ATI video cards - AnswerHub - Unreal Engine Forums
I also see flickering distance fields. I use the AMD 15.11 driver, so the old bug should be fixed. This is what I see:
It only seems to happen on ISMCs though, and it gets worse the further the camera is away from the mesh. In that gif you see a bunch of stones, just one ISMC with a few hundreds instances. And since the distance field has extreme flickering, you can imagine how the shadows look like
Hi John -
Can you take a look at this sample project below, I am seeing the flickering in my Mesh Distance Fields Visualization but that is expected representation of the culling happening, but I am not seeing any flickering in my shadow setup.
And here is the Test Project:
Test Project 4.10.2
Hi Eric, thanks for testing this! In your test project with your setup I don’t see the flickering of shadows. But if I set the SpawnRadius to 500 and the amount of Instances to spawn to 5000, then I see the extreme flickering of the shadows. It only seems to happen if meshes that affect distance field overlap, so with your current setup the cubes just never overlap, so no shadow flickering.
I have adjusted the spawner to also make the Z location random, and this is how it looks like here:
Hi John, I’m helping Eric with this one.
There are limitations with Distance Fields features in a small area. This is culling that is done based on some hard-coded limitations, which is not a bug.
This hard-coded value is controlled by MAX_OBJECTS_PER_TILE and this max is necessary because of D3D11 limitations. It’s culling per tile. You can work around this by disabling small meshes, like grass. This can quickly cause this issue to become apparent in your scene.
Some CVars to be aware of.
r.DFShadowScatterTileCulling: This is on by default, but will disable tile culling which can sometimes work to get rid of the shadows poping in and out however, this is still under the limitations set by D3D11.
r. DFShadowWorldTileSize: This is set to 200 by default, but increasing/decreasing the tile size can help in some situations, especially with some larger objects. Inputting large values will not likely help in this situation though, again, the number of objects per tile is still limited by D3D11.
Hopefully things can be improved in the future. Just to clarify as well this is not related to the AMD bug that was reported with Distance Fields not working. That has already been resolved with Catalyst 15.10 and the latest AMD driver is 15.7.
Hi Tim, thanks very much for your answer.
So so with ISMCs each instance counts as an individual object?
If you say it’s a limitation set by D3D11, does that mean this will be fixed once support for D3D12 and Vulkan is more mature in the engine?
r.DFShadowScatterTileCulling seems to be interesting, setting it to 0 makes the flickering a lot less extreme, but it’s still there. What are the downsides of setting this cvar to 0 instead of the default 1? Less performance?
Regardless of the mesh being instanced, the individual static mesh will still have it’s own distance field volume texture. When this mesh is added to the scene the source data is used to populate the texture atlas. All the distance fields are duplicated into FDistanceFieldVolumeTextureAtlas. You can find how much memory is being used by the atlas by looking at your log for
LogStaticMesh: Allocated Allocated [texture atlas size] distance field atlast = [value]Mb. This should give you a better idea of how much memory is being used by your DFs as well.
I can only say that it’s “possible” that the limitations may be higher with D3D12, but to my knowledge, that’s not been tested or worked on at this point.
By disabling r.DFShadowScatterTileCulling I would expect there to be added cost for not culling based on the set tile size.
I can confirm that disabling lighting>“affect distance field lighting” on many objects (especially the largest static-lit ones/ones with the most complicated mesh silhouettes) helps the issue. Removing from the many smaller dynamic objects is also helpful. Preferably, I reserve distance fields for dynamic objects and am baking static shadows on static objects (so have turned of the toggle for all smaller static objects). It seems that the higher-resolution distance field objects are those which have the most issue.
It also seems like the order in setting that value determines which mesh are affected (the last ones selected?). Ex: If a collection of objects is selected, then “affect distance field lighting” is toggled on/off, the items which have the worst artifact are now different than were before the value was cycled.
*Note: Lighting must be rebuilt for the improvements to fully take effect.