Unreal Engine 5.5 Preview

Please, make QA tests for VR. I can’t understand why it’s a so ignored technology.

I’m sure you have the money to hire a QA team.

Thank you very much.

2 Likes

Upgraded M3 mbpro to sequoia and this thing started happening:

VSM shadows, i did enable hwrt but that’s probably not doing anything since it’s not supported apparently.

I think for the advanced enhanced input its “advanced” your over looking. Currently the only way to add input outside of xinput devices or support controller types is via third party plugins that do NOT use enhanced input and use legacy because it allows device -id’s to be tied to the input controller and key event bindings. Something that EIS doesn’t currently support. Even the legacy way of handling is tedious requiring you to know the device you need to support in advance. (think racing wheels, 3rd party controllers, bluetooth devices, more than 4 controllers) and don’t even get me started on the difficulty getting steam input and unreal PIE/testing to play nice in its current state.

paper2d and paperzd doing “pretty much everything unity can do” is a bit of a stretch. I’ve just finished the 2D skeletal tools plugin to fill “1” gap in the 2D toolbox of UE5. Its currently built on the new skeletal editor because unreal doesn’t have a 2D bone system understanding and also without heavy modification couldn’t treat sprites as meshes to weight to those bones… So I created tooling that did just that. There are indeed many more areas that could use improvement here. They covered this topic quite extensively in the Myth buster series on Day 2 of Unreal Fest 2024 livestream.

I love unreal engine. But I will provide constructive feedback and personally contribute by creating new tools and adding PRs to source to make the thing I love better. Downplaying something in defense of something you care about is a double edge sword. While I’m not validating all of the things mentioned… I definitely do not want to downplay actual issues so they will continue to get the attention they deserve to become an actual 1st class high quality feature and not something stuck in beta/experimental for over 4 years.

Please please PLEASE we have been trying to upgrade our pipeline to UE5 for two years now! Can you please just fix the shadow bug linked above and make VR usable :frowning:

2 Likes

Enabling PCG plugins on a Windows shipping build results in a fatal crash when running the app.

1 Like

I’ve updated the forum with the current findings for 5.5 preview.
UE5.4 (and 5.4.1) shadows are broken in VR (VR Template, default settings) - General / Issues and Bug Reporting - Epic Developer Community Forums (unrealengine.com)

I thought VR was already made available?

What do you mean made available? Its been in the engine since UE4 its been bugged in some way (openxr updates, meta → oculus transfer, plugins, shadow casting) since UE5.0

On a side note they may want to fix the engine.ini for the VRTemplate also.

r.AntiAliasingMethod=3
r.SkinCache.CompileShaders=True
r.RayTracing=True

Pretty sure this is the reason for the solid white screen in forward rendering.

Go grab the ini from UE5.4 Template and you’ll see r.Raytracing and skincache is not an entry and removing and build->rebuild all corrects the issue.

1 Like

Currently anyway to enable new lipsync at runtime? C++?

Oh, I thought that they would have ironed out those bugs, by now. Since who wouldn’t enjoy an good VR game?

(post deleted by author)

Any news on Support for Apple Vision Pro?

Support for VisionOS 2.0 (Experimental) is listed on your Roadmap for UE 5.5, but with this UE5.5 Preview 1 the Vision Pro SDK is still missing…

I can confirm that issue. While holding right click and moving around, after releasing the right click, editor gets a huge performance hit caused by Slate HitProxyReadback for a few frames, which causes lots of microstuttering.

Is there any response from Epic for that? Editor is plagued with that problem since 5.4 release.

I tracked this down to FViewport::InvalidateHitProxy getting spammed when the scenario above happens. I will update if I can figure out why hit proxies are invalidated continuously for a second or two after releasing right click.

3 Likes

Any info on how to input data to the ‘UserSceneTexture’? I do love that we finally get a custom Gbuffer mask without needing a graphics programmer, so am eager to play but aside from the output node I am unsure how to define its input?

There’s a lot of stuff that causes lag spike nowdays. :sweat_smile:

  • Right click on actor to open toolbar = performance hit
  • Left click to select another actor = performance hit
  • Move actor = performance hit
  • Or the moving around then releasing right mouse situation I mentioned

I assume there’s some heavy calculations going on for which game thread waits

I’m not sure if it’s bug or just engine getting heavier,

it likely could be resolved by some multi-threading loading implemented just like it was implemented action list when you right click in blueprint graph. Although it’d take bit of effort to implement by awesome unreal devs.

So that perhaps engine can display loading icon instead of freezing whole editor because list of properties for actor is taking long time to load😅

1 Like

Update on editor fps drop issues while right click is held and released on viewport:

We narrowed down issue the issue to HitProxy calculation logic while editor camera is flying. There is a code piece where editor stops updating hit proxies while you’re flying with camera (because technically you can’t click on actors while flying with camera). The problem is, when you stop flying (aka, stop holding right click), the camera still moves a little bit with deceleration. During this deceleration, HitProxies gets invalidated each frame until camera is fully stopped, which causes huge cpu spike.

We solved this with a workaround in Editor/UnrealEd/Private/CameraController.cpp:

https://github.com/ShadowfallStudios/UnrealEngine/commit/85798d0f9d7378f7d3d41f9f31cf22340c42abfd

If you cannot access the link, here is the actual patch:

This patch makes camera stop immediately after you stop providing an input. Not a good solution, but still better than fps drop.

You’re welcome! I’m glad the Megalights helped you out. Dealing with interiors, especially in tight spaces, can be a challenge. If you have any more tips or questions, feel free to share!

This issue Orthographic camera jitter bug in windows builds will be resolved in the UE5.5 version?

The MegaLights feature looks very interesting. I’m currently working on a little Archviz project using UE Version 5.3.2 and Lumen. The scene uses a lot of standard light sources like RectLights and SpotLights. Can I simply move to Version 5.5 and will the lights automatically use MegaLights or are additional steps needed?