So I had a conversation with ChatGPT about how to achieve this, but would appreciate anybody wanting to add to the techniques suggested in this discussion.
Me: With UE5.1 using world partition, because of memory or GPU limits loading heightmaps larger than 16321px square has proved difficult, is there a mechanism to load in or out alternative levels in a surrounding grid so that you could have a player literally walk across levels seamlessly, and so architecturally have a grid of levels? I am thinking to use Nanite in this scenario, which now works with Landscapes, although an option might be to make individual meshes from the heightmaps.
ChatGPT: Yes, it is possible to use a technique called “level streaming” to load in and out different levels in a surrounding grid, allowing a player to move seamlessly between them. This can be done using the built-in Unreal Engine features, such as World Composition for landscapes or streaming levels for meshes. Nanite can also be used in this scenario, as it has been integrated with Unreal Engine’s landscape system and can stream in high-resolution geometry on-demand. Another option could be to create individual meshes from the heightmaps, and use Unreal Engine’s built-in level streaming feature to load and unload them as the player moves through the world. The choice of approach will depend on the specific requirements of the project and the hardware limitations of the target platform.
Me: With level streaming do you define each heightmap as an individual level and if so is there a limit to how many levels can be encapsulated in a project? and how can line of sight be effected across level boundaries?
With level streaming, each heightmap can be defined as an individual level, and multiple levels can be loaded and unloaded as the player moves through the world. The number of levels that can be encapsulated in a project will depend on the hardware limitations of the target platform, as well as the complexity and size of the levels themselves.
Line of sight across level boundaries can be affected by the level streaming technique used. If you are using streaming levels with BSPs, the line of sight will be determined by the BSPs. If you are using streaming levels with meshes, the line of sight will be determined by the meshes.
One way to handle line of sight across level boundaries is to use a “portal” system. A portal is a special object that is placed at the level boundary, and it defines a transition between two levels. The engine will use the portal to determine what should be rendered in the player’s view, based on what is visible through the portal. This can help to maintain continuity of the player’s view as they move between levels.
Another way is to use precomputed visibility or Light Propagation Volumes that can be used to illuminate the scene, giving the perception of the player having a line of sight across the level boundaries.
Ultimately, the best approach will depend on the specific requirements of the project and the hardware limitations of the target platform. It’s also worth mentioning that a good balance between level size and number of levels should be achieved in order to have good performance and maintain a good player’s experience.
Me: What is a BSP? When you talk of what can be seen through a portal are you talking about a circular or square device for instance, what I perhaps should of expressed was the notion of a full horizon in the being visible across the adjacent level! Of course the target platform will have limitations but are we talking about install space? Would it be possible to limit the applications footprint in memory and GPU by loading levels from disk as required?
BSP stands for “Binary Space Partitioning”. It’s a technique used in 3D computer graphics to divide a scene into smaller, more manageable pieces. In the context of Unreal Engine, BSPs are used to create simple geometry for level design, such as walls, floors, and ceilings. BSPs can be used in conjunction with streaming levels to define the visibility across level boundaries.
ChatGPT: When I talk about what can be seen through a portal, I’m referring to the concept of a “view frustum”, which is the 3D shape that defines what a player can see in the game world. A portal is an object that is placed at the level boundary, and it defines the transition between two levels. The engine uses the portal to determine what should be rendered in the player’s view, based on what is visible through the portal.
In terms of the application’s footprint, it is possible to limit the memory and GPU usage by loading levels from disk as required. This is known as “on-demand loading” and can help to reduce the amount of memory and GPU resources that are used by the application. However, it is important to keep in mind that this can come at the cost of increased load times, which may not be desirable for certain types of games.
It’s also worth noting that the amount of storage required for the levels is also an important factor to consider. It is possible to compress or optimize the levels to reduce the storage required. Additionally, the levels can be split into smaller chunks and loaded on demand, which can help to reduce the amount of storage required.
It’s also worth mentioning that the target platform will have limitations, such as the amount of memory and storage available, the CPU and GPU performance, and the internet connectivity (if the levels are being loaded from a remote server).
Me: So lets say that in game a player was standing on a hill and had an unobscured view of the horizon as he would with natural 360 degrees vision, well perhaps 120 degrees without turning his head, so we could not then use BSP’s to divide the scene. Or could we? And lets say we used 4k size levels as tiles in the grid, representing 4km in the world, with an Earth sized world, the horizon would be perhaps 3 to 4 tiles away and the line of sight take in a broad swathe as well, marking a quadrant encompassing several tiles. Is this achievable with any of these techniques you described?
It is possible to achieve an unobscured view of the horizon with a player standing on a hill, using the techniques that I described. However, the specific approach will depend on the requirements of the project and the hardware limitations of the target platform.
ChatGPT: One approach is to use a combination of BSPs and streaming levels. BSPs can be used to define the visibility across level boundaries, but they will not be able to capture a full 360-degree view of the horizon. However, you can use the streaming levels to load in additional levels as the player moves through the world, which will allow them to see more of the horizon.
Another approach could be to use the Nanite technology which can stream in high-resolution geometry on-demand, this will allow you to have a high-resolution view of the horizon, but it will come at the cost of higher memory and GPU usage.
Me: As for the level size, using 4k size levels as tiles in the grid, representing 4km in the world, you would have a big amount of levels and this could be a challenge in terms of performance and storage space. However, it’s possible to split the levels into smaller chunks, which can be loaded on demand, this will reduce the amount of storage required and improve performance.
ChatGPT: It’s important to keep in mind that the line of sight will take into account the distance of the horizon and the player’s field of view. Therefore, it’s possible that you’ll need to use a combination of techniques, such as precomputed visibility or Light Propagation Volumes, to ensure that the player can see a broad swath of the world while maintaining good performance.
Ultimately, the best approach will depend on the specific requirements of the project, the hardware limitations of the target platform, and the trade-offs between performance, storage, and visual quality.
Me: Lets say the target system had mid-level capabilities (I realise this is quite vague) what would be a better level size than that which I suggested? And are you saying that you could only load smaller chunks from neighbouring levels?
ChatGPT: The best level size for a project will depend on the specific requirements of the project, the hardware limitations of the target platform, and the trade-offs between performance, storage, and visual quality.
For a target system with mid-level capabilities, a smaller level size would be more appropriate than the 4km x 4km size that you suggested. A good rule of thumb is to keep the level size as small as possible while still maintaining the desired level of visual quality. For example, a level size of 1km x 1km or smaller would be more appropriate for a target system with mid-level capabilities.
When it comes to loading smaller chunks from neighboring levels, it’s possible to use a technique called “chunked loading” or “cell loading” where instead of loading the entire level, the engine loads smaller sections of the level (or “chunks”) as the player moves through the world. This can help to reduce the amount of memory and GPU resources that are used by the application, while still allowing the player to see a broad swath of the world.
It’s also worth noting that preloading certain areas of the level or using a multi-threaded loading system can help to reduce the load times and improve the player’s experience.
Additionally, it’s important to consider the trade-offs between the level size, the number of levels and the hardware limitations. A good balance between these elements should be achieved in order to have good performance and maintain a good player’s experience.
Me: So using “chunked loading” or “cell loading” where instead of loading the entire level, the engine loads smaller sections of the level (or “chunks”) as the player moves through the world. Would that mean that chunks from the current level as well as neighbouring levels could be loaded simultaneously thus making seamless line of sight across levels?
Yes, using “chunked loading” or “cell loading” can allow chunks from the current level as well as neighboring levels to be loaded simultaneously, which can help to create a seamless line of sight across levels.
ChatGPT: When the player moves through the world, the engine can use their position and the camera’s field of view to determine which chunks of the current level and neighboring levels should be loaded. The chunks are typically loaded in advance of the player’s movement, allowing the engine to have the next set of chunks ready to be rendered as soon as the player enters them.
This approach can help to create a seamless line of sight across levels, as the engine can blend the visible chunks together to create a continuous view of the world. The chunks are typically loaded and unloaded as the player moves through the world, which can help to reduce the amount of memory and GPU resources that are used by the application.
However, it’s worth mentioning that this technique can come at the cost of increased load times, which may not be desirable for certain types of games. Additionally, it’s important to consider the trade-offs between the level size, the number of levels, the chunk size, and the hardware limitations. A good balance between these elements should be achieved in order to have good performance and maintain a good player’s experience.
“So I had a conversation with ChatGPT about how to achieve this” 
