Hi all,
The optimization stages of my game in my mind is
Have a search on googleâŚ
Check the profiler, see what takes the most time and what you can optimize the best.
Also check out various âbest practicesâ Unity - Manual: Best practice guides
useful thanks
You always want to use the profiler. One-size-fits-all performance rules do not always apply to every scene. Sometimes they may even make your performance worse. The profiler can help indicate what the actual problems are and whether your optimizations are actually improving your performance or not.
I highly recommend starting from the top and working your way down. Optimise your game design before you optimise your code. Its generally better to throw out a system you donât need entirely rather than to try and eke out performance from it.
Well, the general steps are:
Exactly what youâre measuring, modifying and testing depends on the project and the issues youâre running into, and how you do it is in turn dependent on that. The Profiler is a good general purpose tool if youâre working in Unity which will help with a lot of this.
On the programming side of things another good tool in C# is System.Diagnostics.Stopwatch. This lets you take detailed timings from inside a function, so you can see what parts of that function are actually taking up the time.
It could also be worth getting to know the other tools in Unityâs âAnalysisâ menu, depending on where things are slow.
Dont know if your game is 3d, or 2d, or goal platform. But in the 3d world, this is a section of my âUnity Bibleâ, notes on what i do to optimize your assets before hand:
====OPTIMIZATION====
âAll assets should have LODS, and adjusted correctly.
-Adjusting the far/near clipping planes on the camera.
-Increase the pixel error. This results in more significant height-popping of terrain subsections.
-Increase the detail distance (the distance that grass and detail meshes are visible).
-Decrease the tree distance (the distance beyond which trees arenât drawn at all).
-Decrease the billboard start (the distance at which tree meshes are replaced with billboards).
-Reduce the Max Mesh Trees (the maximum number of trees which are displayed as meshes at any one time any others will be displayed as billboards regardless of their proximity).
-Remove reflection probes.
-Use texture atlasâs.
-If Minimap: use texture/screenshot of the world instead of camera, if possible.
-Bake occlusion culling.
-Reduce models polygons/tris.
-Bake lightmaps, static/baked lightmaps.
-Delete parts of models not needed.
-Reduce number of textures per model.
-Take off shadows on objects not needed.
-Scale down textures, if needed - 2048 for high detail, 1024 for mid detail, 512 for low detail, etc.
-Directional light - should be yellow-ish tint.
-Color Space: linear.
-Ambient light (if used): blue tint
-Adjust light intensity.
-Chunk/split up terrain and stream terrain tiles, if large/open world senarios.
Texture Import Settings:
Gen Mipmaps: true
Max Size: 1024
Compression: low quality (Lower Disc Size)
Max Size: minimum
Atlas textures
Remove Alpha Channel
Disable: Read/Write Enabled
16bit Over 32bit color
Disable Mipmaps for UI
Disable Streaming Mipmaps On: decal projector textures, refection probs textures, terrain textures
Mesh Import Settings:
Mesh Compression: use agressive compression
Disable: read/write enabled
Rig: if not using animation, disable Rig
Blendshapes: disable if not using
Normals And Tangents: if material is not using, disable
That should give you a directionâŚ
Profiling and responding to actual problems is the key.
Lots of great tips in this thread, but I also want to warn against unnecessary overuse of LOD meshes, which can actually be detrimental to performance and the maintenance of a project. More LODs isnât always a good thing (in a world with GPU instancing and such like).
@jbooth1 wrote a very informative post on this subject last year, so itâs worth keeping in mind the other side of it as well, so you strike the right balance.
The key is to profile and only optimize what is necessary. Doing optimisations for things that are not needed is often a waste of time. You could spend ages optimising your scripts, only to find that they only use 2%, whilst that time could have been spent optimising what is actually taking up the most.
So profile, use the profiler, memory profiler and frame debugger to track down actual problems and then react accordingly.
If you are somewhat competent programmer more than 95 procent of frametime will be spent in unity domain not your domain and 95 of that will be spent rendering the game.
Problem with unity is that they dont make games them self so tooling is none existing sadly. For example analysing lightmaps etc
That depends on what youâre doing. If youâre processing thousands of agents in a background simulationâŚmaybe not.
Most games let the players optimise the game for their hardware via video settings.
You can achieve similar results to mesh baking by enabling instancing in the material shader (it allows the GPU to copy repeating objects in the scene faster and easier).
Using camera occlusion and baked occlusion also reduces what the game renders but you need separate meshes for this to work best.
However this works against combining meshes which reduces draw calls a good GPU optimisation.
I would not remove Vsync just make it an option.
Ditto for shadow settings.
Distance fog and camera range can massively speed up your game and add atmosphere.
These are basic steps you should be building into your game, however as people have stated you need to run the profiler often to see if anything you are adding to the game is slowing things down.
It is often easy in Unity to write slow code that utilises âFindSomethingâ functions every frame in Unity or just runs every frame in Update/FixedUpdate* when it is not needed, the profiler (deep mode) should help you find these hot spots in your code.
*FixedUpdate can be even worse as it runs at the speed of the physics engine which occurs multiple times per graphics frame.
Offcourse there are edge cases, but in general you will spend your time optimizing not the code but the other aspects
Sure. Just pointing out that itâs not an absolute rule and isnât necessarily about how competent a programmer one is.
Also the default Unity pattern of code per a game object (GO) is really bad when you have lots of GOs of the same type as every GO is using up precious time just calling itâs update function and pulling itâs variables into the CPU cache.
A manager script that cycles through lots of specific types of GOs (via an array of structs) can be a lot faster and is a step towards other optimisations like âmulti-threadingâ and DOTS.
For Example:
Imagine a game with Zombies where every zombie looks and listens for players before moving towards them.
The default Update() per a GO would be overwhelmed very quickly with proximity tests (Sphere casts, Raycasts).
Whereas a manager class could quickly work out where the groups of zombies are then run single tests based on the the centre of those groups.
Another potential performance problem is the Instanciation/Destory mechanic in Unity. For a lot of destructible game objects you are better off with a pooling system that disables then recycles and enables game objects.
This cuts down on processing power and memory utilisation issues such as garbage collection (which is renowned in Unity for causing performance hiccups during gameplay).
thk
I canât upvote this enough, I keep the amount of active monobehaviors as low as possible, usually i end up with around 5.
This saves so much performance itâs actually ridiculous.
also if you have something that runs huge loops and inside the loop thereâs function calls it also costs time, if the call is to a simple calculation it is a lot better to just do the calculation inside the loop instead of calling a function to calculate.
I tested this with a gravity simulation on a solar system scale, and if I calculate the force needed each fixed step inside the loop instead of calling that calculation in a separate function I can increase the amount of bodies a lot.
this was back on unity 5.6 or maybe 2017.1.