Reposted at request of staff to add repro file in PM, actual bug is here: StreamingEnabled causing parts to become visually offset from their bounding box/actual position
thanks devforum for locking staff dms behind age stuff lol
A private message is associated with this bug report
@moochezz Thanks for sharing the repro! We believe the issue is related to how some of the models in your game are using SLIM.
Currently, there are very large sections of the map contained within a single model that has SLIM enabled. Because the entire model is not available on the client at once, the client falls back to the LoD representation of the model. That is why you see the visual offsets.
To avoid this, we see two potential options:
Make the model Atomic under ModelStreamingMode. This ensures that whenever any part of the model becomes eligible to stream to the client, the entire model is sent together, in this case, the entire island.
Break the large model into smaller, spatially localized models (likely Atomic models), and enable SLIM on those smaller models. This would allow the individual sections to stream in and out as units while still benefiting from SLIM when the full model isn’t available.
The second approach is generally preferable for very large models, since SLIM works best when models are spatially and logically localized. The documentation also recommends breaking up models with very large spatial extents into smaller modular models.
This documentation may also be a useful reference, as it covers Model Level of Detail and some of the considerations around model structure:
I was able to solve most of it with your suggestions, however I do have one remaining case of this which confuses me.
I’m destroying a Model that has ModelStreamingMode set to Persistent and LevelOfDetail set to Disabled (or Automatic) on the client at runtime, after PersistentLoaded has fired, causes the model to be removed from the explorer, but remains visible, now with the same visual artifacts as mentioned before. Streaming docs explicitly state that “Persistent models are not subject to normal streaming in or out”, meaning that this should not be a case of client-side desynchronization, nor should it be an issue with SLIM as it is disabled on this model. The model also does not have any ancestor models. Is this also intentional behavior?
@moochezz Thanks for reaching out.
So if I understood correctly you have a Persistent model with no LoD and you destroy it on the “client” side once PersistentLoaded signal is fired. Is that correct?
Could you confirm if this Persistent model is under another model with LoD enabled? If so, once client removes this model, the outer model with LoD enabled will be deemed incomplete and client switches to showing its LoD.
Besides that, I’m curious if you could share more details on what you’re trying to achieve with this pattern. If the goal is to have a model persistent only for some players (and Atomic for other players), you could potentially look into using PersistenPerPlayer capability of streaming.
I realized that it’s occurring because one of the inner models still had SLIM enabled, so the parts from that model were the ones that were stuck after removal 
Anyway, the reason that we need some models that we can delete on the client is because of story progression in our game. Certain parts of the map must be removed by the client when a player progresses. This, of course, will not work with a standard streaming setup because the server will stream the model back in. Creating a client-only version of the model is also oftentimes not a viable solution in our game, as the server will need to be able to interact with the model while it is visible. As far as I’m aware, PersistentPerPlayer also won’t work here, because it will still stream atomically back to other players who need the model removed.