Closed MarkJGx closed 2 years ago
Hum, I still can't understand why Unreal does anything at building shipping time when the plugin is explicitely marked as Editor plugin...
But regardless:
What seems to bother your compiler is this static word, but I don't understand why it would be unexpected...
I'll dig into that, in the meantime I suggest two solutions:
.uproject
file with DarkerNodes, or launch your build from a version of your .uproject
file without Darker Nodes.In any case, I know it's not ideal (I'm very sorry for this), and I'll try to find a solution 😕
@MarkJGx Also, seeing this issue: https://github.com/adamrehn/ue4-docker/issues/83, do you have 4.25.1 update? Or do you run a custom version of the engine?
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.
@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?
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.
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...
Could you try the same thing from a blank project? If you don't have time for this, there's no problem...
After pressing "Fix Elements" and restarting, this is what editor throws out:
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.
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:
Binary
and Intermediate folder
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.
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?
Nope. No ResetAllShaderSourceDirectoryMappings in any plugins/project code.
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...
It does.
Fixed. Disabled r.ShaderDevelopmentMode
Added on the FAQ: https://github.com/TheHerobrine/DarkerNodes/wiki/FAQ
@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
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.
@jorgenpt Thank you for this, it will be updated for the next version!
Ready for version 3!
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 Windows