Update 1: Lumen still performs poorly - disable it if you want FPS use the old methods.
According to my test in preview, reflections became faster but Lumen GI increase by 2x the cost and TSR gained a ms. Regular non-Nanite geometry gets drawn faster by .20ms which is cool but all this does nothing for performance and just stagnates it(unless you don’t use Lumen GI and TSR).
I will be porting that test to 5.4 stable.
It seems that translucent shaders set to forward shading are totally broken in UE5.4.
I had a scene in UE5.3 which had subsurface on translucent objects for curtains that were forward shading, and they work fine.
I migrated this over to UE5.4 and they are just totally white and completely blowing out the bloom, so yes very broken, I even removed everything from the shader and it was still broken when set to forward shading, set it back to deferred and it was fine, unfortunately many shaders require forward shading on translucency, the material editor also gives me an error if you try to use the noise node, and breaks the shader, this also worked in UE5.3.
I am sticking with UE5.3 for now as it seems way more stable, disappointing as I held off getting 5.4 until the official release as I know there can be bugs in the preview versions.
Thank you. Actually its slightly faster than 5.3.2, which is great.
But a lot of trouble will bring the brand to its knees. It would be nice to start solving bugs and tools rather than adding new things and it is advisable to test it through QA. I prefer not to mention your beta and experimental features. E.g:
After loading a custom scheme in the UI editor, some shortcuts stop working, such as Ctrl+E, and the editor must be restarted. Especially when a person switches between level design/scripting and art, it’s quite irritating. The projects are growing, but the work in the editor is slowing down. And not everyone automates everything in Houdiny.
after content migration, the content will stop being displayed in the browser. When cleaning a larger project and backing up content, it is quite bad. Especially when the team buys a lot of assets for the store. Sometimes it is even necessary to restart the editor so that the content can be deleted afterwards, since it is not displayed.
The display filter in the content browser is always reset to its default value after closing it. It is enough to close it, open it in a sheet and give “undocking”. I know a lot of developers who have a content browser in the third monitor, which is turned vertically (same as me). Which is quite a problem.
Meshes that have Nanites on, I always export Fallback meshes to FBX. If the mesh that exports has many times in the scene and turns off nanite, the FPS is down.
also unoptimized Interface. Eg. very complex material - editor splines will easily take even 20 FPS in the editor, which is quite frustrating at 40 fps (minus 20).
sometimes the editor randomly crashes through DX12 when I want have cube reflection actors to the scene in the case of Lumen. The reason is that Lumen is turned off on Medium settings and those reflections are needed in the scene.
Packed Level Actors are great, because UE have not prafab system. But its still only on half way.
In UE 3 was a nice mod to display the overridden properties of the actor in the level. Now, if someone turns something off (eg. “include Actors in HLODS” or physics), whether due to their own inattention, a test or your changing features, they will no longer find it.
There was a problem with the decals. Thanks a lot for the fix, I haven’t tested it though.
Unreal Engine Issues and Bug Tracker (UE-127057)
However, it took you 3 years to solve this bug, especially when there is no vertex paint in the editor for Nanite meshes, although people in your company knew about it. Therefore, there is no reason to trust you anymore.
I would also be quite interested when Nanite will be available for skeletal meshes? You promised it three years ago… Basically, now you have hybrid mumbo jumbo, which confuses a lot of people… It’s a shame, especially when Unreal was quite based on the tools and comfort of the developers who worked in it. And there are a lot of problems with the engine, instead workarounds are constantly invented, which are disguised as “new workflows”. Game development is not an easy thing, and you really haven’t been making it easy for the last three years. There is loooots of problems, and this is only few of them. Now its just a mess. The problem is that people are now fixated on your workflow, which seems to me that you are not even clear about it and how many times you discover it (Matrix without leaves, Valley with only rocks, Electric Dreams as a beta test of the material system, which does not work very well use in production.)
Anyway, fingers crossed. Waiting for 5.5 (another six months)
Nanite Skeletal Mesh exists, if you build from source code (5.5 pre pre). But extensive testing has not been done yet.
So, its not for production. Thanks.
unable to compil my project due to this error : Ensure condition failed: !NavCollision->IsDynamicObstacle() [File:D:\build++UE5\Sync\Engine\Source\Runtime\Engine\Private\Components\SplineMeshComponent.cpp] [Line: 917]
Excuse me but what’s with blatant lie here? : https://youtu.be/ltQfA5Wqdik?t=136
Last time I checked, TSR became 1 ms MORE expensive
Thank you for sharing your impressions!
In 5.3, we added support for 16bit VALU operations on windows D3D12 SM6 capable hardware with r.TSR.16BitVALU. TSR is the first technology in unreal engine to extensively uses these 16bit ops. And we learnt the hardway that there was some unexpected driver bugs we discovered on desktop as well.
To mitigate the impact these 16bit bugs had on the functions of TSR, in 5.4, we added control to enable 16bit VALU operations on a per HIV basis as the issues got ironed out with this change that adds distincts r.TSR.16BitVALU.AMD, r.TSR.16BitVALU.Intel, r.TSR.16BitVALU.Nvidia, all disabled by default.
Subsequently to this change, AMD poped out a fix in their driver we vetted and as a result enabled backed 16bit ops on their hardware by changing that r.TSR.16BitVALU.AMD’s default in this change.
Intel has also been very responsive, hunting down the issues they were having in drivers. But in addition to drivers changes, they also found an issue some of the TSR shader were having in regards to a specific behavior DXC alllows on reordering some of these 16bit operations in the DXIL which the driver consumes, which we have fixed for 5.4 along with enabling r.TSR.16BitVALU.Intel by default as well with this change. Intel has also contributed back to us some new shader permutation in TSR to specifically optimise it on intel Arc GPUs with these changes:
Sadly, at the cost of TSR perf on Nvidia GPUs, we are still waiting a driver fix from Nvidia that caused a total corruption on RTX 20xx series GPU, so as of 5.4.0, the 16bit ops remains disabled by default on nvidia GPU to ensure TSR to at least works consistently compared to other hardware manufacturers and platforms due to r.TSR.16BitVALU.Nvidia being disabled by default. Our hope is to have a futur driver from Nvidia with the necessary fixes so we could change this default in futur hotfix of 5.4 to use on their hardware these exact same way more optimised TSR shaders as we do on consoles.
with almost no improvement to its handling of motion and temporal fizzing(becuase it uses too many frames)
5.4 comes with the history resurrection enabled by default on Medium anti-aliasing quality and higher enabled by default that will allow to remember some of these details showing up again in the scene, allowing much greater depth complexity in scenes in motion.
Also we understand not every project or user have the same needs as the engine default. Even Fortnite have some tweaks due to its competitive nature. So for 5.4, we have spent a lot of time investing in brand new TSR innerworking visualizer, and along side a completely updated documentation and FAQ to better flush out the technical details of TSR and how to tune and execute it to your project’s needs on all the supported platforms.
Since we’ve last spoken I’ve done a lot more research on temporal solutions/designs have come to a rather fond of unexplored territory regarding a couple of requisites TSR doesn’t follow.
The problem in the industry is TAA/Temporal upscling is either too expensive or to poor visually. I’m not sure if you have ever heard of the term “Circus Method”. It’s derived from a joke among gamers regarding the hoops in order to achieve good image quality but is now one of the major methods. An example of this is say 1080p DLAA is going to be a lot more poor in motion vs 4k dlss performance(1080p) becuase of a 200% buffer. You can do the same with XESS 3.1 and you’ll find the same results.
The reason why is becuase a 200% buffer can hold pixels in a more appropriate place before downscaling, this mitigates OLPF(blurred) edges on moving objects. TSR uses too many frames becuase it’s reconstruction derives from getting that information from past frames via multiply jitter sequences(and now history resurrection). More jitter=More past frames=More chance to screw up and more to computation to keep that long array of information in check/from ghosting
Recently, DLSS and XESS have become much better in motion becuase they throw out past frame information much quicker and researching their output, their models have basically reverted to spatial upscalers but since they are not hard coded spatial upscalers and just AI based, they suck up too much power.
A better approach that would hurt performance less and give better results in motion(more important than stills) would to jittering conservatively to only sample thin undersampled objects and specular. You can do this with one frame using the Decima Jitter and use SMAA for stair aliasing edge detection. Then spatially upscale, on the current frame checkerboard the spatial upscaling influence from the last frames upscaled frame.
Unreals TAA/U, FSR2/3, also has the problem, it allows to many frames and we have no variable that can control how exponentially(currently linear) fast past frames are translucent over time. And that’s becuase the jittering is abused for 4 different issues(thin objects, specular, stair edges, and pixel crawl).
Also we understand not every project or user have the same needs as the engine default. Even Fortnite have some tweaks due to its competitive nature.
Yes, I and I find that no game using TSR or unreals TAA proving these are okay software designs. They have serious flaws that have been neglected for years and other rendering aspects have been abusing these flaws for years as well. This creating a false illusion of optimization and I and thousands(not on this site) of others are tired of current gen games produced with unreal being built around broken AA/upscaling.
DLSS is not an viable option for industry even though at the moment circus method combined with the newest dll is arguably the best temporal solution in motion, it’s a brand feature and a overrated one.
I will not being using Unreal as Epic provides it, there are too many problematic shaders and designs and no one on the Epic Developer teams seems to even care about this giant AA issues(unless your willing to review the topic with me).
TSR as of now, brute forces through issues of TAAU. Maybe TSR is viable on console due to the extremely lower cost, but like I said it’s still going against requisites for motion clarity making it a poor choice to what is possible.
EDIT: Again fix the documentation on Nanite Epic, I can have a landscape of small triangles grass and nanite will blow it up, nanite only helps scene with insane overdraw or billion meshed scenes:
With an AMD 5700XT under Win 11 and current drivers, still invisible mesh when using Nanite Tessellation. It’s really sad…According to the FAQ, the card should be supported, right?
We’re trying to track this down - what OS version are you all running?
Passed your feedback to the team and they’ve logged it. Thanks!
The new pricing does not apply to the 5.4 Preview, but does apply to the 5.4 release and beyond, and is inclusive of GitHub branches.
Can we please get an official comment on the absence of the MetaHuman blueprint component in UE 5.4?
According to the anim team, the hip control should show if you swap to the IK spine.
It’s not showing with the FK at the moment, and this is inline with how the MetaHuman rigs work. That said, it’s experimental and we anticipate significant updates so this behavior could change.
I’ve reached out to them and am waiting to hear back.
Updated my project to 5.4 and encountered a lot of issues mostly with PCG. Generating PCG in editor/in game in 5.3 was almost immidiately, in 5.4 it takes several times longer makes it really problematic on large surfaces. Also there was some changes in PCG nodes, after make it work I noticed that “select points” node have weird ratio scale, like divided by 100 or so. Had to change from 0.2 to 0.002/0.004 to make it affect anything. Also combining “select points” node with a “difference” makes it lose some of points at the end, i have not had this problem in 5.3. Tested only in editor, in 5.3 packaging takes few minutes, in 5.4 after more than hour of packaging i get error at the end 
Have to stay with older version for now.
macOS Sonoma 14.4.1 (23E224)
Sonoma 14.4.1 - same as @mehmetbarslan
M3 pro.
Interestingly closing down the editor and restarting seemed to fix my shader issues?
I am not sure what happened but upon first opening my migrated content, lots of shader related content was broken, but reopening everything just seems…ok.
My only thought is perhaps some shaders hadn’t compiled completely or not everything had loaded before I started to open assets perhaps?
UPDATE: No… things are still broken here is a screenshot, what is happening here? Because this works perfectly fine in 5.3 unless I migrate it over to 5.4 where it breaks.
UPDATE 02: I had to do some shader work but managed to fix the noise node breaking in 5.4, I was using a component mask before it got to the noise node, bizarre that this works in 5.3 but not in 5.4?!
But the shader is STILL bright white and broken if it is set to forward shading even with everything in the shader removed.
What I have done to get around this, create a new shader, simply copy over all the nodes from the migrated shader into a the new one and put all the settings in the new shader to match the old one, and it works fine. But still the migrated shader is broken somehow? So something weird is going in with migrating from 5.3 materials over to 5.4, god knows how bad this could be if I had a huge project with lots of materials to move over, In hindsight I would probably dupe the project and change its engine version instead, that might work perhaps?
