1/12/2024 0 Comments Memory monitor android![]() (root) World /Game/Maps/Zones/Zone_Temperate_Urban.TheWorld->CurrentLevel Here's a sample of the output for this example: This takes a few seconds and then outputs to the log a dump of reference chains from the GC root to the target object. ![]() From within the instance of the game where I took the profile, I run "obj refs name= S_Hex_Urban_Standard_03 shortest" from the console. The next tool to use is the obj refs command. Using this, I can quickly gather a few suspects for what might be loading the expensive mesh. In this case a blueprint is referring to it, and if you double click that blueprint, you can then see what refers to THAT. With the reference viewer you can quickly navigate references and see what is referring to an object. Then, right click it and select Reference Viewer, which will give you a view like this: The first is to load up the editor and find the asset in question in the content browser. There are two good techniques to track down errant references. Something is referencing this asset and loading it in when it doesn't need to. We have a single static mesh that is taking a full 3MB of memory, and it's not a mesh that I expected to be loaded because it's not needed by the part of the game I was playing at the time. So, to see the amount of memory used by a certain class, take the 1st and 4th column values and add them. ResKBytes is less useful in this case because it includes shared resources, so in the Material case, the ResKBytes total is artificially inflated by including the same shared textures once per Material. UObject::GetResourceSize is the function that determines the resource size for an object. NumKBytes is the amount of memory used by the UObject's body in memory, while ExclusiveResKBytes is the amount of memory used by non-UObject "resources" that are solely owned by that UObject, such as sound buffers. ![]() For the memory columns, you care about the first and last columns, which are the accumulated memory of all instances of that class. I found a version of this line in a memreport:The first column is the class name followed by the number of instances of that class. I first looked for issues by searching the output of "memreport -full" and looking for large assets that seem out of place. Let's use an example from Fortnite to show how you would use tools in the engine to figure out why a certain asset is loaded. It's also very useful to take before and after memreports, and use a text diff tool to compare them. Using memreport you can quickly see where your memory is going. Here are a few lines from a Fortnite report: The output of the "obj list" needs a bit of explaining. The -full command also has sections for individual assets like static meshes or textures and is useful for looking for individual expensive assets. After that are some sections for rendering memory, the status of loaded streaming levels, and spawned actors. The next section is the output of the "obj list -alphasort" command, which lists all UObject classes and how much memory they use. You can search the source for the name of a memory stat like "STAT_PixelShaderMemory" to see exactly what contributes to it. The first part of the memreport file lists the overall memory usage, with sections for platform-specific memory usage and all registered memory stats. You can change what commands run for your game if you wish in your own engine.ini file, but the default commands are a good place to start. These are simple text files that contain the output of running all commands inside the (and for -full) section of BaseEngine.ini. memreport files tagged with the map name and time stamp. Then, look inside YourGame/Saved/Profiling/MemReports for. To use it, open the console with ` and run "memreport" for a fast report or "memreport -full" for a more complete report. My first step is always to use the memreport command. I use these tools and techniques here at Epic to optimize Fortnite’s memory use and load times. Luckily, UE4 has some useful tools built in to track down what’s in memory and why. As new assets are built, games tend to become larger and larger until load times slow to a crawl and the game starts to run out of memory. When a game reaches a certain stage of development, it becomes critical to figure out what exactly it’s loading into memory and why.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |