I can confirm that the same is happening for me in a packaged shipping build for both Xbox and PC. Over time, memory usage explodes and crashes my game. There is certainly a memory leak somewhere.
Why hasn’t UE5.6.1 been released yet? It’s understandable that there are bugs in the new features, but the existing ones often fail,even the file format of FBX has problems,installing a new version will affect the same features of the old version, which is difficult to understand and quite ridiculous. With so many low-level errors, shouldn’t you quickly release a version that fixes the errors and better allows users to use it with confidence,
Even uninstalling 5.6 is useless. The original skeleton position of FBX imported with version 5.5.4 will still change, and there will be serious shape alignment errors with Alembic’s cache fabric. Therefore, everyone must remember not to install the new version casually, otherwise there will be bugs and the functions of the old version will not work, this is my lesson,the errors that occur in this engine tool are so unpredictable and almost unimaginable, as many existing conventional functions also fail and cannot be predicted or controlled,this kind of maintenance and review technology capability is quite absurd,,
I’m so tired of upgrading to the new version for fixes. They don’t want LTS, Unity and Blender have it.
I also has this bug with “Array index out of bounds” in my project.
It’s random thing in my case, but mostly related to SkeletalMesh, especially if tried enabling Nanite SkeletalMesh causing insta-crash with Array index out of bounds. But there’s some case with SkeletalMesh without Nanite and still has this issue, in that other case I had to delete the affected SkeletalMesh LOD and regenerate them again after upgrading from 5.5.4.
It also there for me when building HLOD (from commandlet outside of Editor, since from Editor causing shader compiler hang and won’t finished) with Nanite enabled, so I had to disable Nanite from my project config file before building HLOD in 5.6.0.
IIRC this “Array index out of bounds” also present in 5.5.0 back then, hopefully they fixed it in 5.6.1, but seems taking forever to drop..
Retarget Pose From Mesh Copy Curves Option deleted in UE 5.6 !
I’m struggling with that problem too. Sometimes I manage to create a build and sometimes I get this error twice. I’ll leave it now. I’ve opened all the structures. I have added validation to the “:IsChildOf” functions. I have been solving this for three days. For the first time I switched to a new version of UE before the patch version appeared and this is how it ended
To address this longstanding UE issue with corrupted structures open affected BPs (see Output log) and select a function with a structure and right click refresh. For affected interfaces briefly change the structure to something else, then switch back. However, as mentioned if you already upgraded to 5.6 from 5.5 it may turn out that the Output log no longer displays affected BPs. For the time being use 5.5 if you can, otherwise take a look into the logs or check BPs in your project which may be affected and refresh those structures.
Also if you manage to fix these structures, you then could try to upgrade to 5.6, but caution is warranted.
ping @Kikilo
same. still waiting for update…
I’ve encountered a shadow rendering issue in Unreal Engine 5.6.
When using Nanite-enabled trees painted with the Foliage Tool, and Evaluate World Position Offset is enabled in the material, the trees do not cast any shadows, neither direct nor indirect, even with Lumen turned off.
However, if I drag and drop the same mesh directly into the level (with identical material and settings), shadows appear as expected.
This issue wasn’t present in UE 5.5, so it seems to be a regression in 5.6.
I’ve tested all combinations:
Nanite + WPO = No shadows (only when painted)
Nanite without WPO = Shadows work
Non-Nanite + WPO = Shadows work
Has anyone else run into this issue? Is there a known workaround, or has Epic acknowledged this yet?
Just telling people to use an older version is pointless. I upgraded my project from 5.4 to 5.5, confirmed everything worked fine both in the editor and in the packaged build, and continued development in 5.5 for months. Only later did I run into a serious bug with Nav Mesh and instanced static meshes, a bug that wasn’t even fixed in 5.5.4. By then, I couldn’t roll back to 5.4.
I waited months for the 5.6 release, hoping for a fix. They did fix the Nav Mesh issue but introduced a whole new set of bugs, especially with Nanite landscapes and foliage shadows. So telling people to just wait for fixes or stick to old versions doesn’t make sense when every version brings new problems.
i think it’s ok for people who can wait on a version. but i understand your point as well if you feel forced to update. or find an issue later on.
the reality is that it’s risky to update. period. and should be taken with care. we can only ask for epic to improve the reality, but ultimately what’s in our power as creators is to take that choice seriously and with all the risks on the table.
i think an lts is the best solution for these things. otherwise the bugs will never end.
you can vote on that post, the more people vote for it, the more priority epic will give to the topic.
That refers to the Swarm missing issue. I cannot render any updates to my products, due to this… almost 3 weeks to the day and it is still not fixed.
It feels like this release is too early, judging by the feedback and issues being reported. Come on Epic, we thought you were better than this.
Hey there, and welcome to life on the bleeding edge.
As someone who’s spent two decades working with bleeding-edge tech, I can say: this is the ride. I’ve done engine upgrades for teams of 20–30 people, and picking the wrong moment to upgrade can cost you and sometimes a lot.
That said, if you’re looking for solutions (and not just here to vent or dig in with “I must use this”), here’s something that might help:
I’ve been using Unreal since 4.10.x. Navigation Mesh in Unreal has always been finicky, and we knew early on that it wouldn’t meet our needs. The old-school trick is placing point markers in the world and using those for pathfinding—it’s more reliable than NavMesh and honestly still valid. But if you’re looking for something modern, robust, and surprisingly plug-and-play, I recommend:
Dynamic Surface Navigation
In action:
https://www.youtube.com/watch?v=_WX2yIjDTWc
Networked test: https://www.youtube.com/watch?v=MUDqAvA9Q3U
Also, if you’re using ISM in your levels, don’t. Foliage uses HISM for a reason. It gives you batching and proper distance culling. ISM doesn’t cull per instance and has very few real use cases.
And be careful with engine upgrades. In 5.3, they silently demoted Turing support, materials that worked in 5.2 just crash. Unreal doesn’t warn when they overhaul the pipeline for Lumen or Nanite. If you’re shipping on PC or mobile in the next couple years, tread carefully with 5.6+. Turing support looks even worse now.
Hope that helps.
It’s ridiculous that the bugs in this engine are very low-level, and some basic functions often fail, such as importing FBX formats and casting shadows on the volume of lights. I deeply suspect that the technical maintenance and development of this engine are outsourced to an extremely cheap team outside the company, such as Indian people, who are responsible for maintenance and development. That’s really ridiculous
Only Indians?
Its crazy how you got 8 upvotes to this post You pretty much admitted that you didnt test something properly when upgrading and you only found out 1 version later where you couldnt roll back.
Incredible, i dont know how this is related to either of my comments or Unreal in general at all. Good luck
Add to DefaultEngine.ini:
[SystemSettings]
Interchange.FeatureFlags.Import.FBX=False
Interchange.FeatureFlags.Import.FBX.ToLevel=False
This will revert FBX import system to old (before Interchange was added as default).
I said I discovered a new bug. It’s not realistic to test every single use case before switching to a new engine version. You only come across some issues when using specific features in actual production workflows.
Thank you very much for providing the method, but the problem still exists. The export and import of the original skeleton position data of the animated character will change, which means the body will deform. I think even if the FBX function is upgraded, no one will touch this part of the data. However, such a big error occurred, and I even think someone deliberately modified it to create such a ridiculous bug,this is very infuriating. Now I can’t distinguish whether it is the bug that existed in version 5.5 itself or the bug that appeared after upgrading to version 5.6,because before upgrading to version 5.6, I have been working on creating scenes and did not start the animation part of the character,I think such a low-level error is unforgivable,
Whats realistic or what isnt is not relevant, the choice of upgrading the engine is in your hands. It is your job to research working / not working features and decide on engine upgrades / version accordingly. Why do you expect epic to babysit you?