Blocker - Creative (only) - Memory issues

Making this post here until there is a category for normal Creative, will prob move it there later.

So I wanted to raise concern into memory and specifically XL islands in Creative atm, because for the past year there have been issues introduced that have made memory management and optimization harder to control and balance. I will list those below for full context. This post is not UEFN-related btw, just normal Creative.

  1. Display of memory

The hardest and biggest change in memory management in XL originally and now in all Creative islands has been to know what is your max memory. Currently, you only know the memory of the memory cell your player is standing on, but that prevents you from knowing if a prop you are adding is actually affecting the entire island memory or just the cell you are on.

Originally, it used to be that you d always see the highest cell in the island, then once you pick up a prop you would then see the cell you are currently standing on. This was a great design choice because it gave us insight into everything using only one memory bar. Now you just have the same memory regardless and it changes constantly based on where you are looking which makes things even harder to optimize. In fact, the original design was so precise that I could visualize the range of which a prop derendered and its memory wasn’t counting where I was standing, now this is impossible regardless of workarounds and approach.

A good example of an optimization that we can no longer do is when we deleted a prop we would see whether initial or instance cost would be subtracted from memory, which gave us insight into whether that prop was the last of its kind. Adding to that, before we would even see the subtraction cost (initial or instance) only by hovering on the prop, now it only shows the instance cost even if it is the initial cost that will be removed, so we have to keep our eyes into the memory bar and see what gets subtracted. However, this was also removed in the last update, and now you see a completely different memory bar when deleting things, which makes optimization even harder. And this is the main reason I am making this post because in just this one area we have seen our optimizations become harder 3 consecutive times, feels like we are taking steps back on that front.

  1. As a side effect of 1), we can no longer tell if something is a prop or a device in terms or memory (affects current cell or all cells), because we don’t know how to see all cells being raised in memory if we only see one. The only way atm is to have 2 accounts be at the same island at the same time and place the said prop then look into both to see if they both increased (players are far away from each other). This was something we could originally do when the highest memory always showed.

  2. A couple of updates back, when the algorithm to determine memory was introduced, a massive amount of maps had a massive memory increase (I 've had 4 maps increase in memory and one of them increased by 20k which is 1/5th of the entire budget). This change alone caused me to kill 2 major projects that I have been working for months, and there is no way for me to optimize them without 1) and 2) (and besides, I had them very optimized because I always do that, meaning I have to delete content or move a massive amount of geometry to lower cluster congestion).

  3. Minimap/overview map only renders what is rendered around the player, it would be ideal to render the entire map instead, even if it comes at a cost of never changing in gameplay (maybe an option we can choose?). The reason behind it is in large maps that have different regions and key POIs, you need to see everything not just what you are close to. Imagine BR minimap/overview map without seeing the entire map.

  4. Deleting a prop changes memory in a weird way now. Hard to know how much you deleted (and whether it was instance or initial cost removed). Hovering preview is not accurate either (only shows instance cost if removed, not initial cost). Notice that memory changes 4 times on top even though I am doing 2 actions:

  5. Island memory (visually) capped at 100k (added last update). How are we to know how much we need to optimize to bring it down to the needed limit now? This is 8k over, but I don’t know how much to optimize now that the number simply says 100k:

  6. A big issue is that over 100k memory locks editing, testing and publishing. Used to only be editing (only for adding things) and in case of new updates we were able to fix game settings and republish. Now we have to remove content all the time once a new update decides that memory is now increased (has happened more times than I can count the past 2 years).

I can showcase all these in a live session if needed. DM me if you have any questions.

EDIT:

  1. Autosave lags Creative when it happens, past 50k memory. Since autosave is frequent, so are the jitters. Depending what are doing at that moment it may affect it because during that quick jittering 1 sec anything doesn’t register, including player controls, and once it ends everything reverts back 1 sec, with your player teleporting to a location that the server thought you d be. This causes us to accidentally delete unwanted things, as we lose control of the character (and this happens very frequently on large islands).

  2. T doesn’t show thermo numbers for me, so its not helpful unless I see the full number per cell (not just thousands) so I can tell if a prop with initial say 512 memory adds to the surrounding clusters, how far and where it stops counting.

  1. Memory vis updates on cursor position, not player position. This causes confusion for memory optimization because when you delete a prop the cursor will point to what is behind it and change the memory, making it more confusing.

Thank you so much, @Wertandrew. :heart: I will get this in front of the right folks.

I’m going to prefix this with, moving forward it’d be helpful for our teams to avoid Core Creative Only posts here in the forums until we are ready to expand for that. We want to make sure that we can maintain focus on UEFN as efficiently as possible and avoid distracting too much from it as there are also different teams that work on different aspects between Creative and UEFN.

But at the same time I don’t want this to feel like it falls on deaf ears, and I happen to have insight into these in particular so I’ll address them as best as I can. Note these are all considerations for Core Creative, UEFN introduces a lot of additional complexity and hence is an entirely different conversation and one actively being discussed.

For anything I mention as bugs, please do continue to report them in the official Creative Discord. Frequency of reports is something taken into consideration for prioritization sake, so don’t worry if you or someone else has already reported it.

So for #6, you should be able to toggle to the Number version of the heatmap map. The “thermometer” keybind cycles between No Heatmap, Heatmap without Numbers, and Heatmap with numbers. The numbers should show you exactly how much over 100K you are. If not, then that’s definitely a bug.

For #7 (over 100K memory locks editing), definitely a frustrating experience we are aware of and we have a plan in place to improve this experience. Stay tuned.

#5 (deleting prop memory inaccuracy), preview should definitely be accurate and that’s a bug. As for the memory shifts, hard to tell for sure, but I believe the memory shifts are related to the fact that the thermometer is adjusting based on what you are looking at (which constantly changes as you work with props). Also something we’d like to address as well.

#4 (minimap at all times) due to how the minimap generation works in Core Creative the only way to render it all on the map is to actually having all the objects spawned, which would risk blowing out memory on platforms. BR’s minimap is a completely different system and is not feasible for how Creative works sadly. Since we are in the UEFN forums… as we introduce the ability for larger islands in UEFN, the original minimap system needs to change as it’s not going to scale well. It’s something that is actively being discussed. There are pros to the current system (like dynamically adjusting for runtime changes like player builds and destroyed structures) that are difficult to account for with other solutions. So this is definitely a TBD, but something we are aware of.

For #3 (massive memory increase on projects), it’s slightly related to #7 and my next few notes on #1/2.

For #1/2 (display of memory and memory impact), the current display of the thermometer isn’t ideal and its difficult to understand the impact of placing a prop. We want to show more information overall and have it be more comprehensive for debugging purposes and we have newer designs being discussed so that’s TBD. But we are definitely aware of that need.

Overall memory is a hot topic internally for sure, but also a difficult one. The feedback is definitely appreciated and helps us ensure we course correct as needed. But I do want to reiterate, that it’ll be helpful for our teams to maintain the focus of the UEFN Alpha forums on things related to UEFN. :sweat_smile: :sweat_smile: :sweat_smile:

2 Likes