Word!
Translucency should affect the framerate only if you use it.
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.
Wellā¦ this performance drop happens even justa in Editor, not only during Play in Editor, so I think they are still not having it into account.
Wake up. They DGAF.
Even fortnite runs slower than it used to (and looks just as bad).
Hey, is there any progress on this subject? especially for mobiles , thnks.
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ā¦
Yes the old versions work perfectly, but Google requires more advanced features like Billings lib 3.0, .aab format, Available just with ue4.26+
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).
1 Like
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.
11 Likes
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.
4 Likes
This ār.rhithread.enableā fix works. I have about 10 frames more.
Thx!
3 Likes