There are following bugs I am aware of:
1, One which drastically reduces Play in Editor performance. Introduced in 4.26, still present in 4.27 and is planned to be fixed in 5.0: Unreal Engine Issues and Bug Tracker (UE-108737) - You can tell if you are affected by this one by trying to play the game in standalone window. The performance degradation should not be there.
2, One which reduces Translucency performance. That one should not be present when you don’t have significant amount of translucent materials in your level. That one will affect standalone play mode as well as cooked builds.
Not really.
.27 seems to run a but smoother in testing (published no dev tools).
It’s still sub par to older engine versions.
If publishing for mobile, may I suggest you grab a way older version of the engine?
Something close to .18 or maybe before that even?
Unless there’s some feature you absolutely need that was added later.
It will not only run smoother, but probably increase compatibility with devices.
In fact, I don’t recall having any issues back in .22 when publishing to 4 different Android branches…
So. Yea. It’s way more complicated than what I’m about to say… you’ll need to dig into it a while.
In a Cpp project, opened in visual studio. Open the nuget package manager, see what updates it can get and try to compile/use the latest version possible.
Also, probably update NodeJS to the latest in a separate install and force the engine to use it in the .net configuration setup.
In the end, it’s an SDK. You should be able to tell the engine what to use somewhere.
In worse case scenarios you have to pull the engine source, modify that, and build the engine from source. This may just be the way to go about it for publishing older versions if the setup for it isn’t modular as it should be.
I THINK there’s an android related section to the forum where maybe you can find some better tips specific to this.
Note that Android Studio also has versions and compatibility issues.
Also, refer to this for setting SDK variables (on the off chance it is avaliable in older versions).
Sorry to revive an old thread, but in case anyone is looking for this, 4.26 disabled the rhithread for us which is responsible for splitting the work load with the render thread. You may notice that “Draw” is very high on ‘stat unit’. If so, try ‘r.rhithread.enable = 1’. That’s what got us to pre 4.26 performance.
I’ve been looking at this today and it definitely gives a good performance boost in 4.26 for DX11
Just note for a shipping build you have to execute the console command at runtime(in a blueprint for example), you can’t just add it to an .ini file
There is some info I found in this thread that gives a few clues as to what happened:
So what it seems happened is the RHIThread was previously enabled by default to help performance in DX11 but was setup differently for DX12 and was set to off by default in 4.26. So you either need to use DX12 or for DX11 you have to enable RHIThread manually.