Unreal Engine 5.8 Preview

That would be because something is wrong with your setup or source data and you are missing the render mesh.
The tell sign is your thumbnail showing the new orange and blue render of sim only cloth assets.
No render mesh means there is nothing to render in the simulation view, or in the level where the asset will be used.
The construction view will also show no render mesh there if you click on any node and check the Render view.

Prior to 5.8, this would error out in your Dataflow, since a Cloth Asset without a render mesh was pretty useless. However, in version 5.7, we added the ability to use SIM-only Cloth Assets as Clothing Data in the Skeletal Mesh workflow. Our customers then requested the ability to use sim only meshes in this workflow, which is why removing the no-render-mesh error reporting and making sure the thumbnails correctly render these asset have been added as new features in 5.8.

1 Like

Can someone explain how to build it? I ran setup and generateprojectfiles and those ran fine. But I can’t open the solution in either VS 2022 or 2026. It says the project files are incompatible.

I can’t create the Media Output assets, they are just not available in the context menu like the source assets:


It seems to be related to the class here being abstract as opposed to the sources:

UCLASS(Abstract)
class UAssetDefinition_MediaOutput : public UAssetDefinitionDefault

vs

UCLASS(MinimalAPI)
class UAssetDefinition_MediaSource : public UAssetDefinitionDefault

I was able to start compiling, but the InterchangeOpenUSDChaosClothAssetImport module produces file paths that are longer than 250 characters. Even with long filename enabled, it still can’t open the file.

edit: If anyone runs into this problem, open the InterchangeOpenUSDChaosClothAssetImport.Build.cs file and add this before the PublicDependencyModuleNames.AddRange line:

	ShortName = "USDCloth";

Note that you should also keep your main folder path really short if you want to avoid this all together.

Runs excellently. Significant performance improvement from 5.7.4 for VR

2 Likes

Input mode behavior has changed yet again. Worked perfectly in 5.7. Now I have to double click any time it switches back to game mode. Worse part is I have no clue how to fix this. I’ve been updating this behavior since 4.X, but this time I’m stumped.

Also, stat fps and stat unit has been removed from the viewport in the editor. Not sure why this was done.

Performance in 5.8 is atrocious. Completely unusable. I have a RTX 5080. In 5.7, I was getting 150-250fps in my game. Now it’s barely above 70fps in 5.8. I have a tower defense game. So at times, I have a lot of actors active. Performance absolutely tanks. And my suspicion is that anyone using object pooling will be in for a huge surprise. I think 5.8 has overhead per actor, even in inactive actors in an object pool. The reason I say this is because disabling Lumen doesn’t even increase framerate.

edit: Yeah, 5.8 is VERY buggy. I ran a trace and it’s showing that animation blueprints that are disabled are still active and it’s ignoring SetActorTickEnabled() and just calling tick anyhow. Doesn’t care that actors are invisible, can’t tick and animations are disabled. It bypasses all those settings and behaves as if they were all active. Tick is disabled on all components, but it ignores that and ticks away on components.

Also, I have a planar reflection that is supposed to only get used when Lumen is off. In 5.8, it doesn’t care that it’s disabled, it is in the rendering pipeline anyhow.

What a mess 5.8 is.

edit2: Looks like the tick issue is there in 5.7 as well. So that’s not the cause of the slowdown.

edit3: When you press ā€œPlayā€ in editor, the editor window changes size. It’s very annoying.

I was able to disable the tick events, collisions, character movement, animations, etc. from disabled actors more forcibly (by unregistering those components and reregistering when re-using actors) and fps came back to what it should be. Seems 5.7 is a bit better at ignoring disabled actors in an object pool.

edit4: Update on mouse capture when setting input config. 5.8 has broken the use of EMouseCaptureMode::CapturePermanently_IncludingInitialMouseDown. On 5.7 and earlier, it was EMouseCaptureMode::CapturePermanently that was broken, but it acted like the previous option. So I’d set IncludingInitialMouseDown in the project settings and used CapturePermanently by itself in the code. In 5.8, I think they fixed CapturePermanently, but also broke IncludingInitialMouseDown since they both act identical now. As it is now, 5.8 is unusable for me. I have to click twice every time I go back to game mode. I’ve tried all sorts of thing to give focus to the viewport without success. This was the usual solution in the past. It doesn’t work in 5.8. It’s just broken.

edit5: It’s not actually the input mode. Seems it’s related though. In 5.8, it appears it was changed so each mode keeps its own input queue. Because I was activating UI mode during mouse down… when I want back to Game mode, mouse down events would be ignored until it received a mouse up causing any code that activates on mouse down to skip every second mouse down event (if mouse down activates UI mode).

2 Likes

Hi team,

Like many here, I look forward to every new Unreal release, both for the new features and in the hope of seeing some long-standing VR/XR bugs finally addressed, especially the ones that show up as soon as Instanced Stereo is enabled.

Since 5.4, it feels like a bit of a moving target: some features work on one version, then break on the right eye in the next, and 5.8 doesn’t seem to fix them either. I’ve patched a few of them locally on my side, but I keep stumbling onto new ones.

A few concrete examples:

https://forums.unrealengine.com/t/bug-in-vr-since-5-6-and-5-7-preview-with-instanced-stereo-baked-reflection-capture-deferred-rendering-post-process-volume/2660169/5

https://issues.unrealengine.com/issue/UE-347065

And one I ran into more recently: custom mesh voxelized fog volumes also fail in VR with Instanced Stereo.

Some of these can actually be fixed quite simply, several are tied to this PR which broke a number of things for VR, and I’ve left a comment there explaining the fix:

https://github.com/EpicGames/UnrealEngine/pull/12854

Others will probably require deeper changes on the C++ side, but at least a few are low-hanging fruit.

I’ve reported several through the issue tracker, but unfortunately none of them have been picked up so far, and without feedback I’m not sure if they ever will be.

I totally get that VR/XR isn’t the hottest topic right now, but it’s still a really important platform for a lot of us, and these bugs are genuinely painful to work around. Would love to see a small dedicated pass of testing and fixes on the VR side in a future release. :folded_hands:

Thanks for all the great work in the meantime!

5 Likes

Thankyou! I was struggling to figure out where to put the material!

1 Like

My sound is OK now, Ultra Dynamic Sky’s recent update fixed the issue in 5.8. Hopefully preview 2 fixes your issues.

This is great to know, can you shed more light on the performance increase and setup?
How significant is it?
Forward shading vs deferred?
Lumen vs. baked?
Nanite on/off?

Please fix EMouseCaptureMode::CapturePermanently_IncludingInitialMouseDown Input Config. I can live with the rest, but having this broken means 5.8 is unusable. Or let us know how to give focus to the viewport in a way that actually works.

This doesn’t work:

LocalPlayer->ViewportClient->Viewport->SetUserFocus(true);

This doesn’t work:

FSlateApplication::Get().SetAllUserFocusToGameViewport();

This doesn’t work:

  if (LocalPlayer->ViewportClient && LocalPlayer->ViewportClient->GetGameViewportWidget().IsValid())
  {
    TSharedPtr<SViewport> ViewportWidget = LocalPlayer->ViewportClient->GetGameViewportWidget();
    FSlateApplication::Get().SetUserFocus(0, ViewportWidget.ToSharedRef(), EFocusCause::Mouse);
  }

Note that I’m using mouse up (on a button) to switch to game mode. But I think the next mouse down is what actually caused the capture. I could be wrong. Either way, I’m finding it impossible to get 5.8 to work correctly and avoid double clicking. It worked perfectly in 5.7.

edit: I’m going through with the debugger. Seems the problem is that input actions based on the mouse are giving a magnitude of 0 on mouse down every second time.

This is what my action is. It’s the same for controller buttons and everything else that’s either on or off.

Weird thing is that rotation (activated by right mouse) is exactly the same and that works fine.

edit: Looks like Game mode and UI mode keep separate Input queues. I switch to UI mode on mouse down. When I go back to Game mode, it still hasn’t seen a mouse up. So the mouse down is completely ignored. It does not trigger my input action at all. When I do a mouse up, I do get the mouse up event. This is what made me think it was alternating. This is different than 5.7. I think I could make my popup activate an mouse up instead. I’ve tried various methods to clear out the input state when switching modes to no avail.

edit2: Found a fix. Since there is still an action in the queue, we must remove it. If you have a similar problem where you’re switching modes on a mouse down event, try this when switching modes:

  // fpc is PlayerController.  Use GetController<MyControllerClass>();
  if (fpc->PlayerInput)
  {
    fpc->FlushPressedKeys();

    if (UEnhancedInputLocalPlayerSubsystem* EISubsystem = ULocalPlayer::GetSubsystem<UEnhancedInputLocalPlayerSubsystem>(LocalPlayer))
    {
      FModifyContextOptions ContextOptions;
      ContextOptions.bForceImmediately = true;
      ContextOptions.bIgnoreAllPressedKeysUntilRelease = false;
      EISubsystem->RequestRebuildControlMappings(ContextOptions, EInputMappingRebuildType::RebuildWithFlush);
    }
  }


edit3: It doesn’t actually have separate input queues like I thought. It’s that my input actions are only in Game mode. In UI mode, it uses the button’s OnClicked event and a CommonActionWidget for controller buttons. It doesn’t use the game mode input actions. It uses an input table instead. Still not sure why it behaved differently in 5.7 and earlier.

I do have an issue with this release, actually a few

  1. Forward Renderer has an Acid Trip ā€œSubstrate is causing issuesā€
  2. Toon shader for Toon characters that are low poly causes a 50-80% decrease in performance in a ā€œEmpty Scene with Nothingā€ No lights, Pure Black
  3. Insane compilation, worse than before
  4. Zen Server causes shader corruption.
  5. I expect this engine version will crash more than the last engine version

You should investigate the problems, i have dialed it down to just certain poor implementations of features overloading buffers that causes the engine to crash as it is trying to access invalid objects in memory, this has a been a problem since Unreal Engine 5.0 and has still not been fixed, hence the massive amount of Crash Reporter windows most people experience working with UE5

1 Like

Wasn’t really able to find the bug tracker for this. So i’ll just ask the community. On linux seems like all context menus stopped working with the mouse after downloading 5.8. Arrow keys and keyboard shortcuts seem to still work however. Anyone know if this is a known issue or not?

Aware of the wayland issues.. Not affecting me. I’m sticking with x11. Also got the launch flag and windows rules set in just in case. Complely nuked my config and shader chach. Rebuilding that now to see if that helps.

I assume you’re referring to Viewport Scalability ?

I’ve got a new problem with 5.8. I can’t stop my project from rebuilding 4000 files from the engine every time I compile my project. I’ve rebuilt the source and my project (including deleting intermediate, saved, binaries folders) and no luck. It just keeps rebuilding everything.

edit: I’ve ended up rebuilding the engine 9 times today. Takes almost 2 hours each time (or 1 hour if it only builds the ShaderCompilerWorker). This is on a 9900X with SSD. My machine has been non stop building. Keep hoping it would eventually stabilize, but no. I’m giving up on 5.8. It just has too many flaws right now. It’s not anywhere near being production ready.

From what I can tell, if any setting is different from your project and the engine, it rewrites the SharedDefinitions.Core.Cpp20.h and rsp file every time you start a build. Then it sees that there’s a new rsp file and decides to invalidate the makefile for the engine. Now, this one can eventually stop rebuilding if you don’t touch anything. But the same thing happens for the ShaderCompilerWorker. The problem is that ShaderCompilerWorker wants to be built every time no matter what. I haven’t found a way to stop it from rebuilding. And it rebuilds 4000 files no matter what to build ShaderCompilerWorker. 4000 files is better than the full 8000 files. But it’s still almost an hour. Then if you want to build the original engine, it sees that your project modified those headers and then rebuilds everything again.

So the only way to have half a sane environment is to not build the engine at all. Just build it from your project’s solution. Just don’t change anything in your project settings. If you change just one thing in any ini file, EVERYTHING rebuilds.

Can’t confirm that, I’m building from 5.8 source too and I’ve got a ton of custom code and plugins with cpp code. It’s been the same as 5.7 and before. Sure, every now and then it thinks it must compile the engine, but that happens maybe once or twice a week, and not every single time and has been like that for ages.

Have you updated Visual Studio? What’s your VS version? I’m on VS 2022 Community.

Found yet another problem. It seems they changed how the editor starts up. In the past, you could set it to DebugGame Editor and debug it from the start in visual studio. That doesn’t work in 5.8 anymore. You have to attach manually. This means you can’t debug your project if it crashes on startup.

edit: Found that it’s getting confused as to which version its using. It seems to think my project was built with a different UE version even though it did build with the correct source. When I forced it to switch to my current source build, nothing rebuilt but I can now debug directly. That it didn’t rebuild was shocking, but hopefully this will solve the constant rebuilding issues.

Problem is that my project is now crashing trying to load embree4.dll. No clue why this is happening. Last launch worked fine. Launch a second time with zero changes and it can’t find embree4.dll that’s sitting right there in the binaries folder.

Oh, and for everything that is holy, NEVER disable hardware raytracing. If you do, you will NEVER get your project running again. No amount of clearing folders, caches, etc. will save you. Restoring the setting manually will actually make it worse. Just start over from scratch.

edit2: FastAllocatorPage is not working correctly. So this ends up breaking the lumen card generation. I’ll try using the windows allocator instead.

VS is fully updated. I can only use VS 2026. If I use VS 2022, it says the project files are incompatible. In both VS 2022 and 2026, I used to get a dialog that the project files were incompatible. But now that I’m using Switch UE Version instead of Generate Project Files in file manager, I can open my solution in VS 2026 directly. I suspect there’s a versioning issue somewhere and this is likely the cause of all the rebuilds I’m getting. But now my project keeps crashing building lumen cards, specifically in the FastAllocatorPage.

I’m going to start from scratch yet again. What I really hate is that if you build a personal project, it changes the files in the main UE source folders. So if you go to build the main UE editor, it rebuilds everything. Now that I know this is what it does, I can at least keep all my compiling from my personal project. The downside is that I have to build the entire engine twice from a clean build. It’s very annoying.

edit: I rebuilt everything from scratch and it’s still doing the same thing. It compiles 4000 files to build ShaderCompilerWorker. I’ve never had this happen in any other version of UE.

edit2: Here are some of my findings. Maybe it’ll help someone if they run into the same issue. Do NOT install the VS2022 (I think it’s 143) in VS2026 if you also have VS2022 installed. The UE build tools get very confused.

I also found out the project files are indeed VS2026 project files. So UE 5.8 is made for VS 2026 but use the VS 2022 compiler. The problem here is that the normal course of action is to use VS 2026 and install the 2022 tools with 2026. And maybe it could work if you don’t have VS2022 installed. Point being, only have one v143 build tools installed.

VS 2022 cannot open these project files. I tried forcing it to use VS 2022 project files and got a bunch of errors that .NET 10 wasn’t supported and a bunch of stuff could break.

So I removed the v143 build tools from VS2026 and I’m now rebuilding everything from scratch for the bazillionth time.

1 Like

The fact that the build system (when building your own project) alters files in the engine’s source folders is just plain evil. Not only that, but it seems impossible to restore a proper build. Seems to cache settings somewhere outside both the project folder and the engine folder.

edit: I found this setting that helped a LOT. Add this to your editor.target.cs file:
BuildEnvironment = TargetBuildEnvironment.Shared;

You’ll need to delete the .vs, Intermediate, Saved and Binaries folders in your project. Then regenerate the project files on your .uproject file. If you use the render queue, backup your images from the saved folder first.

I had to do this a couple times and my project finally built without rebuilding the engine. It didn’t even try to rebuild ShaderCompilerWorker. But I think this setting ignores any local settings in your project that differ from the way you built the engine. So I think I still have settings cached somewhere that I cannot figure out where they are and are overriding my project settings.

When enabling Megalights in a new TPS project, the engine returns an error. RTX 4060, i5-13400, 32GB RAM.