We have a massive Skiing Slope, that is thousands of studs away, it used to only fully load when you teleport to the area, now many of our maps are loading on spawn and always visible.
If you have a MeshPart that is larger than 2048 studs in any dimension then we may treat that MeshPart as persistent. If the MeshPart is part of an atomic model this will result in the entire model being treated as persistent.
Is it possible for you to ensure that none of your MeshParts are larger than 2048?
Hello @CorvusCoraxx
Yes, that was our previous knowledge, but something has changed in the past weeks.
Could you try to replicate the instruction on the post?
As you can see all these meshes are Size 50x50x50
If you make them size 10x10x10 the bug will dissapear.
The map is huge and without clear rules it is extremely difficult to order any changes to the team.
I ran a script on all descendants searching for sizes > 2048, there are none, i believe it is not possible to do so, we never could reach such sizes, one of our developers had issues with the 1024 threshold in the past tho, it seemed to have lowered, which seems to be another issue which i cannot confirm.
Looking at those parts in Studio it seems like none of those MeshParts have a MeshId or MeshContent. I’m not actually familiar with how MeshParts that don’t have MeshId’s are handled. Did these MeshParts have actually meshes attached in the past? If I do attach meshes to them then the sizes are reasonable and the model no longer is treated as persistent.
I rolled back to when they had meshIDs, selected every mesh and made them 2000,2000,2000
Bug Still happening. Althrough when it’s 1000,1000,1000 it doesn’t.
Also if i add a regular part/cube size 2048 it is treated as persistent again.
If the cube is size 2047 it doesn’t.
Is there a clear number or method we can deliver to the team to proceed with these changes?
I know some models push bounduaries of the engine, but it is very hard to provide changes when you don’t know how much is enough.
Perhaps a warning saying a part is being treated as persistent? or a code that could check for that issue. Any tool that could help us, thank you!
If you can provide me a place id of where you want to do your testing/editing I can enable some logging to indicate what parts are causing the models to be treated as persistent. It will only show the first part that exceeds the limit inside the atomic model, but it should allow you to iterate and identify all the problematic meshparts.
Hey @CorvusCoraxx
Managing this issue has been really hard to the team, thank you for your time helping us out.
workspace.TestHere.ThisModel"SCALE THIS PART"
Thats the 2048 part causing it to be persistent and 2047 size part causing it not to be.
Could the streaming team review this file? I think there is something wrong that started 2 weeks ago, mesh parts really became very sensitive to size when it comes to streaming, but now even regular parts have weird behaviour like that, doesn’t seem to be logical to have this property.
I do see that parts that appear to be exactly 2048 in Studio somehow end up a bit larger than that when we access them deep in the engine code. I wonder if floating point precision issues are showing up somewhere.
At a high level is the issue you are concerned about is that parts are visible earlier than previously? There are efficiency reasons for us to treat these very large parts as persistent so we can avoid some spatial processing.
Our issue is that every zone in our game is loading in and being treated as persistent. 2 or so weeks ago, whatever system that changed in the back end is treating all of our atomic areas as persistent and loading all of our worlds at once. This is drastically effecting performance for our players.
We aren’t able to correct our worlds if the rules you are stating are not accurately being treated as the guideline. Is there perhaps a way to schedule a meeting for our devs Gustavo & Rich to receive hands on assistance from you or another team member?
The rules are that if any Part/MeshPart has a size in any dimension that is larger than 2048 that instance will be treated as persistent. If that instance belongs to an atomic model or to a mechanism then that model/mechanism will also be treated as persistent. Unfortunately it looks like that can be a bit tricky for instances right around the 2048 limit because when multiple transformations are applied in the engine floating point precision can get us over the limit.
Since it sounds like this change we rolled out is causing performance issues for your players what we can do is temporarily disable the change for your published experience to give your team some time to make changes to the parts that trigger this behavior. We can enable the additional logging on a private experience so that it is clear what parts are over the limit. That way you will have time (weeks or months) to make adjustments without impacting your player base.
Hello @CorvusCoraxx
I got a 1400,1400,1400 cube to cause it by itself, when orientation is removed from it, bug stops. Bug_3.rbxl (100.2 KB)
workspace.TESTHERE.TestModel.THISCUBE
We are still doing some tests, parts.Size.Magnitude > 2048 seems to be close to the threshold for any angled part (not mesh), but it’s still not exact, it’s a few studs off
