10-15-2022, 01:50 PM
I was having this strange bug in the build of my game where UnityEngine.Random.value would just return the same value over and over again. It was as if Random.state was being forcefully set to the same value every frame. It only happened in the build, so it was a bit difficult to catch.
I checked the log file and found this error message getting repeated over and over:
I figured out that it was regarding this line inside FluffyUnderware.Curvy.Generator.CGVMesh:
This is a bit problematic to me because my project uses HDRP, and therefore doesn't use the Standard shader.
I checked to make sure, and yes, it is indeed not in the build:
Without editing Curvy's source code, my only course of action is to add the Standard shader into the build, despite the fact that nothing in the game really uses it.
I guess this is one of those things that in the end, doesn't really affect performance, but nevertheless kind of an idiosyncratic thing needed to get the build running properly.
I'd have preferred if the code was changed so it didn't need a NullMaterialDictionaryKey in the first place, or something like perhaps if Curvy had a stub/empty shader file, put it in a Resources folder, and use that, instead of trying to look for the Standard shader. That way, we wouldn't have to worry about making sure the Standard shader is in the Always Included Shaders list.
I checked the log file and found this error message getting repeated over and over:
Code:
ArgumentNullException: Value cannot be null.
Parameter name: shader
at (wrapper managed-to-native) UnityEngine.Material.CreateWithShader(UnityEngine.Material,UnityEngine.Shader)
at UnityEngine.Material..ctor (UnityEngine.Shader shader) [0x00008] in <ae4a1ec73f6041bbadc2055c204f6096>:0
at FluffyUnderware.Curvy.Generator.CGVMesh..cctor () [0x0000a] in <a5ab9950f8554e81bd281f399f125c50>:0
Rethrow as TypeInitializationException: The type initializer for 'FluffyUnderware.Curvy.Generator.CGVMesh' threw an exception.
at FluffyUnderware.Curvy.Generator.Modules.InputMesh.Refresh () [0x00081] in <a5ab9950f8554e81bd281f399f125c50>:0
at FluffyUnderware.Curvy.Generator.CGModule.doRefresh () [0x00035] in <a5ab9950f8554e81bd281f399f125c50>:0
at FluffyUnderware.Curvy.Generator.CurvyGenerator.Refresh (System.Boolean forceUpdate) [0x00193] in <a5ab9950f8554e81bd281f399f125c50>:0
at FluffyUnderware.Curvy.Generator.CurvyGenerator.TryAutoRefresh () [0x00050] in <a5ab9950f8554e81bd281f399f125c50>:0
at FluffyUnderware.Curvy.Generator.CurvyGenerator.Update () [0x00010] in <a5ab9950f8554e81bd281f399f125c50>:0
I figured out that it was regarding this line inside FluffyUnderware.Curvy.Generator.CGVMesh:
Code:
private static readonly Material NullMaterialDictionaryKey = new Material(Shader.Find("Standard"));
This is a bit problematic to me because my project uses HDRP, and therefore doesn't use the Standard shader.
I checked to make sure, and yes, it is indeed not in the build:
Without editing Curvy's source code, my only course of action is to add the Standard shader into the build, despite the fact that nothing in the game really uses it.
I guess this is one of those things that in the end, doesn't really affect performance, but nevertheless kind of an idiosyncratic thing needed to get the build running properly.
I'd have preferred if the code was changed so it didn't need a NullMaterialDictionaryKey in the first place, or something like perhaps if Curvy had a stub/empty shader file, put it in a Resources folder, and use that, instead of trying to look for the Standard shader. That way, we wouldn't have to worry about making sure the Standard shader is in the Always Included Shaders list.