Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

4.25. Shipping build fails to launch due to shader compiliation issues. #131

Closed
MarkJGx opened this issue Feb 6, 2021 · 19 comments
Closed
Assignees
Labels
bug Something isn't working ready Issue is fixed and ready to be deployed
Milestone

Comments

@MarkJGx
Copy link

MarkJGx commented Feb 6, 2021

I want to use this theme. Unfortunately when packaging a shipping game with this editor plugin enabled, it causes the Windows shipping build to crash with a missing WorldGridMaterial (due to failed shader compilation while cooking). While building for Linux under the Vulkan RHI, the shader cooker starts throwing out dialog messages that it's failing to build DarkerNodes Shapes.usf. Doesn't throw out any errors on the Windows DX11/DX12 build, but Windows build doesn't launch regardless. The most peculiar thing is that this is a editor plugin, yet it's interfering with a non-editor shipping build.
Linux
linux-shipping-fial
Windows
windows-launch-fail

@hugoattal
Copy link
Owner

Hum, I still can't understand why Unreal does anything at building shipping time when the plugin is explicitely marked as Editor plugin...
image

But regardless:

  • I didn't get any feedback that Darker Nodes is crashing shipping build in Windows, that's concerning...
  • It may have something to do with Vulkan? I never tried Vulkan with Unreal Engine, is HLSL supported?

What seems to bother your compiler is this static word, but I don't understand why it would be unexpected...
image

I'll dig into that, in the meantime I suggest two solutions:

In any case, I know it's not ideal (I'm very sorry for this), and I'll try to find a solution 😕

@hugoattal hugoattal added the bug Something isn't working label Feb 6, 2021
@hugoattal
Copy link
Owner

@MarkJGx Also, seeing this issue: adamrehn/ue4-docker#83, do you have 4.25.1 update? Or do you run a custom version of the engine?

@MarkJGx
Copy link
Author

MarkJGx commented Feb 6, 2021

4.25.3 fork locally built. adamrehn/ue4-docker#83 looks unrelated since I'm cross-compiling a game project with a pre-built engine.
I bet that the Windows DX12/DX11 RHI build is suffering from the same issue as the Vulkan RHI Linux build, but isn't being as verbose. From my understanding unreal shader code translates between RHI's seamlessly, so a Vulkan specific bug is unlikely.

@hugoattal
Copy link
Owner

@MarkJGx Arg, I can't reproduce at all, everything seems to work fine on my end on Windows... (Build and launch)

If you go into "Edit/Editor Preferences/Darker Nodes Plugins" and you click on "Fix Missing Elements", do you have anything special on the log? Does it change the outcome?

Also, I'm not very familiar with cross compiling/building in command line... Can you explain me quickly how to build a project to Linux under Vulkan RHI?

@MarkJGx
Copy link
Author

MarkJGx commented Feb 7, 2021

This will build a Linux standalone shipping build without the editor.
RunUAT.bat BuildCookRun -project=C:/Users/user/Documents/UnrealProjects/privacy/Privacy.uproject -nocompile -nocompileeditor -installed -rocket -nop4 -licensee -clientconfig=Shipping -serverconfig=Shipping -platform=Linux -cook -iterate -iterativecooking -package -stage -stagingdirectory=C:\Users\user\Documents\UnrealProjects\privacy\Scripts\Output\Linux -build -pak -prereqs -distribution

DefaultEngine.ini settings for the Vulkan RHI on Linux.

[/Script/LinuxTargetPlatform.LinuxTargetSettings]
SpatializationPlugin=
ReverbPlugin=
OcclusionPlugin=
+TargetedRHIs=SF_VULKAN_SM5

You'll also need the Epic Games clang/llvm distributable for your target engine.
https://docs.unrealengine.com/en-US/SharingAndReleasing/Linux/GettingStarted/index.html
I'll try the fix elements thing in a bit.

@hugoattal
Copy link
Owner

Ok, I downloaded the clang thing and the Linux option of the Unreal Engine 4.26.
I did not change the DefaultEngine.ini since you said that a Vulkan specific bug was unlikely.
I launched the exact same command line you gave (only changing the project directories)
And I think it worked, I didn't have any problem at all...

image

Could you try the same thing from a blank project? If you don't have time for this, there's no problem...

@MarkJGx
Copy link
Author

MarkJGx commented Feb 10, 2021

After pressing "Fix Elements" and restarting, this is what editor throws out:
Screenshot (278)

We don't use Niagara, and it's completely disabled for our whole project.
EDIT: After trying to build the Linux client, it's throwing the same shader error dialog message.

@hugoattal
Copy link
Owner

Hum, Darker Nodes requires Niagara to update the Niagara interface.
I'm not planning on removing Niagara support, and I can't make it an option since the Niagara requirement is in the .uplugin...
But if you want to use Darker Nodes while keeping Niagara disabled, I could make a custom build for you!

About the error you get, it feels pretty weird... Is the plugin directly inside your project Plugins folder? Or in the marketplace folder of the engine? Is the plugin activated at all? I think you might want to:

  • disable the plugin on your project
  • delete the plugin
  • delete your Binary and Intermediate folder
  • rebuild your project (so it's clean)
  • redownload the plugin

@MarkJGx
Copy link
Author

MarkJGx commented Feb 10, 2021

Started writing this right after my original post:
I removed any mention of Niagara from the .uplugin's .json and plugin module's build.cs, also removed any reference to Niagara editor in the plugins native code, including the slate styling code. After that the editor was still failing on a different shader error, involving Button.usf. I ended up going in and removing the commented #include Button.usf code, for some reason that actually did something?
Did the fix elements thing again and no errors on launch. Just compiled the shipping builds for all platforms with some slight hitches due to iterative cooking, cleared out the local Intermediate/Binaries directories and tried again, can confirm that the Windows version builds and runs without any shader errors, however the Linux builds still have the same issue.

I could setup a private repo with the modifications if you'd like.

@hugoattal
Copy link
Owner

hugoattal commented Feb 10, 2021

Hum, the thing is that you won't be using the shaders function used in the .usf... Unless you C/C their content inside the material custom node (which not ideal from a dev perspective 😅). But I'll probably end up doing this if that fix your problem.

By any chance, don't have any ResetAllShaderSourceDirectoryMappings() call in your code or plugins?

@MarkJGx
Copy link
Author

MarkJGx commented Feb 10, 2021

Nope. No ResetAllShaderSourceDirectoryMappings in any plugins/project code.

@hugoattal
Copy link
Owner

So, does the Shaders folder exist under the DarkerNodes folder with a bunch of .usf files (including Button.usf) inside it? If it does, I'm really clueless on what happen...

@MarkJGx
Copy link
Author

MarkJGx commented Feb 10, 2021

It does.

@MarkJGx
Copy link
Author

MarkJGx commented Feb 10, 2021

Fixed. Disabled r.ShaderDevelopmentMode

@MarkJGx MarkJGx closed this as completed Feb 10, 2021
@hugoattal
Copy link
Owner

@jorgenpt
Copy link

@hugoattal We are also hitting this problem -- we're on 4.27.2, and only the Android cook is hitting these warnings. We're running Engine\Binaries\Win64\UE4Editor-Cmd.exe Project\Project.uproject -run=Cook -TargetPlatform=Android_MultiClient -fileopenlog -unversioned -stdout -CrashForUAT -unattended -NoLogTimes, and this is the output:

[2022-03-11T22:25:21.942Z]     LogShaderCompilers: Warning: Failed to compile Material /DarkerNodes/Materials/Panel.Panel for platform GLSL_ES3_1_ANDROID, Default Material will be used in game.
[2022-03-11T22:25:21.942Z]     LogShaderCompilers: Display: /DarkerNodes/lib/Shapes.usf(12): error: syntax error, unexpected STATIC
[2022-03-11T22:25:21.942Z]     LogShaderCompilers: Warning: Failed to compile Material /DarkerNodes/Materials/HeaderBox.HeaderBox for platform SF_VULKAN_ES31_ANDROID, Default Material will be used in game.
[2022-03-11T22:25:21.942Z]     LogShaderCompilers: Display: /DarkerNodes/lib/Shapes.usf(12): error: syntax error, unexpected STATIC
[2022-03-11T22:25:21.942Z]     LogShaderCompilers: Warning: Failed to compile Material /DarkerNodes/Materials/HeaderBox.HeaderBox for platform GLSL_ES3_1_ANDROID, Default Material will be used in game.
[2022-03-11T22:25:21.942Z]     LogShaderCompilers: Display: /DarkerNodes/lib/Shapes.usf(12): error: syntax error, unexpected STATIC
[2022-03-11T22:25:21.942Z]     LogShaderCompilers: Warning: Failed to compile Material /DarkerNodes/Materials/Button.Button for platform SF_VULKAN_ES31_ANDROID, Default Material will be used in game.
[2022-03-11T22:25:21.942Z]     LogShaderCompilers: Display: /DarkerNodes/lib/Shapes.usf(12): error: syntax error, unexpected STATIC
[2022-03-11T22:25:21.942Z]     LogShaderCompilers: Warning: Failed to compile Material /DarkerNodes/Materials/Button.Button for platform GLSL_ES3_1_ANDROID, Default Material will be used in game.
[2022-03-11T22:25:21.942Z]     LogShaderCompilers: Display: /DarkerNodes/lib/Shapes.usf(12): error: syntax error, unexpected STATIC

As far as I can tell, we aren't using r.ShaderDevelopmentMode

@jorgenpt
Copy link

While the source of the particular shader compiler error is pretty mysterious, changing the DarkerNodes module to use EditorNoCommandlet as its Type (instead of Editor) in the .uplugin will prevent it from being loaded by the cooker, which means that it'll no longer reference those materials -- which is what's causing it to be included in the cook.

@hugoattal
Copy link
Owner

@jorgenpt Thank you for this, it will be updated for the next version!

@hugoattal hugoattal reopened this Mar 13, 2022
@hugoattal hugoattal self-assigned this Mar 13, 2022
@hugoattal
Copy link
Owner

Ready for version 3!

@hugoattal hugoattal added the ready Issue is fixed and ready to be deployed label Apr 6, 2022
@hugoattal hugoattal added this to the 3.0 milestone May 5, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working ready Issue is fixed and ready to be deployed
Projects
None yet
Development

No branches or pull requests

3 participants