I’ve got an actor, “Maze”, whose construction script handles the creation of a maze given information regarding its layout. For the time being the pieces of the maze have no self-contained behaviour or anything, so I’ve used instanced static meshes, meaning the maze generates incredibly fast (I watched one of the tutorial videos on procedural level generation, which suggested using this over normal static meshes, as they’d take longer to generate).
However, my game’s design has evolved, and now there will be pieces of the maze that need self-contained behaviour, meaning that I should probably create actors for them. My only question is, will my game suffer a big performance hit by spawning actors (via child actor components) instead of instanced static meshes?
Just so you’ve got an idea of the scale of things, my maze will contain around 500ish child actors…
There will be certain parts of the maze that I’d still use instanced static meshes for, but there will still be around 400 actors required (i.e. the parts that do have behaviour).
Just something else to be aware off. Keyword culling.
When you create a large areas it may not be the best idea to use instanced meshes. The way they work is some fancy GPU magic where you only hand over the model and shader once and it renders it over and over at different transforms. However the downside is they can only be culled when not a single mesh is in the viewport. If a single instance is, every single instance will be rendered.
Adding instances is indeed significantly faster than initializing individual pieces.
However the larger your maze is the more of an overhead you might have during real time.
If you don’t see a lot of them for the majority of the time it might be worth taking the extra time during generation to get some ingame performance from culling. (e.g. First person maze where you see like 10 walls at once. Rendering 500 or more instanced meshes might have a worse performance than rendering the 10 individual meshes and have the rest culled aka not rendered).
There isn’t a clear cut right way to do this and as I mentioned depends a lot on how much of it you see during runtime.
Since the spawning is technically the same up until the point where you create the instance / new mesh component. Why not put those in separate functions and test out every now and then which is better?
Shouldn’t be a significant workload and could end up giving you a better result. And you can be absolutely sure that you’ll have picked the right option in the end!
I’m glad you answered in detail, Erasio, as I think I’m encountering a problem that might be solved by the very thing you have mentioned! I’ve now reproduced my maze blueprint with the extra required parts (or half of them at least), and it’s slowing down to a crawl! I’m going to make a backup of my project and try to use actors for everything, and see whether it increases the in-game performance. Unfortunately, I don’t have the best computer (I can’t remember the exact specs, but I think it’s 4GB RAM and a GTX260 graphics card, so it is pretty outdated compared to even mid-level PCs today); it was good enough to play Alien vs. Predator (the remake) at max settings, but I think it’s struggling to keep up a bit with UE4. I’ll try to optimize my game a bit to see if I can get a decent frame-rate and post the results, but I have a feeling some of the problem might lie in the fact that I’m using a lot of metallic and other highly-reflective materials (which in turn produce gorgeous, but taxing visuals).
This does give you a good baseline for the minimum specs for your game though! For example, now you know you might have to optimize more to appeal to the masses. I find some indie devs with high end PC’s don’t notice how badly their game runs on lower spec’d PC’s and thus don’t put any effort into these optimizations.
You have a good point there! I think the only problem is the extra overhead with running the editor alongside the game itself; are there any settings within UE4 that I could use to effectively allow me the test the game without the (I’m guessing) heavy overhead from the editor (perhaps something that turns off the debugging tools, for example)?
I wasn’t able to find anything myself. What I ended up doing was cooking my project every hour or so when I was ready to test fixes or features rather then using the in-editor debugger. If you have a second PC laying around, like an old laptop, I found that cooking my project to a network drive and then testing on that second PC can help improve the workflow.
Create+Edit on Desktop -> Cook to network drive -> Load game on network connected laptop to test.
It’s a bit of a hassle, but if moneys tight then it’s an okay alternative.