Game developer - Level Designer - Environment Artist - Author - Tutor - 15 Years of experience with Unreal Engine 1, 2, 3, 4
Log In | Cart        

About : Basic introduction to performance profiling.
Target Audience : Intermediate and above.
Platform : Unreal Engine 3
Last Update : November 2011

The Basics


There are a couple of great pages about game profiling on UDN, but as those are quite programmer focused and simply plain “too much” I decided to write a bit easier and more basic guide to profiling in Unreal.

Profiling means to find out exactly what part of the game is causing performance issues. Is it the lighting? The particles? The code? And so on. Before you can get to solving your performance problems you first need to know what exactly is causing it.

It is best to do your profiling in the real game, and not in the editor PIE/Play-In-Editor game, as having the editor running in the background can have a significant impact on performance. Some parts of the game are more sensitive to whether or not you have the editor running in the background to my experience. Physics for example. When I made The Ball we often encountered situations where the physics behaved differently and less accurate in the PIE game.

Be sure to run your game with the following command line options set:

  • -log: This will open up a MS DOS log window so you can keep track of what the engine is doing as it loads your game/level.
  • -remotecontrol: Allows you to open the remote control developer window during the game. Type “rc” in the console to open it.
  • -windowed: Forces the game to run itself in a window, to allow easy access to the log window and the remote control while playing.
  • -NoVSync: Forces V Sync off as having it on will cap your framerate to about 60, thereby potentially distorting your profiling numbers. Note that your 3D card settings may force V Sync back on in turn and override this command line option.
  • For example:
    H:\UDK\UDK-2011-09\Binaries\Win64\UDK.exe -log -remotecontrol -windowed -NoVSync

    Run your game, open the console, and type:

  • stat fps
  • stat unit
  • Stat fps displays the framerate and milliseconds a frame. Stat unit displays the milliseconds per component. The milliseconds are how long it takes the computer to render a single frame.

    So in this example we can see that we have 40.72 frames per second (FPS), and 24.56 milliseconds per frame (ms). Since one second is 1000 milliseconds long, that means that 1000 ms / 24.56 ms gets us 40.72 frames rendered that second. So the longer a single frame (=image) takes to render, the fewer frames will fit within this 1000 millisecond window (=one second) and thus the lower the framerate will be. Therefore, the millisecond value is what it is all about.

    Stat unit gives allows you to see which component is taking the most time per frame to process.

  • Frame: This is the overal time, about similar to the ms value that Stat FPS also displays.
  • Game: Things processed by the CPU, this is most notably the code, and possibly things like Physics.
  • Draw/GPU: The things processed by the GPU (3D card), so pretty much the rendering of the scene and models.
  • In the example the GPU is more stressed than the CPU, which is usually the case as the rendering is often the part that is most complex to do for the hardware.

    It should also be noted that the time it takes in milliseconds differs from PC to PC. It is hardware dependent. A more powerful GPU requires less time to render something, and a powerful CPU requires less time to go through some code. A high CPU ms value does not necessarily mean that something is wrong in your game, it may also simply be that your 3D card is much more powerful than your CPU and that your CPU has trouble keeping up with the pace.

    More Stat Commands


    In the third tab of the Remote Control window you can find a long list of statistics to display. Lets go over some of the most common ones. You can also trigger all of these by typing them directly into the console.

    Stat SceneRendering

    These are statistics to do with the rendering of the scene. Look for any statistic that takes an usual large amount of time to process.

    Within SceneRendering I often focus on the following values:

  • InitViews: To do with the occlusion of the scene. While occluding the scene the hardware has to do quite a large number of checks which meshes you can and cannot see. This can end up taking a significant amount of performance.
  • Base Pass Drawing and StaticDrawList/Dynamic Primitive Drawing: The rendering of the meshes and dynamic meshes within view. If Dynamic Primitive Drawing would be very high, you would know that it is an InterpActor that is most likely causing a problem somewhere.
  • Translucency Drawing: The time spent on drawing translucent surfaces. A very high number here could indicate a problem with particles for example.
  • Stat D3D9RHI or Stat D3D11RHI

    Shown at the bottom of the previous screenshot. The D3D stats display information from the render device. D3D9RHI if you are using DirectX9, D3D11RHI if you are using DirectX11.

    Some very important values here:

  • DrawPrimitiveCalls: The number of draw calls.
  • Triangles Drawn: The polycount. Note that the polycount may not reflect the actual polycount of the models in your scene. The hardware often processes a model several times, for example to calculate occlusion, dynamic lighting, complex materials, decals, and so on. Triangles Drawn displays the combined total and may therefore be several times higher than what you might have been expecting.
  • Stat ES2

    This command is the iOS equivalent of Stat D3D9RHI. It outputs information from the iOS render device.

    As this screenshot was taken from within a regular PC game all values are 0. This command will only work when used on a iOS device. Like Stat D3D9RHI, Stat ES2 exposes the Draw Calls and Triangles Drawn to you.

    Stat InitViews

    Handles Occlusion calculation. What mesh can or cannot be seen currently? The engine and the hardware have to continuously check which objects can or cannot be seen, and that can quickly get out of hand, especially on weaker hardware such as iOS devices.

    Of particular importance:

  • MaxDrawDistance Dropped Primitives: The number of objects removed through raw distance culling. If object is more than X units away, remove it. This is the fastest way of removing objects, performance wise.
  • Statically Occluded Primitives: The number of objects removed through precomputed occlusion calculations. This only works when the level rebuilt with Precomputed Visibility set up, which was not the case in the level used in this example.
  • Occluded Primitives: The number of objects removed through real time occlusion. This is the slowest way of occluding objects.
  • Stat Collision

    Should be especially checked when working with a physics/vehicle intensive game and/or weak hardware.

    Stat Memory

    The memory taken by the various parts of the game. How high things can be depend entirely on your target device/platform.

    Stat StatSystem

    Rendering statistics in itself takes performance, Stat StatSystem shows you just how much. When accessing the framerate it is important to have as many stats turned off as possible.

    Stat Engine

    Of particular important:

  • Terrain Render Time: The time spent on the terrain(s).
  • Terrain Smooth Time: Time spent on smoothing out the terrain(s).
  • GameEngine Tick: The time spent by the code on updating things. A high number here very likely indicates an Unrealscript problem.
  • Stat Game

    These are all values that have something to do with the processing of UnrealScript and Kismet.

    Copyright 2006-2014 Hourences.com - UDK, Unreal, Unreal Engine are trademarks or registered trademarks of Epic Games, Inc. All other trademarks are the property of their respective owners

    Website Design by 1clickwebdesigns.co.uk
    Powered by Wordpress