C++ 4.19 Transition Guide

[Rama]

Dear Community,

Yay for 4.19!

Please post any questions you have about the upgrade process here!

Also feel free to share any thing you learn as you do the upgrade process that you think will benefit others!

**Material Layers & FMaterialParameterInfo**

**UMaterialInterface::GetScalarParameterValue & UMaterialInterface::GetVectorParameterValue**

In order to support the new feature, **material layers**, GetScalarParameterValue and a whole host of other constant/dynamic material parameter functions had to change.

Please note that my provided solution does not take material layers into account (it's still experimental) and defaults to layer 0.

But to get your code to compile, you would change:



```


Mat->GetScalarParameterValue(Name,Value);


```



to :



```


Mat->GetScalarParameterValue(**FMaterialParameterInfo**(Name),Value);


```



I got this solution from Epic's code base -> MaterialInstanceDynamic.cpp from the **BP node** code for GetScalarParameterValue



```


float UMaterialInstanceDynamic::K2_GetScalarParameterValue(FName ParameterName)
{
    float Result = 0.f;
    FMaterialParameterInfo ParameterInfo(ParameterName); **// @TODO: This will only work for non-layered parameters**
    Super::GetScalarParameterValue(ParameterInfo, Result);
    return Result;
}


```



♥

Rama

[Narg]

Did they change something related to Collision Checks or Math Functions (FMath)? Because my Climb system works fine in 4.18 whilst on 4.19 its completely random wether my character grabs the ledge or not, the Traces fail in 4.19 on the same places they succeeded in 4.18, I’m extremely confused (and a bit frustrated as I can’t find the source of this problem)

[muchcharles]

Has anyone run into 4.19 forcing constant complete engine rebuilds? I change stuff only in my game project and the whole engine will rebuild if I regenerate the visual studio files for the game project, not the engine. And several other small changes seem to have kicked off complete engine rebuilds.

[muchcharles]

I have now seen it trigger complete engine rebuilds when building the game project when nothing in the engine or game project has changed.

I grepped through the modification times of all the files and the earlier modified file that was modified after the previous build was:

Engine/Binaries/Win64/ShaderCompileWorker.target

Any ideas?

[SolidGasStudios]

@muchcharles

Has anyone run into 4.19 forcing constant complete engine rebuilds? I change stuff only in my game project and the whole engine will rebuild if I regenerate the visual studio files for the game project, not the engine. And several other small changes seem to have kicked off complete engine rebuilds.

I had the same happen, after building the engine, RightClick the Solution node in VS -> Configuration Manager, then remove all the Builds except your project.

[muchcharles]

Another problem I had was crashing when loading any map with a navmesh. This was apparently due to a bug in Visual Studio 2017 ( I think related to this: Visual Studio Feedback ). Upgrading to the latest VS2017 fixed it. Other people saw the same issue in 4.18, but it didn’t affect me until 4.19 for whatever reason.

[kamrann]

@muchcharles

I have now seen it trigger complete engine rebuilds when building the game project when nothing in the engine or game project has changed.

I gave up using source engine builds a long time ago, precisely because of unreliable UBT behaviour, so I can’t speak to source build issues in 4.19. However, as of 4.19 I am now seeing (for the first time) sporadic complete project rebuilds on a launcher engine install, without any changes to source files.

As for ideas; yep, I have an idea that Epic broke UBT, again.

[anonymous_user_88d57b37]

“yaaay for UE4.19”!
It broke my whole project - again! This is so annoying.

I’m now getting the error that there is now default constructor for the class FLocalVertexFactory in my custom VertexFactory. How do I resolve that?

class FPointCloudVertexFactory : public FLocalVertexFactory
{
public:

FPointCloudVertexFactory()
{}

Edit: resolved the error but now I get the following error during runtime:
Can someone help me?

[ExtraLifeMatt]

@anonymous_user_88d57b37

“yaaay for UE4.19”!
It broke my whole project - again! This is so annoying.

I’m now getting the error that there is now default constructor for the class FLocalVertexFactory in my custom VertexFactory. How do I resolve that?

class FPointCloudVertexFactory : public FLocalVertexFactory
{
public:

FPointCloudVertexFactory()
{}

Edit: resolved the error but now I get the following error during runtime:

Looking at the code

FLocalVertexFactory(ERHIFeatureLevel::Type InFeatureLevel, const char* InDebugName, const FStaticMeshDataType* InStaticMeshDataType = nullptr)

So you need to pass a FeatureLevel and name in for it, like FSplineMeshVertexFactory does:

FSplineMeshVertexFactory(ERHIFeatureLevel::Type InFeatureLevel)
: FLocalVertexFactory(InFeatureLevel, “FSplineMeshVertexFactory”)

[kamrann]

@anonymous_user_88d57b37

Edit: resolved the error but now I get the following error during runtime:
Can someone help me?

I would guess that means you probably passed SM5 for the feature level? I don’t know much about the rendering side of things, but I think in general you will want to pass SM4 if you don’t require specific rendering capabilities. If building for mobile, you may need to pay further attention to this, not sure.

Edit: Anyone know about this stuff? From the enum, maybe ES2 essentially means ‘lowest feature level’, and you can use that as a baseline even if not targetting mobile? Seems a little strange that they made this a requirement for a bunch of rendering related types, but didn’t create something like a ‘BaseLevel’ entry in the enum corresponding to the behaviour before when the types didn’t require this argument.

[anonymous_user_88d57b37]

Hey guys, thanks for the immediate help!

@ExtraLifeMatt

So you need to pass a FeatureLevel and name in for it, like FSplineMeshVertexFactory does:

did this but now I have the SRV-related error (see the screenshot above)

the vertexfactory looks like this (probably outdated/deprecated way?)

[anonymous_user_88d57b37]

the callstack, if it helps:

>    UE4Editor-D3D11RHI.dll!FD3D11DynamicRHI::RHISetShaderResourceViewParameter(FRHIVertexShader * VertexShaderRHI, unsigned int TextureIndex, FRHIShaderResourceView * SRVRHI) Zeile 512    C++    Symbole wurden geladen.
     [Inlineframe] UE4Editor-Engine.dll!FRHICommandList::SetShaderResourceViewParameter(FRHIVertexShader * SamplerIndex, unsigned int) Zeile 2553    C++    Symbole wurden geladen.
     [Inlineframe] UE4Editor-Engine.dll!SetSRVParameter(FRHICommandList &) Zeile 324    C++    Symbole wurden geladen.
     UE4Editor-Engine.dll!FLocalVertexFactoryShaderParameters::SetMesh(FRHICommandList & RHICmdList, FShader * Shader, const FVertexFactory * VertexFactory, const FSceneView & View, const FMeshBatchElement & BatchElement, unsigned int DataFlags) Zeile 63    C++    Symbole wurden geladen.
     UE4Editor-Renderer.dll!FMeshMaterialShader::SetMesh<FRHIVertexShader * __ptr64>(FRHICommandList & RHICmdList, FRHIVertexShader * const ShaderRHI, const FVertexFactory * VertexFactory, const FSceneView & View, const FPrimitiveSceneProxy * Proxy, const FMeshBatchElement & BatchElement, const FDrawingPolicyRenderState & DrawRenderState, unsigned int DataFlags) Zeile 511    C++    Symbole wurden geladen.
     UE4Editor-Renderer.dll!TBasePassVertexShaderPolicyParamType<FUniformLightMapPolicyShaderParametersType>::SetMesh(FRHICommandList & RHICmdList, const FVertexFactory * VertexFactory, const FSceneView & View, const FPrimitiveSceneProxy * Proxy, const FMeshBatch & Mesh, const FMeshBatchElement & BatchElement, const FDrawingPolicyRenderState & DrawRenderState) Zeile 31    C++    Symbole wurden geladen.
     UE4Editor-Renderer.dll!TBasePassDrawingPolicy<FUniformLightMapPolicy>::SetMeshRenderState(FRHICommandList & RHICmdList, const FViewInfo & View, const FPrimitiveSceneProxy * PrimitiveSceneProxy, const FMeshBatch & Mesh, int BatchElementIndex, FDrawingPolicyRenderState & DrawRenderState, const TBasePassDrawingPolicy<FUniformLightMapPolicy>::ElementDataType & ElementData, const FMeshDrawingPolicy::ContextDataType PolicyContext) Zeile 1219    C++    Symbole wurden geladen.
     UE4Editor-Renderer.dll!FDrawTranslucentMeshAction::Process<FUniformLightMapPolicy>(FRHICommandList & RHICmdList, const FProcessBasePassMeshParameters & Parameters, const FUniformLightMapPolicy & LightMapPolicy, const FLightCacheInterface * const & LightMapElementData) Zeile 483    C++    Symbole wurden geladen.
     UE4Editor-Renderer.dll!ProcessBasePassMesh<FDrawTranslucentMeshAction>(FRHICommandList & RHICmdList, const FProcessBasePassMeshParameters & Parameters, FDrawTranslucentMeshAction && Action) Zeile 1578    C++    Symbole wurden geladen.
     UE4Editor-Renderer.dll!FTranslucencyDrawingPolicyFactory::DrawMesh(FRHICommandList & RHICmdList, const FViewInfo & View, FTranslucencyDrawingPolicyFactory::ContextType DrawingContext, const FMeshBatch & Mesh, const unsigned __int64 & BatchElementMask, const FDrawingPolicyRenderState & DrawRenderState, bool bPreFog, const FPrimitiveSceneProxy * PrimitiveSceneProxy, FHitProxyId HitProxyId) Zeile 557    C++    Symbole wurden geladen.
     UE4Editor-Renderer.dll!FTranslucencyDrawingPolicyFactory::DrawDynamicMesh(FRHICommandList & RHICmdList, const FViewInfo & View, FTranslucencyDrawingPolicyFactory::ContextType DrawingContext, const FMeshBatch & Mesh, bool bPreFog, const FDrawingPolicyRenderState & DrawRenderState, const FPrimitiveSceneProxy * PrimitiveSceneProxy, FHitProxyId HitProxyId) Zeile 603    C++    Symbole wurden geladen.
     UE4Editor-Renderer.dll!FTranslucentPrimSet::RenderPrimitive(FRHICommandList & RHICmdList, const FViewInfo & View, const FDrawingPolicyRenderState & DrawRenderState, FPrimitiveSceneInfo * PrimitiveSceneInfo, const FPrimitiveViewRelevance & ViewRelevance, const FProjectedShadowInfo * TranslucentSelfShadow, ETranslucencyPass::Type TranslucencyPass) Zeile 807    C++    Symbole wurden geladen.
     UE4Editor-Renderer.dll!FTranslucentPrimSet::DrawPrimitives(FRHICommandListImmediate & RHICmdList, const FViewInfo & View, const FDrawingPolicyRenderState & DrawRenderState, FDeferredShadingSceneRenderer & Renderer, ETranslucencyPass::Type TranslucencyPass) Zeile 780    C++    Symbole wurden geladen.
     UE4Editor-Renderer.dll!FDeferredShadingSceneRenderer::RenderViewTranslucency(FRHICommandListImmediate & RHICmdList, const FViewInfo & View, const FDrawingPolicyRenderState & DrawRenderState, ETranslucencyPass::Type TranslucencyPass) Zeile 1060    C++    Symbole wurden geladen.
     UE4Editor-Renderer.dll!FDeferredShadingSceneRenderer::RenderTranslucency(FRHICommandListImmediate & RHICmdList, ETranslucencyPass::Type TranslucencyPass) Zeile 1276    C++    Symbole wurden geladen.
     UE4Editor-Renderer.dll!FDeferredShadingSceneRenderer::Render(FRHICommandListImmediate & RHICmdList) Zeile 1314    C++    Symbole wurden geladen.
     UE4Editor-Renderer.dll!RenderViewFamily_RenderThread(FRHICommandListImmediate & RHICmdList, FSceneRenderer * SceneRenderer) Zeile 2749    C++    Symbole wurden geladen.

[anonymous_user_88d57b37]

fixed it by setting bSupportsManualVertexFetch of the VertexFactory to false. Still, I have way worse performance than with UE4.18. I mean, seriously, how is it possible that Epic changes low-level stuff without even telling **somewhere anything **about it? The low-level stuff is not documented at all anyway. This costs so much time and really annoys me.

[ExtraLifeMatt]

@anonymous_user_88d57b37

fixed it by setting bSupportsManualVertexFetch of the VertexFactory to false. Still, I have way worse performance than with UE4.18. I mean, seriously, how is it possible that Epic changes low-level stuff without even telling **somewhere anything **about it? The low-level stuff is not documented at all anyway. This costs so much time and really annoys me.

From the 4.19 patch notes:

Vertexbuffer Objects now bind their SRVs directly instead of filling out a StreamDescriptor. Care must be taken when the Vertexfactory is initialized before the VertexBuffer as the bound SRV will become invalid if the underlying vertexbuffer is re-created. We do not support late binding of the data anymore.

[anonymous_user_88d57b37]

@ExtraLifeMatt

From the 4.19 patch notes:

Okay, but still, it is hard to find and there are no deprecation warnings etc. Besides, after moving to 4.19 I get very poor performance for my paper2D sprite renderer (see image below). In fact, the “SpriteProxy GDME” has increased by factor 100. Does anyone know why that is?

[anonymous_user_b58cf9e8]

Trying to generate project files against 4.19 I get:

error CS0122: 'UnrealBuildTool.BuildConfiguration' is inaccessible due to its protection level

This is from a plugin bulid.cs with the following code:

Path.GetFullPath(BuildConfiguration.RelativeEnginePath)

It seems UnrealBuildTool.BuildConfigiration is no longer accessible from build.cs files? What is the correct way to get things like RelativeEnginePath in 4.19?

[kamrann]

@anonymous_user_b58cf9e8

It seems UnrealBuildTool.BuildConfigiration is no longer accessible from build.cs files? What is the correct way to get things like RelativeEnginePath in 4.19?

They’re exposed as properties on the ReadOnlyTargetRules Target argument instead.

[anonymous_user_b58cf9e8]

@kamrann

They’re exposed as properties on the ReadOnlyTargetRules Target argument instead.

Awesome, this is the solution. Thanks!

[Almost-Famous]

If upgrading a project to 4.19 and your project uses FVariant (Runtime/Core/Public/Misc/Variant.h) be warned that EVariantTypes has finally been converted to a proper enum class (was previously a collection of namespace-scoped constants). Any switches using the GetType() on an instance of FVariant will need to be updated accordingly to handle an enum rather than int32 constants.

[muchcharles]

My issue with constant rebuilds seems to be from my project switching back and forth from the VS 2015 toolchain to the 2017 toolchain. I turned on -verbose on UBT and I see this when it happens:

2>UnrealBuildTool: VERBOSE: Module.Core.2_of_9.cpp: Produced item "Module.Core.2_of_9.cpp.obj" was produced by outdated command-line.
2> Old command-line: F:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\bin\amd64\cl.exe @"E:\git\UnrealEngine\Engine\Intermediate\Build\Win64\UE4Editor\Development\Core\Module.Core.2_of_9.cpp.obj.response"
2> New command-line: E:\Program Files (x86)\Microsoft Visual Studio\2017\Community\VC\Tools\MSVC\14.13.26128\bin\HostX64\x64\cl.exe
@"E:\git\UnrealEngine\Engine\Intermediate\Build\Win64\UE4Editor\Development\Core\Module.Core.2_of_9.cpp.obj.response"

I generated the engine files with:

GenerateProjectFiles.bat -2017

And my game project has:

[/Script/SourceCodeAccess.SourceCodeAccessSettings]
PreferredAccessor=VisualStudio2017

in DefaultEditorPerProjectUserSettings.ini

Any ideas on what could be going wrong?