Limiting the framerate with t.MaxFPS or turning off TLV batching usually seems to make the flickering stop (r.TranslucencyLightingVolume.Batch 0)

• The flickering is from TLV only (not happening with forward translucent shading)
• It seems it also happens without Lumen enabled
• The issue may not happen with older Nvidia drivers, eg, 551.86
• {{r.TranslucencyLightingVolume.Blur 0 }} doesn’t appear to affect the issue

This flickering issue doesn’t appear to be the same issue as the kind of flickering that can occur with meshes that intersect the edge of the TLV.

Additional Notes

r.OneFrameThreadLag 0 will kill it. And the render frame has to struggle (lag) for it to occur.
r.rdg.asyncCompute 0 might stop it, but only because the lag shifts a bit. You will still be able to get it with asyncCompute 0, but it just might be harder to reproduce.

The suppression relies on FAnimExtractContext::bIgnoreRootLock, which is WITH_EDITOR-only, so the suppress in FMovieSceneSkeletalAnimationEvaluationTask::Execute is gated behind #if WITH_EDITOR. As a result the mixer's root-motion pipeline behaves differently between editor/PIE and cooked:

• Editor/PIE: the lock is suppressed during eval, real root motion survives, and the extraction task handles locking.
• Cooked: the field does not exist, so the lock is applied during decompression and the extraction task works from an already-locked pose.

This is a runtime system depending on an editor-only lever, so the behavior silently forks between configs.

Repro

• Set up an anim mixer skeletal section using an anim sequence with both Force Root Lock and Enable Root Motion enabled.
• Compare root behavior in PIE vs a cooked/packaged build.

Proposed fix

• Add a runtime (non-WITH_EDITOR) bool to FAnimExtractContext (e.g. bSuppressForceRootLock), separate from the editor-only bIgnoreRootLock so the preview flag's meaning is unchanged.
• Un-gate the three force-root-lock checks (!ExtractionContext.bIgnoreRootLock) currently under #if WITH_EDITOR so they honor the new runtime flag in cooked.
• Set the new flag unconditionally in the mixer eval task and drop its #if WITH_EDITOR guard.
• Default the flag to false so all other runtime paths are byte-for-byte unchanged.
• Add a mixer test comparing a Force-Root-Lock + Enable-Root-Motion section cooked vs PIE.

Key locations

• MovieSceneMixedSkeletalAnimationSystem.cpp (section flag derivation, and the #if WITH_EDITOR suppress in the eval task)
• AnimationAsset.h (FAnimExtractContext::bIgnoreRootLock)
• DecompressionTools.cpp, AnimSequence.cpp, AnimStreamable.cpp (the #if WITH_EDITOR !bIgnoreRootLock force-root-lock sites)

This is due to input being evaluated through the PlayerController's tick, which always occurs later in the frame than the movement simulation.  Use a debugger to break in functions like AMoverExamplesCharacter::OnMoveTriggered and OnProduceInput to how they are called.

Investigate alternatives, such as:

• forcing an evaluation of input just as OnProduceInput is called
• rescheduling the PlayerController tick to occur earlier 
• something else?

• r.OneFrameThreadLag 1
• r.GTSyncType 1

The previous skinning bone data can be corrupted and introduce visual artifacts on everything using motion vectors, motion blur being the most visible.

This is hard to reproduce without specific/heavy content. But has been seen in the wild by several licensees.

Licensees have found that the issue comes from SupportsNoOverwriteBuffers() not being robust. The buffer queue is handled with a tick function, and under certain timing constraints will return a buffer that is still in use to be written to.

The issue was introduced in our 5.6 update with the parallel RHI command translate. (Disabling the parallel translate also fixes.)

You can no longer use controller and mouse simultaneously to control the camera. Previously you could use the left stick on the controller to control forward/back movement and use the mouse with RMB down to control the rotation and get nice smooth flyby controls. Now if you use the mouse the controller inputs stop being considered.

Also there is some kind of change the update or tick rate for the camera inputs and or movement/rotation. It feels like 24fps compared to the nice smooth feeling previously.

You can try setting Gizmos.Version 0 to compare to previous behavior.

Root cause: UHLODBuilder::ComputeHLODHash opens a FHLODHashScope with
EFlags::ResetHash, which calls FArchiveCrc32::Reset() (zeroing the running
CRC) but never restores the previous CRC. Everything accumulated before the
loop is thrown away.

The showFlag.CollisionVisibility 1 cvar is a viewport visualization mode that highlights which Actors will block visibility. The showFlag.CollisionPawn 1 cvar is a Player Collision viewmode which highlights assets that collide with a character or Pawn. In these modes, only the respective collisions are rendered in the viewport.

Problem

The licensee noticed that setting `showFlag.CollisionVisibility 1` in one of their production levels seemed to omit most collision geometry in a Development game build, with `showFlag.CollisionPawn` also exhibiting the same issue. Everything seems to work fine in PIE and when the licensee tried a test level everything seemed fine at first, but then they noticed a select few assets were indeed missing in the collision view. Most of the test level is composed of simple block-out meshes which do not have Nanite enabled, but the pieces with no collision drawn (they do have collision) were production assets with Nanite enabled.

It is the licensee's understanding that the `showFlag.CollisionVisibility` and `showFlag.CollisionPawn` views should work in Development builds of the game, but this doesn't seem to be happening for StaticMesh assets that have Nanite enabled. Since nearly all of their production assets are going to have Nanite enabled this is going to make the collision views in game builds entirely unrepresentative.

QUOTE:
TLDR: Use of 'escape' paths in Uproject's AdditionalPluginDirectories seems to break Visual Studio launches, as well as Zenstore.

Much more detail:

We added a AdditionalPluginDirectories like the code chunk to our MyGame/MyGame.uproject. The important part to note is that it starts with "../" which 'escapes' the MyGame folder. And, we have a code plugin in that directory. This mostly works.

What works: Editor Builds, packaged builds (e..g from our farm)

What doesn't: Win64 builds launched from Visual Studio, Zenstore launches. These are detailed below

1) Win64 builds from Visual Studio fail to launch

Our engineers have a common habit of cooking locally, but not the full pak/stage step. For example, "RunUAT.bat BuildCookRun -project="MyGame/MyGame.uproject" -noP4 -nocompileeditor -utf8output -build -cook -SkipCookingEditorContent -stage -iterate

Then, we launch say Development|Win64 from Visual Studio with default debugging commands. This used to work.

That cook leaves a game\MyGame\Saved\StagedBuilds\Windows\RemappedPlugins folder with the .uplugin folder. If I launch from Development\Win64 from Visual Studio, it fails with a "LogPluginManager: Error: Unable to load plugin 'CompanySharedPlugin'. Aborting."

Debugging this, in FProjectDescriptor::Read(), in non-Editor builds, it adds this path: "C:/path/to/unreal/game/MyGame/Saved/Cooked/Windows/RemappedPlugins" . Problem is, that doesn't exist. The cook above created "Saved/StagedBuilds/Windows/RemappedPlugins" Thus, it fails.

That's with the stock empty (blank) commandline arguments from Visual Studio. It doesn't use that StagedBuilds*\RemappedPlugins folder. It looks like commandline PLUGIN= or setting %UE_ADDITIONAL_PLUGIN_PATHS%, it could succeed, but that requires every engineer to edit things locally.

2) Zenstore launches on platforms fail

This is even more tricky to debug. A zenstore cook of that platform left the artifacts in Saved\StagedBuilds\<Platform>\remappedplugins . Launching from my Platform, it "../../../mygame/../remappedplugins/" to the list of folders to look in.

In FStorageServerPlatformFile::DirectoryExists(), the call to MakeStorageServerPath() turns stock paths into items like "../../../engine/Plugins" -> "/

/Plugins" . That works well, but it might be a code change to find the RemappedPlugins folder.

Yes, I know Zenstore is still under development, but it's been a huge win for Platform iteration.

I've looked ahead to the 5.4 (live snapshot) in Perforce, and I don't see changes to PluginManager.cpp, ProjectDescriptor.cpp that look like it would fix it.

Thanks for your help.

"AdditionalPluginDirectories": [
	"../CompanyShared/Plugins"
],

Here's a snippet of code to add to FProjectDescriptor::Read() that seems to at least fix the Development|Win64 launch. Zenstore for Platforms is likely to need more changes.

		// If this is a packaged build and there are additional directories, they need to be remapped to the packaged location
		if (FPlatformProperties::RequiresCookedData() && AdditionalPluginDirectoriesValue->Num() > 0)
		{
			AdditionalPluginDirectories.Empty();
			FString RemappedDir = FPaths::ProjectDir() / TEXT("../RemappedPlugins/");
			if (FPaths::IsRelative(RemappedDir))
			{
				RemappedDir = IFileManager::Get().ConvertToAbsolutePathForExternalAppForWrite(*RemappedDir);
			}
			AddPluginDirectory(RemappedDir);
 
// BEGIN ADDED CODE
			// After cooking with RunUAT.bat BuildCookRun -project="MyGame/MyGame.uproject" -noP4 -nocompileeditor -utf8output  -build -cook -SkipCookingEditorContent -stage -iterate -platform=Windows
			// and then launching from VisualStudio, by default, right now  RemappedDir=="Saved/Cooked/Windows/RemappedPlugins", but the RunUAT left files in
			// "Saved/StagedBuilds/Windows/RemappedPlugins" . So, add a second search path transparently.
#if !UE_BUILD_SHIPPING && !WITH_EDITOR
			static const FString COOKED_FOLDER = TEXT("/Cooked/");
			static const FString STAGED_FOLDER = TEXT("/StagedBuilds/");
			if (RemappedDir.Contains(COOKED_FOLDER))
			{
				FString RemappedDir2 = RemappedDir.Replace(*COOKED_FOLDER, *STAGED_FOLDER);
				AddPluginDirectory(RemappedDir2);
			}
#endif
// END ADDED CODE
		}