UE 5.1 World Partition nearly-infinite loop building minimap (small level)

Development World Creation
1

I have a test project that was created in 5.1 (not migrated) from the Archviz template demonstrating level variants. This project was working fine, although being new there’s not much in it yet (just one landscape and my archviz structure, total size about 1 km x 1 km). Though I started from the template, I created an empty open world level and my own landscape, leaving the demo level as a reference.

I needed to set up a nearly-identical test sandbox for a team member, so I used the Launcher to clone the working 5.1 project. I opened it, and all seemed well, until I created a new Level from the Empty Open World template. I added a smaller Landscape (about 0.5 km x 0.5 km), set up my landscape auto material, and saved all. Then, with all regions (only four of them) loaded, I told the editor to rebuild the minimap for the new level.

The editor pinned one of my CPU cores at 100%, and the minimap had not finished after over 90 minutes. I waited that long in case it was compiling shaders, since I happen to have started the minimap build shortly after changing the landscape material. Task Manager did not show any shader compilers, but I thought perhaps they were no longer separate processes in 5.1. After deciding I’d waited too long, I killed UE editor from Task Manager.

Reloading the project and trying again, I watched the output of the editor log and observed that the bounds it had used for computing the size of the level were from circa -4 trillion to +4 trillion, and it had processed hundreds of thousands of cells out of a total of “a large negative number caused by integer overflow”.

Since I’m a programmer, I dug into the UE source code, and I believe the problem is caused by the builder thinking the cell size is zero, thus no matter what size the level is, there are an infinite number of cells. In the World Partition details panel, the level bounds have been calculated as zero in all dimensions, and these are non-editable fields.

Looking further, I noticed that the BoundsVolume object was duplicated in the level, and that both of these had scales of zero in X and Y, and a large positive number in Z, making an extremely thin vertical cuboid. I deleted one of the BoundsVolume Actors and manually set the size of the other one to enclose my landscape plus a bit of padding in all three axes.

I had hoped this would fix the problem, but it didn’t, and in fact it seems to have no effect on the calculated number of cells or level volume. The log messages are identical.

To make this even stranger, I reopened the project and attempted to reopen the level that came over as part of the clone. The UE editor became unresponsive and eventually failed with an Out Of Memory crash, overflowing my 64 GB RAM.

Going back to my original project that I cloned, the level that previously built correctly now hangs the editor. So apparently something broke before I cloned the project, but I can’t imagine what. Interestingly, in the original project, there are non BouldsVolume Actors present.

I should also mention that the Stop Build button displays the “Stopping Map Build” message but has no further effect, even after I waited over an hour in one test run just to see if it would eventually terminate the build.

This is possibly (likely?) due to something I’ve done wrong, but I have other World Partition projects and have not encountered this before. I’m going to try reproducing this problem with a fresh project that is not created from the arcvhz template, on the theory that the problem may be related to whatever process Epic used to upgrade the template itself.

In the meantime, if anyone else has experienced this problem, please chime in with your suggestions of how to fix it.

I have not yet filed an official bug report, because I want to do the other tests I’ve mentioned. I’m also working on getting a source-built UE 5.1 so that I can inject some additional logging into the minimap build method. The existing code does have a check for whether the bounds are valid, but clearly they are not and yet it’s passing that checkpoint. My goals are, first, to have a workaround so I can continue my project, and second, to submit a bug report to Epic that also includes details of where I think the problem is in the code.

Even if this is caused by my own configuration error, or by a problem in the templated, the editor code should not attempt to build “infinity cells” with no graceful way for the user to abort the build – so some defensive code would be useful here.

2

Quick update: A new project with an empty World Partition level successfully builds the minimap. I haven’t tried creating my landscape again, loading my material, etc., so this is not a definitive test yet. I’m going to eat lunch while the shaders compile.

3

Were you able to figure out what was up?

4

Not yet, though I haven’t given up. As a workaround, I’m using 5.0.3 which so far has not thrown the error for me.

I can’t repro the error on 5.1 unless I have World Partition (which makes sense given the minimap is n/a – what I mean here is that making the same level without WP removes the error). I can’t repro the error on 5.0.3 at all.

5

Back before world partition, minimaps were created with a scenecapture2d and stepping through landscape componets center point (from bounds) to get the tile shot that would be merged onto a full texture.

If you make yourself the same bluetility script you’ll never have any issue dealing with whatever the engine code messed up…

This is ofc assuming you are using landscape tiles. Also note that you cant rely on the component index to build the map/move the camera.

If you aren’t using landscape, then set the process up to take screenshots at known distances by doing math, and you’ll be ok.

You need to calculate how many total tiles you want taken, then divide your known total size of each side by the square root of the total tiles you want. Use those as the max values of 2 loops to drive X and Y, and set your step value to “total size / square roof of total tiles”.

The end result will be a final image of whatever resolution you want (up to 8k total, unless you export and combine outside the engine), that is slightly better than the minimap - however screencapture2d in Ortho mode does not include shadows.
This can be good or bad depending on what you need for your art style.

1 Like
6

Thanks! That’s a great summary of a useful technique.

In this case, the minimap is for use in the World Partition dialog panel in the editor, so I’d need to take the output of your technique and place it in that role. (Given that we have full source code, in theory I should be able to discern how to do that through code inspection.)

We had an in-person collaboration gathering last week on a different project, so I’ve been away from this issue for a few days. I’ll be getting back into it in the coming days.

7

I think I finally have a clue what’s going on here, and a workaround that has so far fixed the problem for me in several test iterations.

The WorldDataLayers Actor in the affected levels was throwing a warning in the Message Log indicating “Actor needs to be resaved”. I thought I was taking care of that by doing a Save or Save All after seeing the warning, but it seems that was not the case.

The workaround is to right-click on any WorldDataLayers Actor in the Outliner and choose Save Selected Actor(s) from the context menu. After that, I am able to rebuild the Mini Map without crashing.

So far this method has worked in every level I’ve tested.

There is still something strange going on with respect to WP in 5.1, however. In one level all the LandscapeStreamingProxy Actors were greyed out as if unloaded, but the landscape was all clearly visible, and when I entered PIE mode the editor crashed with a memory access violation. I sent the crash report to Epic for that. It may be that something was corrupted on that specific level, because I have not reproduced that behavior on the other levels. Perhaps during one of my earlier crashes the Actor files were corrupted somehow.

I would appreciate reports from anyone else who has been able to reproduce the bug described in my OP, and see if this workaround is also effective for you.

1 Like
13

Another quick update: The workaround I posted may not cover the entire problem. It definitely helps, but I’ve now observed that the same issue can happen during HLOD building.

I have not yet attempted to reproduce this in the new UE 5.1.1 that just released.

14

This still happens in 5.1.1. Seem to happen when I use migrated assets or copy paste a large number of assets at the same time? Does not happen in 5.0.2. Resaving the world data layers and the World partition minimap allowed me to at least click on the world partition tab as before this would cause memory crash while attempting to allocate memory? After saving all building
works fine but the minimap build is still not working. It is stuck on processing cells?

15

My inspection of the UE 5.1 source code (this was 5.1.0, not 5.1.1, but I doubt this section changed much) and the log messages suggested to me that the error happens when UE calculates a finite overall landscape size but a cell size of zero (or something that rounds to zero with floating point precision limits). The code determines the number of cells by dividing the overall dimension by the cell size, so the number of cells is incorrectly determined to be infinity, or an extremely large number.

I still haven’t quite deciphered where or how the cell size is determined. I’m experienced in programming C#, Java, and C but am just learning C++, and the UE engine source is an unfamiliar and complex code base without a lot of embedded comments. The upshot is that I understand the local logic and what it’s doing with the data, but I’m not certain where the data originates that it is receiving. (I should also mention that I’m a Linux guy normally, and Visual Studio is a brand-new IDE for me and not what I normally use, so I haven’t learned the VS debugger yet.)

I’m sorry not to be more helpful on this issue. I have to balance working this problem against my company’s project deliverables that don’t depend on this specific task. I haven’t given up on solving this and contributing a solution, but it may not be as soon as I would prefer, and I’d welcome any input from experienced C++ coders.

16

I forgot to mention, in reply to your “memory crash” comment, that on my system if I allow the loop to continue for an extremely long time, UE editor will eventually crash with an out-of-memory error. This takes quite a while on my workstation because I have 64 GB RAM, but I’ve observed the crash more than once with that clearly being the error message. I also have watched Task Manager as the RAM footprint of UE slowly grows over time when this loop is running. There is clearly (to me, at least) a slow memory leak involved, but I believe that memory leak is secondary to the [nearly-]infinite loop caused by the cell size miscalculation.

17

Placing a WorldPartitionMiniMapVolume fixed the issue for me. The WorldPartitionMiniMapVolume overrides the map bounds the code is trying to calculate and sets them to those of the volume. We now get a proper texture in a fraction of the time. Nowhere is this mentioned in documentation. I had to inspect the code to find it and got lucky with a UDN post that mentioned it in passing. Hope that helps.

3 Likes