Hello, I have two issues. If one needs to be made a separate ticket I can do so.
Issue 1: Under high stream load and using PersistentPerPlayer models, the player is disconnected from the game with the following error message: ‘readRegionRemoval error total time exceeded’. The example I have given is extremely artificial however I was able to repro last night myself without this script constantly streaming things in and out.
Issue 2: Having a PersistentPerPlayer model seems to significantly degrade performance permanently. We have broken the map up into chunks to try mitigating the issue but it still never fully recovers. For instance without these persistent per player models I get ~240fps but with the persistent per player models I get around 180-200fps. The game also freezes up for a second or so any time we remove/add a player to persistent models (ie the player changes maps) but I’m unsure if anything can be done about that. Streaming also seems to take a lot longer to initialize with these persistent per player models. There isn’t much in each model either, last time I checked, only 112 parts in the largest model.
I am sorry to say that we currently do not have a solution, though we are aware of the root issue and we are working on it. This is a result of having, spatially speaking, large PersistentPerPlayer models, as even for models with few parts they contain large individual parts. These are putting strain on the server whenever they are streamed in or out as we try to update the spatial tracking for a given player, causing us to hit safe guards as you have found. This is likely what is also causing the second issue as well, as there is spatial tracking on client for these models as well.
Again, we are working on improvements for these issues, but in the short term I can recommend trying to break up large models if possible. I tested higher numbers of chunks and found the first issue is mitigated. Further, if shifting maps via teleport is common and somewhat predictable, there is also the Multiple Replication Focii to help preload these areas.
Alright it’s no problem, I will see if we can come up with something to break up the map even more. I have a couple ideas but have two questions: Approximately what volume should we aim for per model if there is some target (or what number of chunks did you try that mitigated the issue)? Will a small part with a large mesh (specialMesh.Scale) still be treated as having a small volume? I’m thinking since the player won’t interact with the terrain, collisions don’t matter, and we could do something like moving all parts to a small area, sizing the actual parts to be small, making the mesh the actual size of the part, and using mesh.Offset to position the parts.
There isn’t a set per model volume that would work best, it depends on the individual model dimensions. I went overkill to 32 chunks, but I think a smaller number could yield similar results. Trying to keep models in ranges of 1024 studs in any dimension will help server side, though lower end clients may still be affected.
As for the mesh part modification idea, the extents are calculated based on the part size, not the mesh size, so this theoretically would solve this issue. However, I would do this very cautiously as it would affect streaming behavior for clients who do not have this set as a persistent, leading to odd behavior for streaming.