When we were preparing to build the mini map for the World Partition map, we found that the map size seemed to have become abnormal.
[Image Removed]Here are the basic settings of our World Partition:
[Image Removed]
We attempted to build directly to verify whether it would return to normal upon completion. However, after executing Build World Partition Editor Minimap in the editor, the process had been running for 7 hours without finishing, and we ultimately had to cancel the build.
[Image Removed]
We would like to know what typically causes this kind of issue. It seems like it could be related to bounds or something similar. Are there any effective debugging methods you would recommend?
I have attached the build log from this attempt. Since it ran for about 7 hours, the log file is approximately 2 GB in size. I’m not sure if this would be helpful for analyzing the issue.
Additionally, we are also providing the cvars we used, which are included in the attachment.
Hello, I’m adding some info here for clarity: IsSpatiallyLoaded is what enabled the behavior that world partition manages when an actor is loaded. If true, the actor will be loaded depending on whether the player is nearby its bounds. For actors that affect the entire level, like this one, they should definitely not be spatially loaded.
The fact that an actor with enormous bounds expands the minimap is expected behavior. That actor should not be spatially loaded, based on the fact that it should be loaded at all times no matter where the player is in the world.
You’re welcome! Since you already found the solution of unchecking Is Spatially Loaded, which I agree is the correct solution, I’ll close this case again.
We added a Volume in the scene, but it didn’t seem to improve much. In the WP Editor, the map size still appeared very large, and the build process was extremely slow. So we eventually removed the Volume.
We would like to know if there is a way to investigate what specifically is causing this issue. It feels like it might be related to something like Bounds, but it seems there isn’t a good way to debug this.
For example, is there any tool that can check the size of object bounds in the scene, or any other debugging methods?
There’s still research to be done on my end, but wanted to give two more suggestions to look at in the meantime.
In the Show Flags menu, you can view bounds by going to Advanced->Bounds. If there is an actor with bounds larger than normal, you should be able to visualize it this way.
Thank you very much for your reply. We tried using Advanced -> Bounds, but the result was not ideal. Since there are too many objects in the scene, enabling it directly causes the editor to freeze, so we haven’t been able to perform an effective check. We would like to know if it is possible to implement some editor tools to perform automatic scene checks.
Regarding adjusting WORLD_MAX, it does affect the map size. However, since our maps vary in size, we don’t have a good way to adjust WORLD_MAX, so this solution probably won’t work for us.
[Image Removed]
We will continue investigating the cause, and if there are any updates, we will communicate them here.
There are also several Get Bounds functions that returns “the bounding box represented as box origin with extents and also a sphere that encapsulates that box”
that could be helpful, most likely the one that checks static meshes. You would likely also want to use Get All Actors of Class or another similar Get function to iterate through every actor in your scene, though if you have many actors you may need to create your own data structure to capture them.
Thank you for your suggestion. I have tried some of the functions you provided, but they were not very effective in detecting the bounds information of objects in the scene. I will continue exploring to see if there is a better way to implement a similar tool.
We will continue investigating the cause, and if there are any updates, we will communicate them here.
I am awaiting a reply from Epic regarding the support of third-party plugins, so I would like to inform you there is no guarantee that the issue with this plugin will be solved.
From what I can tell in my own tests, setting “Relevant for level bounds” to false should have solved the issue on its own, but it does not.
I also did not see any relevant code in the Sky Creator classes that would affect this, just as you said.
It may be due to which streaming source it’s automatically being assigned to when “Is Spatially Loaded” is set to true.
However, I would try testing to see if any behavior changes by assigning the TOD actor to a custom data layer so you can determine the streaming source yourself, and set “Is Spatially Loaded” to true.
If the same behavior occurs, I would leave that bool false, and for good measure set “Relevant for level bounds” to false as well. In the repro project also set every one of the actor’s attached components bool “Use Attach Parent Bound” to true so that the bounds of the object weren’t immensely large for no reason (which I was able to visualize from the info I gave earlier in the week).
1.Regarding “Relevant for level bounds”, we have tested it and it has no effect at all.
2.You are correct, when “Is Spatially Loaded” is set to false, it works perfectly fine.
3.As for placing the actor inside a Data Layer to control it, we tried that as well, but it still caused the map size to change.
4.Thank you for the suggestion. The “Use Attach Parent Bound” setting is indeed something we had not considered before. We will try setting Use Attach Parent Bound to true and see if it makes any difference.
At the moment, our workaround is to call SetIsSpatiallyLoaded(false) in code, which ensures it does not affect the map size.
Please feel free to share any new suggestions if you have them.