Pretty sure it does not, but then again It’s been a few years since I ran games on a 1080ti to do anything other than test.
Back from ARK dev actually.
He also claims the engine “is fine” if you want to re-type stuff pointlessly you may as well do it right.
Unless the tools are to blame.
In your case, they certainly are. Kudos for “working around the problem”, However you are just ignoring the fact that 40-60FPS in PIE is literally NOTHING - by default pie is maybe 800x600 of a view port. So already playing in full screen will drop your FPS below what you’d like.
Do a test in a full screen published build.
At 1080p you shouldn’t be completely unable to get 60fps. Yet, you could have 20% more FPS by just using an older engine version than .26.
That’s your problem - as a new comer to the engine you don’t know that it was once actually a lot better.
Do some research on the forums. There’s only about a billion topics complaining about specifically broken stuff between different distros that have never been patched.
Meanwhile everyone with a project who upgraded engine version for a specific need got screwed out of 20% fps amongst other things.
It’s not. It’s packaged build too.
And when targeting older GPUs a 20% drop in performance means literally not being able to publish.
It also appears to have extended to UE5.
There’s currently a note in rendering thread addressing an issue with DX11 drivers - that’s not it either. The issue persists in DX12.
/ That note is literally the FIRST acknowledgment of problems by epic in 2 years.
(link to it, since the rendering forum is being flodded with “KB notes” whatever they are: Tech Note - [Bug] 4.26 D3D11 - Shader creation on multiple threads causes hitches)
It’s 100% not open source.
Can you access the source? yes.
Don’t mix the 2 things. It’s an insult to open source efforts.
Personally, I opted to move to an engine where I accutally get support.
So has pretty much everyone else.
This issue has been IGNORED by epic for 2 years now.
Why would I or anyone else waste time fixing the mess that the EPIC team refuses to take care of?
Refer freely to any of a thousands of topics like this:
https://forums.unrealengine.com/t/looking-for-input-on-learner-progression-for-our-future-ue-community-learning-experience/262563/32
Meanwile, Unity for instance has developers actually answer to bug reports. In public, and provide viable solutions - despite having an inferior company that’s not making billions off of grabage of visual only pixels in Fortnite.
Point in fact, I really don’t for professional projects. At this point I’m also convinced that no one really does. We all stick to other engines or .18/.20 if we really have to use unreal.
There’s some people out there developing in “UE5” - I think 90% of that and related gameplay footage is BS equivalent of GDC preview of pre-rendered VS what you actually get on release day.
There’s nothing going for UE5 yet that would justify wasting the amount of time needed to fix up the engine nightly to justify pushing development onto it.
And according to forum posts on performance of it it’s only getting worse the more features they add - which being it’s not an official final release is also to be expected. That’s a different scale that has to be used to measure the 2.
UE4.27 is “FINAL” as such it shouldn’t have any ISSUE as bad as a 20% FPS drop between an older version and itself. (same for .26).
UE5 isn’t “final” so any metric of any kind is purely speculative and you can indeed choose to “live dangerously” and develop something you’ll never be able to release.
Not for me, no. I have my own .24 version with custom ray marched clouds, custom sky-sphere and updated physx engine version going.
That doesn’t change the fact that there is absolutely NOTHING in .26 or .27 that should justify a 20% frame drop when disabled - OR is there?
I mean, are you suggesting that it’s OK for an engine version to just magically cost you 20% more rendering out of nowhere? Without any support or acknowledgment from official sources? And that an engine DOING this doesn’t just “SUCK” ?
It’s not a problem with my expectations when prior engine versions are capable of this while the current one is not.
It’s you that has wrong expectations thinking that the scene has to be dialed down to run “right”. It’s the rendering pipeline that is causing the drag. NOT your scene.
(when the same scene runs above the required stats in older versions - obviously).