Building for optimization from the start

I have been building small games and looking at content packs in order to get a better idea of how things are made and I have quickly been getting bogged down in performance issues. I understand the general ideas behind optimization - lower res textures, low poly counts, the basics of draw calls and occlusion but my projects still start to bog down before too long - it seems that keeping texture and polycount overheads low and using as few dynamic lights as possible etc, but I feel like I need to build these games from the start with some key optimizations in mind. I really want to build a game that runs ultra smooth on a potato, and I’m not really interested in the latest PBR rendering techniques - good old fashioned dif+spec is fine by me!

Is there a way to hard-disable some of the more advanced features of the engine so that I’m not spending cycles on features that I’m not using? Are there any resources that provide a deep dive on how to optimize UE from the get-go, and how to build the entire project for ultra-optimization? I’d love to be able to spin up my game on a fairly low-spec device and have it look only slightly worse than a high-spec device.

In particular I remember the Epic Citadel demo that ran smooth as butter on a really trashy old samsung of mine. How did they do that??

There is no big switch unfortunately. It’s quite possible to bring a 20 core CPU to its knees with just a couple of carefully placed actor spawns on tick.

You need to be aware of things that are killing the frame rate while you’re building the level.

I’ve just finished writing a game and I’m pretty sure it will run on just about anything, but that was not straightforward.

There were several levels that I had to ‘re-imagine’ and make from scratch a number of times.

If you just pay attention to the performance as you go along and track down what’s causing the problem, you’ll get better and better at it. You don’t need fancy profiling tools, you get a nose for it.

Things like large landscapes with a lot of foliage are out from the word go…

Yeah I’ve been basing my entire games around what I assume to be optimizations - for instance, a top-down isometric-esque adventure game allows me to completely avoid ever having to render a large landscape off into the distance, but I still don’t feel like I have full control over what is being rendered, and I don’t fully know how to take control of when an actor is dumped from memory entirely - do I need to manually write my own object pooling? I guess I’m not comfortable just allowing the engine to do it’s best - I really want to be able to take control and make sure I’m not wasting a single cpu cycle. Things like precomputed vis volumes seem to be the right direction -…ume/index.html because that allows me to transfer the cycles from runtime to bake time, and gain some more control over the otherwise ‘black box’ that is the engines own auto optimizations. Trawling the docs only gets you so far though.

I understand it won’t be a single big red button (and I don’t want one) - I guess I’m looking for suggestions for courses or resources on the various controls the engine has for ultra granular optimization, and ideas on how to build a project from the ground up with those controls being forefront. It’s not a big truck!

Yikes, that seems like something of a perfectionist creativity killing approach. But whatever works for you dude…
I’d argue that you’re at risk of killing off some pretty serendipitous moments in terms of gameplay discovery tho.
UE4 (and even UDK) has immense capacity for high mesh counts, without devs having to actually do too much.
Overall landscapes + foliage, plus high AI player / character counts + navmesh complexity are the bigger issue.

UE Livestreams + GDC talks are far more useful for learning about optimisation than the docs will ever be imo.


I’ve no doubt that the devs who’ve mastered all the profiling and stat commands are the best in the business tbh.
But there’s still something to be said with just having switches to toggle the action on / off within complex scenes.
Or move the action quickly to a test level so you can see if the foreground / background complexity is killing FPS.

The cumulative build up of collision in complex scenes, can cause huge issues that stat-unit won’t ever show you. :wink:

Of course there is a place for the tools, but you can do 90% of it just with fps and knowing what to look for…

If you’re doing that style of game, you’ve already cut out many of the problems. If you’re having ANY frame rate problems at all, it will be down to a bit of dodgy blueprinting :wink:

You definitely don’t need to write your own garbage management, the engine will handle everything just fine until something start hammering it.

nha, c’mon i can get a custom 112km^2 rendition of a real world location with only foliage to run on a note 10… its all about doing the impostors correctly for foliage, picking the correct landscape size since you have something like 12×12 or more calls just to render the landscape impostors with 8km tiles, and HLOD merging.
Re impostors if you use speedtree, yes. Forget about it. You need something way more advanced to get more than 300 foliage for the current tile you are on to not destroy performance.

As a general rule of thumb never add in anything from marketplace direct.
Create a slush project, add content, review content, migrate parts you reviewed. Pay particular attention to materials and texture sizes.

While you may not need to do custom GC - writing your own pool is definitely the most beneficial thing you can do in terms of improving performance/running from a potatoe.

On a top down game, being able to store the world location of AI enemy and removing him when off screen is a dramatic performance improvement.
keeping the location means you can re-spawn it at the same place if you go back to the area.

Of course, you’re right. But I did mean using large landscapes with a lot of foliage ‘out of the box’.

I see you’ve got good at optimizing landscape. I assume that each developer needs to hone skills for optimizing the particular cross-section of actors they are working with…

Kind of a must in order to use the built in landscape. I would say that between the material making and figuring out sizing for impostor/draw call it takes about a year of actual trial and error to even start to get a nose for it… / I really wish they’d drop the current system or at least remove the automatic MIP thing they added.

Check it out, new video on performance optimizations

So I understand that UE can handle heaps of polies and that’s fine, and in the example of a top down adventure game I am using a tile system so that anything outside the camera frustum is culled pretty aggressively. But I saw an article outlining how separate meshes have a single drawcall each, and if I was to join my tile meshes then I would have the advantage of less drawcalls, with the tradeoff that more verts would be in memory even if they would otherwise be culled. On a lemon device, should I be turning the knob all the way in favour of minimum drawcalls, or aggressive mesh culling in this instance?

Or am I better off scrapping the tiling meshes idea and throw it all in on landscape instead? I understand landscape is optimized for lodding but if my game is top down then I really don’t care about any landscape tiles further out than the camera view, and that seems like a waste of memory.

In terms of profiling, I haven’t got far enough yet to really crank the settings and see what causes chugging but I’m looking forward to it - thanks for the tip on unloading AI’s - that’s the kind of info I’m looking for as well!