With new Metal backend on Mac UE4.11 our game has two new rendering bugs.
First one is that static shadows from stationary directional light are completely broken. Screenspace buffer that should contain static shadows is just static garbage from different application. This is shown at second picture where there are some random text shown at grass. Dynamic shadows work fine.
Second one is that Motion Vectors are bugged for some objects. This causes lot’s of temporal artifacts. Third picture lamp is good example of bug. Lamp is static. Camera is not moving.
Both of these are new bugs that are introduced in 4.11.
Thanks for posting these - we haven’t seen anything similar in our test projects AFAIK so you have found some new problems. I’ve added UE-29361 to track the shadow rendering bug & UE-29362 to track the motion vector bug. Could I ask you to help me debug these issues?
If you could send me the project files that show these issues that would probably be easiest, but if you aren’t comfortable doing that then either generate a quick cut-down level project that shows the problem, or point me at one of the Epic samples that shows the same problem so I can debug it.
Ideally you could also send me two Metal frame captures each demonstrating one of the two issues and projects which also show the issues that I can run and use for debugging. The process for capturing a Metal frame is somewhat involved if you are running from self-built executables in Xcode but because of the way Apple’s tools work it’s even more complicated if you are using pre-built binaries.
-
(If you normally run through Xcode then skip this step) If you don’t use Xcode and/or are developing a blueprint only project then create a new Xcode OS X Cocoa Application project (New > Project > OS X > Application > Cocoa Application) give it a name and save it wherever you like. Then go to the scheme drop down, select Edit Scheme, then select Other in the Executable drop down in the Run > Info section. In the file dialog that appears select the UE4Editor.app, then go to Arguments and in the arguments list add a new argument with + then drag your .uproject file into the text-box. If there are spaces or other non-ascii characters in the path you will need to add quotes (“”) around the path in the same text-box.
-
In ConsoleVariables.ini (for the binary Editor this will be in /Users/Shared/UnrealEngine/4.11/Engine/Config) uncomment (
the lines: r.Shaders.Optimize=0 & r.Shaders.KeepDebugInfo=1. This makes the shaders text available in the frame capture, without which its impossible to work out what’s going on. Note that unlike other capture tools you can’t actually debug shaders in Metal, only view them. Changing these settings will also cause all shaders to recompile.
-
You can capture a Metal frame when running through Xcode by going into the scheme drop-down in the top-left of the main Xcode window, scroll all the way down to Edit Scheme, then select Run > Options > GPU Frame Capture and set this to Metal.
-
Make sure that the Editor is set to open your project on startup (i.e. the .uproject is the first argument in the Run > Arguments panel). You can also use ‘game’ mode by adding the level name, then “-game -windowed” to the Scheme’s argument list if its easier to capture the problem in game.
-
Run the Editor and ensure that in Editor Preferences > Miscellaneous > Performance that the “Use Less CPU when in Background” option is UNCHECKED because otherwise the Metal frame capture tool won’t work. Also ensure that the viewport’s “Realtime” option is enabled - you may need to disable “Monitor Editor Performance” in Editor Preferences > Miscellaneous > Performance to ensure it remains so.
-
Find on of the locations show in the screenshots and then switch back to Xcode. Use the small camera button in the debugger control bar to capture a frame. Once it is displayed use File > Export to save it.
-
Repeat for the other problem.
Hello. Thanks for reply.
Fastest way to replicate Motion vector bug seems to use ShooterGame and Open project settings → Rendering → toggle Accurate Velocities from Vertex Deformation and Selectively output to the GBuffer rendertargets ON.
I will look to the Metal frame capture but I am not Mac user myself so it might take a while. I will also try to make minimal reproducible project.
Thanks for that ! You don’t need to provide a Metal capture for the Motion vector rendering bugs because the sample case you’ve identified is ideal for debugging. I wasn’t aware of these options myself so I’ve never personally tried them so while I’m sorry you’re encountering problems I really appreciate the report.
If you can provide a repro. case for the shadowing artefact, either using an Epic sample or your own then they’ll be investigated. Obviously I can’t make promises as to when they’ll be fixed because I don’t yet know what’s wrong. If there are driver bugs involved it may take considerably longer than if they are merely bugs in the UE4 code.
We also tested with another Mac and bug was reproducable. There is screenshot from bug with First person project when changing only those two settings.
Enabling “Accurate Velocities from Vertex Deformation” exposes a serious GPU driver bug on AMD that I will need to file with Apple. This means any fix will be dependent on Apple’s OS X update cycle which we don’t control.
Can you check if the “Accurate Velocities from Vertex Deformation” setting works correctly if you DISABLE “Selectively output to the GBuffer render targets”?
I have been tracking an Intel & Nvidia GPU driver bug where selective GBuffer output is unreliable on Metal, so it could be related.
I’ve now tested this on an Nvidia system and I suspect “Accurate Velocities from Vertex Deformation” won’t work on Nvidia when “Selectively output to the GBuffer render targets” is enabled because of the GPU driver bug I was already tracking.
It appears I need to work with Apple to resolve several GPU driver bugs when combining “Accurate Velocities from Vertex Deformation” with “Selectively output to the GBuffer render targets”. This unfortunately means I can’t predict when it will be resolved for you.
I’ve filed all the relevant bugs with Apple and made note of them in our own JIRA system so I’ll keep track of things as they progress. However, I have no idea when this bug will be resolved so in the interim you’ll need to disable “Accurate Velocities from Vertex Deformation” on Mac if you can get away with. Since the Mac doesn’t support this should be OK and you can disable it for Mac only by adding a Mac sub-folder inside your projects Config folder (i.e. ProjectName/Config/Mac) then adding a MacEngine.ini that disables the “Accurate Velocities from Vertex Deformation” setting. The contents of MacEngine.ini would look like:
[/Script/Engine.RendererSettings]
r.BasePassOutputsVelocity=False
When we tested with ““Accurate Velocities from Vertex Deformation” setting works correctly if you DISABLE “Selectively output to the GBuffer render targets”” static shadows were bugged but motion vectors seemed to work.
Thanks. This workaround fix bug for us.
Only problem is small trailing with trees and foliage where we use WorldPositionOffset material animation. Accurate Velocities from Vertex Deformation fix that but it should be ok if it’s only for mac and only while waiting for a fix.
If you could provide a sample case for the broken static shadow effect you originally posted, either in the Epic samples or a sample project of your own then I can look into that too as there’s no guarantee its related to the velocity setting.
