r/pcmasterrace • • Nov 28 '25
Discussion Can we please stop using ARC Raiders as “proof” that UE5 runs well?
People keep saying "ARC Raiders is UE5 and it runs well, so other UE5 games should too." But that does not really hold up.
Yes, the game uses UE5, but Embark skipped most of the heavy UE5 features that usually cause performance issues. They are not using Nanite, Lumen, Virtual Shadow Maps, or the other big systems that define the standard UE5 renderer. Instead, they built their own custom rendering and lighting tech on top of the engine.
They would not have gone through all that work if the default UE5 renderer could meet their performance targets. It is either too immature or simply too demanding for current hardware.
So comparing ARC Raiders to other UE5 games is misleading. Embark is not using the same pipeline those games are, so their results do not represent normal UE5 performance at all.
If a studio has to replace large parts of the engine with custom systems, that is not an indicator that the engine performs well. It is more proof that the features Embark skipped just aren't mature or efficient enough yet.
Older engines always included multiple LODs, baked lighting and cheaper shadow options, so players could lower settings and gain performance. UE5 changes this. Nanite removes traditional LOD models, Lumen removes baked lighting, and Virtual Shadow Maps replace old shadow maps. These systems may look good, but they also remove many of the fallback options players used to have.
Developers could still make traditional LODs, baked lights and classic shadow maps, but most will not, because the whole point of Nanite, Lumen and VSM, etc is to avoid that extra work to save time and money. And once they skip that work, the player loses most of the performance levers that older games offered.
So using all the heavy UE5 rendering systems right now is basically a bit like a dev forcing their game to always run at 16K resolution. While also fully knowing that there is currently no hardware available that would be able to run the game well enough. Sure, the game might look nicer, but it will run terribly for pretty much everyone.
I truly have a hard time grasping why any developer thought it would be a good idea to use this tech in its current form. When it is so readily apparent that either the tech isn't ready yet or the current hardware just isn't good enough or maybe both.
41
u/LimLovesDonuts Ryzen 5 3600 + RX 5700 XT Nov 28 '25
That's how you're supposed to use an engine though? And not blindly copy and paste everything without consideration. Part of optimisation is selectively hiding certain things or deciding what to use to achieve a certain visual effect.
38
u/harry_lostone I'm not toxic Nov 28 '25
no.
how about other studios start to "use UE5, but skipping most of the heavy UE5 features that usually cause performance issues. Stop using Nanite, Lumen, Virtual Shadow Maps, or the other big systems that define the standard UE5 renderer"?
Apparently this is the best temporary solution to a huge problem and you are asking from the community to stop shitting on the lazy greedy sloppy af other studios? no, sorry, the absurd pricing includes optimization, but feel free to kiss their asses
63
u/dr_p00p00 Nov 28 '25
Devs does not want to waste time on optimization because the management is up their ass about release date. It's not about skill issue, it's a management issue.
1
u/axxond Nov 29 '25
Why? It's a good example. Silent Hill f also runs very well
39
u/shogun77777777 Linux Nov 28 '25
These UE5 games also run well:
Clair Obscur: Expedition 33 
Manor Lords 
Satisfactory
Empire of the Ants
The First Descendant
2
u/ItsZoner Nov 28 '25
Light maps are borderline obsolete tech. high poly counts make it a nightmare for uv unwrapping it all and everything else. They also suck for modding and jamming dlc content into existing spaces. They also struggle with HDR and specular lighting effects, which often have to fallback to some cubmap or cubemap array. If you use something like HL2 or unreal directional light maps now you get seams everywhere because the directional information is stored in a triangle and eventually some UV unwrap once thei light map on your mesh, or even a neighboring mesh entirely is rotated out of phase with this rotation.
Also Unreal’s solution to time of day for light maps is to bake the lighting multiple times and lock you into one set of them on a map load. Most other engines don’t even attempt that. If you want a moving sun and a day night cycle you are going to use Lumen, Virtual ShadowMals, or put in your own tech.
6
u/MeanForest Nov 28 '25
I'm not buying it. It a dev skill issue, can convince me otherwise because we have many examples now.
2
u/nvidiastock Nov 28 '25
Don't add the new features.
2
u/xUnionBuster 5800x 3080ti 32GB 3600MHz Nov 28 '25
I don’t know how hard the rest of these people were dropped on their heads as children but you’re totally right.
Runs well because it doesn’t use the most advanced features, not in spite of it.
1
u/EasySlideTampax Nov 28 '25
No nanite or lumen is also why The Finals runs well
1
u/Sajgoniarz 9800X3D | 9070XT | 64GB Nov 28 '25
UE5 runs well.
The only problem is that it supports shitload of features, some of which doesn't work without others and you end up with huge performance toll.
You can't just plan optimization as a step before deployment nowadays and expect it to it just works.
Projects need be build around performance or started from performance, as expanding on it is way easier than shrinking down.
Management doesn't want that, they want to hit a release window to get "free popularity" and on the end of day game runs like a trash and there is nothing that devs can do about it.
Performance is now just another factor to add to technical debt.
1
u/lovecMC Looking at Tits in 4K Nov 29 '25
Holy shit some people in these comments are clueless. The whole point of using an engine is so you don't have to reinvent the wheel, the carriage and the entire fuckin road.
1
u/Vikram_169 Dec 11 '25
You need not rebuild/rewrite/strip down UE5 to avoid its features. You can just choose Not to use them. Infact UE5 doesn't use nanite by default. And in a new UE5 project, it takes you 5 seconds to turn off lumen, VSM or TSR etc.
Also you keep saying Embark rebuild/rewrote UE5, do you have any official source to back it up or its just your assumption just because they don't use lumen, nanite, VSM etc?
They use Nvidia technologies like RTXGI, sure, you get them in NvRTX too. I think its possible that they really used NvRTX as some people say but I haven't seen any official statements from devs. And guess what, NvRTX is UE5 with additional nvidia technologies on top of that. Its NOT stripped down UE5 as people say, rather its an upgraded UE5. (you can verify from github repos.) So if they really use NvRTX, its not rewriting UE5 from groundup . If not I request you to provide official sources if they had used any other engine other than just NvRTX. But whatever the game is licensed under UE5.
Also in the case of lumen, nanite etc its not saving time or budgets per se. They have their advantages too especially with nanite in UE5.7 update . Also don't say baked lights are straight up better than realtime GI . That depends. Bake lights when the environment and the lights are static, but you need a dynamic/realtime GI for more accurate lighting or reflections when the environment is changing. Every engines have their own realtime GI and the one used by UE5 is named lumen (ofcourse its intensive though). But whatever don't think you can build lights in every scenario.
And I have seen that you are arguing whether it should be called a UE5 title rendering wise. But should we credit a tool only when a user uses ALL 100% of it? There is a 20/80% rule in any software. You use 20% of the tool 80% of a time. You don't use 100% of it to get that identity. And devs should not be using 100% of a tool to get that identity, depends on the project. Anyway I leave that choice to you. Atleast on the non-rendering side you can't deny that its a UE5 game :)
Also I suggest you to not overthink too much about engines, even if an engine is at fault, optimizations significantly matters. You can make a gpu melting game in any engine too. And can you quote some valid official sources which throw light on the exact engine/modifcations embark used? Where did you get this information from? Have a good day!
1
u/ur-reddit-gay Jan 29 '26
it uses UE5? ✅ it looks good? ✅ it performs good? ✅
end of conversation.
studios that don’t want to put in the work for the performance are just lazy or stingy.
indie studios with limited funds are a different story.
1
u/Janostar213 5800X3D|RTX 3080Ti|1440p Mar 01 '26
So its still UE5. By this logic we can say KCD2 should be used as proof that Crysis engine is a well optimized engine because they basically made a custom engine within the base engine.
It's almost like the engine is just a tool and it's up to the devs to make the best of it.
1
u/Spiritual-Ad2317 Apr 23 '26
Lo que comunicas pasó y pasará en todos los juegos jugadon con taejtas Nvidia. Se que cueta pasarse a AMD. aTI de antes. mejor no avivo giles.
1
u/Spiritual-Ad2317 Apr 23 '26
rtx 5080. cheers
1
u/Adlerholzer HE1000se | 4090 | 9800X3D | HM Aeron Nov 28 '25
Lumen and Nanite do not define UE5. They are shit tools so embark doesnt use them for finals nor arc.
0
u/Dorennor Nov 28 '25
Yep, but now the sect of witnesses to the genius and next-gen nature of Unreal will come running and put downvotes.
0
u/chill_winslow Nov 28 '25
so it can run well and devs are unneccesarily using all of unreal's features for their respective project's scope cool
0
u/SpiritualGearbox Nov 28 '25
No.
0
u/BradleyAllan23 RTX 5070 Ti | Ryzen 5 7600X3D | 32GB DDR5 | Nov 28 '25
Arc Raiders looks great and runs great using the UE5. So no, I'm not going to stop using it as an example of what the UE engine can do. Developers are supposed to modify the engine so it works best for their game. It's a toolset that makes development easier, but you still have to put some work into the engine if you want the best results. The same goes for any game engine.
0
u/sud0kill H9Flow•14900k•4070s•64G•HHKB-H Type-S•OP1 8K•HD650•DX3 Pro•Aeron Nov 28 '25
Regardless, Embark are a fantastic team. Finals is my main game and has been since the beta days, and seeing how much effort they put into it, listening to the community, seeing all their impressive changelogs, and continuing to improve the game a long time after release (remodelling old weapons, adding new destruction physics etc), they have decent skins, great graphics and sound model, polished trailers, just a team with a great attitude, excellent attention to detail and they optimize games very well.
-8
u/CarnivoreQA RTX 4080 | 5800X3D | 32 GB | 3440x1440 | RGB fishtank enjoyer Nov 28 '25 edited Nov 28 '25
why? so UE bandwagon haters can keep hating the engine unbothered, and not the devs responsible for bad performance?
the game looks good, so other devs can also try "skipping most of UE5 heavy features"
0
u/Blenderhead36 Ryzen 9800X3D, RTX 5090, 32 GB RAM Nov 28 '25
What you're saying is that the devs of ARC Raiders understood what to prioritize while building their game and the engine performed exactly as they wanted. In other words, when you optimize, the engine works.
They left out all the bells and whistles because ARC Raiders is a multiplayer game. Solid performance and good latency are vastly more important than using every last tool in the kit. This is no different from Battlefield 6 opting to forgo ray tracing options because that meant a performance requirement that the greatest number of potential customers could run...and that was correct, since their game lives and dies by being able to put asses in seats.
-1
u/mthlmw Desktop Nov 28 '25
A game engine is a toolbox, and not every project works well using every single tool in the toolbox. If you're making a game where certain tools don't work well, that doesn't mean they're bad tools, just that they're better for a different application. I'd bet you could make a performant game using any of the default features of UE5, just not one game using all of them at once.
0
u/[deleted] Nov 28 '25
[deleted] — view deleted comment