this is correct. afaik the engine predicts about 1.5g of ram per process.
so if you have a 32 threads cpu you will want to have more ram than 32g. specially since there are other software always open.
and that’s basically an issue from the compiler itself.
ue will work with less ram, but will reduce the amount of processes, giving you considerably less performance during certain tasks (compiling code, shaders, and others (maybe lights and landscapes), and maybe the new multi process cook).
Packaging and cooking is another very intensive process that might benefit from more ram.
other factors to take into account:
- debug/development builds could use more ram/disk and are slower, which is the norm while developing.
- blueprints (afaik) have a sort of virtual machine on top, (or an extra layer of communication), which consumes ram.
- there’ s also python automation scripts which could translate to more ram.
- other software you might need open:
-
- the IDE for developing can use a lot of ram (vstudio/rider). mine uses like 20g sometimes.
-
- the IDE during a debug session could hold even more ram necessary for such process (e.g. when attached to a build or editor).
-
- the browser. is not a trivial piece of software and consumes ram indiscriminately.
I think those are the main reasons they recommend such a number. not because ue itself uses it all the time, but because the whole environment needs it.
but also as mentioned, content is big and sometimes needs to be in ram, as well as metadata.
some data types are complex in raw form but small when cooked, but the editor needs to be able to handle them in raw form (meshes, sounds, images, etc).
i have had exp in Qt (which btw is my favorite app framework <3) but the content you handle with it is far less complex than what you handle in UE (imho).
also worth noting that UE itself, when compared to other 3d engines, not only it has a considerable surface (as in lots of big pieces), but also quite complex (e.g. lumen, nanite, umg, metasounds, etc. are not trivial in their implementations).
i think it’ s pretty efficient how it’ s architectured (i’ m not an expert on the internals), it’ s divided into modules and plugins. This is quite flexible and allows for compilation in pieces but also can require more ram to interface or compile.
Another reason is that UE has plenty of optimizations, and sometimes the tradeoff is memory Space–time tradeoff - Wikipedia
One example of this is UnityBuilds (not to be confused with another engine), these are way faster than compiling one .cpp at a time, but requires a lot more ram comparatively.
(i did the test with 32 threads with the same ram and cpu for both types of build, and the time difference is absurd, it basically comes down to overhead, i think.)
you can reduce the amount of ram used to compile and run the editor (and the game) if you disable plugins you (know you won’t) don’t need. Though for beginners i’m not sure i’d recommend it, because when you disable a plugin that functionality is not shown in the UI, so you might never know it exists until late.
note:
most of my experience is using Linux, but i also work with Windows sometimes.
Normally with my ide, browser, UE and other minor apps open my ram is about 25-40 gib usage, on KUbuntu. i usually use debug or development builds of my project and sometimes the engine.
on the current project im working on windows atm ue editor itself is only using 3gib of ram, the browser 2, and the ide 10.
considering blender recommends 32gb of ram, i don’ t think ue is too far off.