Error building reference-project with docker

[philippeqc]

Bug description

When using the docker image "unityci/editor:windows-2021.3.1f1-windows-il2cpp-1.0.1", to build reference-project, the produced application only displays a white screen.

How to reproduce

The following instructions are performed on Windows 10 using powershell.

Create a docker image and use it to build reference-project. Substitute with your values for UNITY_USERNAME, UNITY_PASSWORD and UNITY_SERIAL.

git clone https://github.com/game-ci/docker.git docker-game-ci;

"ARG UNITY_VERSION='2021.3.1f1' `
ARG UNITY_IMAGE_VERSION='1.0.1' `
FROM unityci/editor:windows-${UNITY_VERSION}-windows-il2cpp-${UNITY_IMAGE_VERSION} `
RUN choco install visualstudio2022-workload-vctools --no-progress -y `
USER ContainerUser" > Dockerfile

docker build -t unity-test:latest -m 6GB . --network "Default Switch"

docker run --rm -it -w C:/docker-game-ci `
-v $pwd/docker-game-ci:C:/docker-game-ci `
-e "[email protected]" `
-e "UNITY_PASSWORD=example_password" `
-e "UNITY_SERIAL=AN-EXAM-PLE-SERIA-LKEY-1234" `
-e "UNITY_EDITOR=C:\Program Files\Unity\Hub\Editor\2021.3.1f1\Editor\Unity.exe" `
unity-test:latest powershell -Command 'try { `
    Start-Process -FilePath $env:UNITY_EDITOR -Wait -ArgumentList @(`
    "-quit", "-nographics", "-batchmode", "-projectPath ./reference-project/", `
    "-buildWindows64Player ./bin/app.exe", "-logFile ./Build.log", `
    "-username ""$env:UNITY_USERNAME""", "-password ""$env:UNITY_PASSWORD""", `
    "-serial ""$env:UNITY_SERIAL""") `
} `
finally { `
    Start-Process -FilePath $env:UNITY_EDITOR -Wait -ArgumentList @(`
    "-quit", "-nographics", "-batchmode", "-logFile ./Release.log", `
    "-username ""$env:UNITY_USERNAME""", "-password ""$env:UNITY_PASSWORD""", `
    "-returnlicense") `
} ';

When launching the application, the display is all white.

In the log file, this line The following line occurs 11 times in the log file:

Initializing Microsoft Media Foundation failed.  It seems that the Microsoft Media Foundation is not installed on this machine or a newer version of Microsoft Media Foundation is required.  To install the necessary libraries please install the Media Feature Pack from https://www.microsoft.com/en-us/search/result.aspx?q=Media+Feature+Pack for your version of Windows.

Around line 7127 and 7182, the following stack trace is shown:

UnityEngine.StackTraceUtility:ExtractStackTrace ()
UnityEngine.Rendering.Universal.UniversalRenderPipelineGlobalSettings:Create (string,UnityEngine.Rendering.Universal.UniversalRenderPipelineGlobalSettings) (at Library/PackageCache/[email protected]/Runtime/UniversalRenderPipelineGlobalSettings.cs:145)
UnityEngine.Rendering.Universal.UniversalRenderPipelineGlobalSettings:Ensure (string,bool) (at Library/PackageCache/[email protected]/Runtime/UniversalRenderPipelineGlobalSettings.cs:116)
UnityEngine.Rendering.Universal.UniversalRenderPipeline:.ctor (UnityEngine.Rendering.Universal.UniversalRenderPipelineAsset) (at Library/PackageCache/[email protected]/Runtime/UniversalRenderPipeline.cs:147)
UnityEngine.Rendering.Universal.UniversalRenderPipelineAsset:CreatePipeline () (at Library/PackageCache/[email protected]/Runtime/Data/UniversalRenderPipelineAsset.cs:401)
UnityEngine.Rendering.RenderPipelineAsset:InternalCreatePipeline ()
UnityEngine.Rendering.RenderPipelineManager:PrepareRenderPipeline (UnityEngine.Rendering.RenderPipelineAsset)
UnityEngine.Rendering.RenderPipelineManager:DoRenderLoop_Internal (UnityEngine.Rendering.RenderPipelineAsset,intptr,System.Collections.Generic.List`1<UnityEngine.Camera/RenderRequest>,Unity.Collections.LowLevel.Unsafe.AtomicSafetyHandle)

[C:\buildslave\unity\build\Modules\Video\Public\Media\WindowsMedia\WindowsVideoMedia.cpp line 1124]

Expected behavior

The image "${UNITY_VERSION}-windows-il2cpp-${UNITY_IMAGE_VERSION}" should correctly build reference-project as it is.

There should not be any exceptions on "WindowsVideoMedia.cpp" in the log file.

Additional details

In the log file, the following exception is observed multiple times. It does not appear to be a problem, as when building the project outside of the docker image, i.e. using the unity editor installed on my computer, they are present but the produced application displays the scene correctly.

RenderTexture.Create with shadow sampling failed: Hardware does not support shadow compare sampling.
UnityEngine.StackTraceUtility:ExtractStackTrace ()
UnityEngine.RenderTexture:GetTemporary_Internal (UnityEngine.RenderTextureDescriptor)
UnityEngine.RenderTexture:GetTemporary (UnityEngine.RenderTextureDescriptor)
UnityEngine.Rendering.Universal.ShadowUtils:GetTemporaryShadowTexture (int,int,int) (at Library/PackageCache/[email protected]/Runtime/ShadowUtils.cs:268)
UnityEngine.Rendering.Universal.Internal.MainLightShadowCasterPass:Setup (UnityEngine.Rendering.Universal.RenderingData&) (at Library/PackageCache/[email protected]/Runtime/Passes/MainLightShadowCasterPass.cs:114)
UnityEngine.Rendering.Universal.UniversalRenderer:Setup (UnityEngine.Rendering.ScriptableRenderContext,UnityEngine.Rendering.Universal.RenderingData&) (at Library/PackageCache/[email protected]/Runtime/UniversalRenderer.cs:455)
UnityEngine.Rendering.Universal.UniversalRenderPipeline:RenderSingleCamera (UnityEngine.Rendering.ScriptableRenderContext,UnityEngine.Rendering.Universal.CameraData,bool) (at Library/PackageCache/[email protected]/Runtime/UniversalRenderPipeline.cs:411)
UnityEngine.Rendering.Universal.UniversalRenderPipeline:RenderSingleCamera (UnityEngine.Rendering.ScriptableRenderContext,UnityEngine.Camera) (at Library/PackageCache/[email protected]/Runtime/UniversalRenderPipeline.cs:324)
UnityEngine.Rendering.Universal.UniversalRenderPipeline:Render (UnityEngine.Rendering.ScriptableRenderContext,System.Collections.Generic.List`1<UnityEngine.Camera>) (at Library/PackageCache/[email protected]/Runtime/UniversalRenderPipeline.cs:279)
UnityEngine.Rendering.RenderPipeline:InternalRender (UnityEngine.Rendering.ScriptableRenderContext,System.Collections.Generic.List`1<UnityEngine.Camera>)
UnityEngine.Rendering.RenderPipelineManager:DoRenderLoop_Internal (UnityEngine.Rendering.RenderPipelineAsset,intptr,System.Collections.Generic.List`1<UnityEngine.Camera/RenderRequest>,Unity.Collections.LowLevel.Unsafe.AtomicSafetyHandle)
UnityEditor.Experimental.Rendering.BuiltinBakedReflectionSystem:Internal_Tick (UnityEditor.Experimental.Rendering.SceneStateHash)
UnityEditor.Experimental.Rendering.BuiltinBakedReflectionSystem:Tick (UnityEditor.Experimental.Rendering.SceneStateHash,UnityEditor.Experimental.Rendering.IScriptableBakedReflectionSystemStageNotifier)
UnityEditor.Experimental.Rendering.ScriptableBakedReflectionSystemWrapper:Internal_ScriptableBakedReflectionSystemWrapper_Tick (UnityEditor.Experimental.Rendering.SceneStateHash)

[C:\buildslave\unity\build\Runtime\Graphics\RenderTexture.cpp line 679]

The full log file: Build.log

[davidmfinol]

Is this a duplicate of game-ci/unity-builder#469 ?

[philippeqc]

Is this a duplicate of game-ci/unity-builder#469 ?

Good observation! I don't beleive it is.

When I applied the fix proposed by TDogVoid (game-ci/unity-builder#469 (comment)), and build from the command line, the player's output is still all white. I didn't keep those changes.

A side observation emerging from performing multiple build operations is that a previous "good" build can make a "bad" build show the correct display from the player. To isolate from this, one repository would be modified through the Unity Editor. Then the editor would be closed and the changes commited to git (and not pushed). For each test, a git worktree would be created where a single build would be performed and the player app analysed before being deleted. This ensure that the observed display from the player was not influenced by previous manipulations.

It was observed that the command passed to docker (Start-Process -FilePath "C:\Program Files\Unity\Hub\Editor\2021.3.1f1\Editor\Unity.exe" -Wait -ArgumentList @( "-quit", "-nographics", "-batchmode", "-projectPath reference-project", "-buildWindows64Player ./bin/app.exe", "-logFile ./build.log");) would also produce a player with an all white display when executed natively.

Upon opening reference-project in the Editor, the global illumination is always re-baked . The Editor's command line documentation note that the flag -nographics prevents this. Removing said flag from the command and running a build does produce a player correctly displaying the scene. This new command produce the following when run from docker:

Aborting batchmode due to fatal error:
Failed to initialize unity graphics.
Editor exited with error(s): Failed to initialize graphics.
Make sure you have DirectX 11 installed, have up to date
drivers for your graphics card and have not disabled
3D acceleration in display settings.

For now, that is an issue I'd prefer not to tackle. So -nographics stays.

It apprears that the Global Illumination can be pre-baked if you go to Window > Rendering > Lighting, unselect Auto Generate and click Generate Lighting. This adds some files to the project, mostly under Assets/Scenes/SampleScene. This updated project produce a player correctly displaying the scene both when build from the command line and from within docker.

While this addresses the issue, I don't know what should be done so other users can benefit from a working example using reference-project build through docker on Windows.

[davidmfinol]

So the issue is that you need to have lightmaps generated?
Sounds like this issue then: game-ci/unity-builder#609

[philippeqc]

That sure sounds like it!

[sk-chanch]

Is this a duplicate of game-ci/unity-builder#469 ?

Good observation! I don't beleive it is.

When I applied the fix proposed by TDogVoid (game-ci/unity-builder#469 (comment)), and build from the command line, the player's output is still all white. I didn't keep those changes.

A side observation emerging from performing multiple build operations is that a previous "good" build can make a "bad" build show the correct display from the player. To isolate from this, one repository would be modified through the Unity Editor. Then the editor would be closed and the changes commited to git (and not pushed). For each test, a git worktree would be created where a single build would be performed and the player app analysed before being deleted. This ensure that the observed display from the player was not influenced by previous manipulations.

It was observed that the command passed to docker (Start-Process -FilePath "C:\Program Files\Unity\Hub\Editor\2021.3.1f1\Editor\Unity.exe" -Wait -ArgumentList @( "-quit", "-nographics", "-batchmode", "-projectPath reference-project", "-buildWindows64Player ./bin/app.exe", "-logFile ./build.log");) would also produce a player with an all white display when executed natively.

Upon opening reference-project in the Editor, the global illumination is always re-baked . The Editor's command line documentation note that the flag -nographics prevents this. Removing said flag from the command and running a build does produce a player correctly displaying the scene. This new command produce the following when run from docker:

Aborting batchmode due to fatal error:
Failed to initialize unity graphics.
Editor exited with error(s): Failed to initialize graphics.
Make sure you have DirectX 11 installed, have up to date
drivers for your graphics card and have not disabled
3D acceleration in display settings.

For now, that is an issue I'd prefer not to tackle. So -nographics stays.

It apprears that the Global Illumination can be pre-baked if you go to Window > Rendering > Lighting, unselect Auto Generate and click Generate Lighting. This adds some files to the project, mostly under Assets/Scenes/SampleScene. This updated project produce a player correctly displaying the scene both when build from the command line and from within docker.

While this addresses the issue, I don't know what should be done so other users can benefit from a working example using reference-project build through docker on Windows.

Thanks! @philippeqc Auto Generate work for me