I have a question. I need an Unreal packed game that simply does nothing else but show a maybe slightly rotating cube or whatever. However it shall use a plugin i wrote, that shall be used when a mqtt message comes in. My plugin, a third party MQTT plugin. Thats it.
So i do not need anything at all but the absolute basic Unreal core. The goal is to have a “game” using the smallest amount of vram possible.
The project is a blueprint project, 5.5.1, with some c++ code for the plugin.
No, I don’t suppose you will do it for me. It is this: Even when having disabled plugins and having deleted all meshes, the content drawer almost empty but the level, the game when started grabs quite much vram.
Actually it would be best for me to run Unreal without using any graphics card at all, as a testing container for plugins that don’t use graphics. This way i could have three or four inexpensive machines running unreal headless.
Is there any chance to make unreal run without a graphics card? I know, that’s a weird question, and probably the answer is no.
So not: Is there a way to restrict the use of vram somehow?
Having packed my “game” without any meshes, without lights, just black emptiness and as “shipping” makes it grab 4GB Vram. For what? For black nothing?
are you trying to test the impact of your plugin in a “shipping” build, and probably trying to minimize variables on what is impacting performance?
to “disabling GPU from the engine” (firstly you will need to build from source) you would have to rip out the entire Renderer which has a big maze on inter-dependencies into other systems like physics (physics has hooks to share data with the renderer for mesh in the event you use mesh collision tests to achieve pixel perfect collision).
on the “restrict the use of vram” this is shaky, and platform dependent, and then the compiler through the header and build tool might say try to simd the matrix operations from the CPU to the GPU instead. there is also things like Nanite, Lumen, Niagra, and other rendering focused things existing that will use vram (even if you are not calling them explicitly)
Unreal does have “listen server” that does its best to abstract out GPU things, but still able to utilize physics (though it performs better with GPU), and if I am understanding the acronym you are using a messaging interface/layer whose primarily for “internet of things” or server interactions.
as a proof of concept “can I make Unreal as small as possible” it will always be a “kind of”, and I am going to assume your plugin is intended for generic integration (like the market), and the users even you yourself will not be putting it into an application with nothing (outside of a listen server). Maybe the user ends up using a bunch of unconstrained Tick() implementations which will lead to longer delays, and maybe even queuing on the client side.
so eventually you will need to test the impact on a dense system for impact: take something like the matrix demo and try to broadcast the locations of each active entity every 10 seconds (maybe just a list of entities that are “close to the player”). this way you can do profiling on a “known system” and if you were say to put this on the market you can also show what the impacts of your plugin relative to a known (you might also figure out some integration assumptions you may have made). especially where one of UE5.5s big things is hardware independently improving the performance of like the Matrix demo.
Thank you so much! Actually the task for me is to set up and test multiple unreal engines running and talking to other systems and also to each other. For such testing it would be great to run multiple instances of unreal on one computer. If it was possible to limit the vram demand to say 1GB, I could maybe run 8-10 instances on a system with 12GB vram. As the games don’t do anything, the demands to the hardware shouldn’t be so high, theoretically.
I have one computer with a A6000 that shares 48 GB vram and 128 GB ram to 4 instances, but these are real games that demand their share.
For testing purposes only it would be great to be able to mimic such a system on less expensive hardware.