The following video footage will quickly demonstrate an issue with the distance field, it is not affected by the WOS feature, and so it will result an offset in DF shadow and DFAO features.
In the second video, the camera smoothing is also bugged once you shift the world origin, and it is very annyoing. Isn't World Origin Shift have been declared as a fully implemented feature? Probably not.Hey Konflict,
Can you reproduce this in a blank and minimal test project, and provide me with steps or the project itself?
I ran a very similar test on my end, but am confused as to how you are enabling the Mesh Distance Field visualizer during PIE and switching back and forth between that and Lit Mode to see the shadowing errors.
I will say that upon reading the documentation on Distance Fields, any sort of World Position Offset used within materials on objects that have opted into Generating Mesh Distance Fields, will not be displayed correctly. Now, since World Origin Shifting Shifting results in adding an offset vector to all registered Actors in the world, I would assume the Distance Field implementation to have issues. This could be incorrect though since there is a difference between the vertex and pixel shader and how geometries locations are stored.
Let me know if you have additional questions.
Thanks,
Yes i reproduced the problems in a very very minimal project as per your request, and i also implemented a temporal fix to the issue with shadows that probably will help to find the proper solution, since it seems like the DF is cached a way that is not gets updated upon world origin shift but only when transform the mesh (eg move or rotate a bit), in which case that individual mesh gets updated in the DF scene.
The pawn also got a sphere attached which should move with the camera, but as the video was showcasing the issue before, the camera smooth reacts very bad on World origin shifting, thus a disturbing “slide” effect will be seen when you shift the world coordinates (press 2 to see the effects of a large change).
The WPO i can confirm it is indeed does not contribute to the shadow mapping properly, which could be a missing feature of DF (it depends on how do you approach the problem), but the materials does not implement origin shifting actually, since the absolute world position will not follow the world offset, henche the color changes in the material you will witness.
The issues showcased in the videos and this repro project does not depend on WPO and user created materials, therefore the issue with DF shadows/DFAO, camera smoothing and material world position are easily reproducible individually as well.
For convenience reasons i created the repro project in 4.15 but you will see the same results in 4.16 preview as well.
[repro project in 4.15.0 launcher][1]
[1]: 137675-dfwos_ue4_15_0_launch.zip (549 KB)
ps: the trick with the visualizer/PIE was that i press the eject/possess buttons to switch between the viewports. 
Hi Konflict, Have you learned anything else about this? We have been struggling for a while to find a way to flush/reset the DF. The fix you have with moving the objects slightly doesn’t appear to be effective at all in 4.17.
Check out this also.
https://udn.unrealengine.com/questions/365250/polluted-mesh-distance-fields-after-re-origin.html?childToView=375478#comment-375478
I am interested in this workaround to see what you were able to do, as our project would greatly benefit from any possible routes to a workable solution.
Hi i have sent you a pm on forum, please check it out!
The “fix” was only tested with the project i attached here, and it was not meant as a workaround but rather a guidance for the engine deveopers to figure out the reasons for the issue. A proper solution would probably require some research and engine modifications. We can talk if you will.
We are using the mesh distance fields of meshes we made invisible in order to mask other objects. This is done by finding distance to nearest mesh inside the material of the masked actor and using that to set opacity to 0. Basically we need the mesh distance fields for everything to be in the right place.
Well. Neither of you guy are saying any specific problems you have found so it’s hard to respond to you since i don’t understand the issue you have seeing.
In order to focus on the problem i (we) have been found, there might be some quick workarounds exists, tho i can’t say for sure if this would help you in your projects. Not even in a shipped product either. But it’s something and you can try maybe it helps,… who knows after all.
Let’s say you can trigger a manual update in the cached distance field with by changing a property. I have just found this in about 5 minutes but once again it is NOT a solution nor a workaround to any of the issues regarding the problems revolving around DF and other advanced features of the engine that all are LACK of support world origin shifting.
Here, i just recorded a footage of my finding:
By applying this (or maybe there others as well) console command you will trigger an update in the volume which might help for the time being, but as a proper solution i mean a quality time must be spent r&d the entire pipeline, and find better ways to solve any problems regardin df.
I am kinda surprised none of the Epic employees are catching up with this issue report but oh well, this is not an important feature as it seems. Nevertheless, we can figure this out on our own. Send me a PM on the forums and we can talk.
Thanks for the details (and your video) we will try these options and see what results we have as this gives us a good starting point.
Hello,
Just wanted to update everyone that this is a known/tracked issue:
Unreal Engine Issues and Bug Tracker (UE-55375)
As a workaround:
"FPrimitiveSceneInfo::ApplyWorldOffset should call DistanceFieldSceneData.UpdatePrimitive(this); That will cause ProcessPrimitiveUpdate to be called again for that object, fetching the new offsetted proxy bounds and uploading them to the DistanceFieldSceneData (GPU representation of the scene).
Just wanted to update, it is backlogged, so nobody will care about it. Eventually the ticket will get deleted as usual. Unacceptable.
Do they really just delete the backlogged items after a while? That is insane 
Wow that is very sad I have been waiting for this to be resolved now for over a year
I actually used the word “as usual” not “in fact” but yes there were many tracked issues in the past which was set to backlogged eventually gets deleted because of ‘inactivity’ on the developers part. Simply put, things like that will be ignored. I believe this issue will go the same way. As usual.
Known and tracked issue… Still not fixed after 5 years.
4.26.2 DFAO is not implemented for World Rebasing. That’s for somebody who is wondering why suddenly shadows are not working.