There is only 1 unanchored assembly in the entire scene (the character, which uses a custom controller). Everything else is anchored, so I’m really confused as to why this is getting caught in a loop like this! Is it LoD with terrain physics?
Can you dump the actual microprofiler file so that we can take a look at the information present in the labels? It looks like a single WorldStep is taking 25ms, and it seems to imply that the step is “Throttled” (meaning everything that is not a Humanoid is ignored for physics simulation). So its safe to assume that somehow your player character + stuff in the world alone is enough to cause 25ms of simulation time to simulate 4ms of physis.
Hmm, I was wrong, I don’t think there is any throttling… What I am seeing though is that the Solver has 216 assemblies that have 1653 collisions.
Also, if I look at a different part of the microprofile I can see that whatever the client is, it has 224 Mechanisms that it owns for simulation. The list bellow can be read as such:
AssemblySetPhase 0 - 1 : Number of Mechanisms your machine authoritatively owns, simulates and sends updates about. Affects Solver , Narrowphase , Broadphase load.
Whenever debugging Server physics performance check this first, is the solver simulating MORE than it should?
AssemblySetPhase 2 - 3 : Number of Mechanisms your machine locally simulates, but corrects using interpolation informed by the authoritative machine responsible for the mechanism (could be a server or another client). These are most likely objects that are potentially interacting with objects that you authoritatively own, and therefore need to be simulated. Affects Solver , Narrowphase , Broadphase and Interpolation workloads.
AssemblySetPhase 4 - 7 : Number of Mechanisms your machine does not simulate at all, but will interpolate. Affects Broadphase loads.
AssemblySetPhase 8 : Sleeping Mechanisms that should have no physics load.
Based on that alone, it seems like you have 224 Mechanisms that are not anchored and are owned/simulated by this client.
A general thing that confuses me is that normally if WorldStep goes above 3ms, we trigger “throttling” which skips physics work for any objects that aren’t considered time-critical, like player characters. Somehow, I don’t see anything triggering throttling here…
Is this a mobile test against a production environment or are you doing something special for testing against Studio?
The camera seems to be running at max framerate but I can’t move my character (physics owned by the client, moved using a BodyVelocity)
I was trying to get a video but the app closed and then killed the session. I believe the issue might be something building up in our scripts. Is there a way to get a list of all assemblies being simulated by a client (in Lua) so I can figure out what shouldn’t be there?
This is a mobile test in our development universe ([DEV] Lobby - Roblox)
I can grant you access if necessary!
Wait the camera is running at Max framerate? This is extra confusing because according to the MP you posted you should be getting 3 to 4 frames per second…
What you are describing sounds like throttling eventually DOES kick in and because your characters are not Humanoids, they aren’t considered “Player Characters” and they stop simulating as well. This will cause everything to seem to be running in ultra slow motion. Throttling is probably running in 1/16th time.
Could you by any chance capture a microprofile when framerate is running max, but the world is unresponsive?
As far as identifying what parts are from the Microprofiles, there isn’t a good way. You may literally have to have a script that scans the world for unanchored parts.
So this is most likely the cause of throttling and bad behavior on your client. Not exactly sure how to track this down besides a Lua script that traverses the entire datamodel and looks for un-anchored things. Probably a LocalScript in case you are spawning things on the Client but not the server.
Would mechanism be a single part or assembly of parts?
We have ~12 NPCs that have anchored Root parts, but their rigs animate to do things like look at you when you walk past them.
I have 1 character (~2 parts on the server) and 5 mobs (1 part on the server) currently visible. On the client they are each one rig
So for 200 assemblies to exist we must have some kind of memory leak in our scripts? Is it possible these assemblies could be parented to nil and still simulating or would they definitely be in the workspace?
I’m not sure I understand how to use the microprofiler to count assemblies. It shows a total of 5 assemblies when running the same test on my laptop, however I can count at least 9 rigs in my frame that are animated.
As far as a client is concerned, things that are owned by the server or other clients, are considered “Anchored” unless they require local simulation by being in proximity to something that you own/simulate authoritatively.
I’m unable to make my android or laptops reproduce the issue. I took a microprofile from the android device (OnePlus 3T) and the iOS device (iPhone X) at the same time.
I realize it’s probably a bit premature to try labelling this as an iOS bug, but with limited debugging tools this is all I’ve noticed out of the ordinary so far. After standing still on iOS for a while it will “declog” itself of the lag and you can resume playing at a very nice framerate. But the OnePlus performs much more consistently.
I built some debug tools and was able to figure out the cause!!
So, this is caused due to one of our scripts creating a part. This was actually due to a fix we needed to implement for StreamingEnabled.
You see the arrows leading the player? The part they lead to would be streamed out, so we needed to write something to create a part at this position. The code had a glitch causing the part to be created in a slow loop - which the iOS device was much quicker to show symptoms to (lower memory?)
Thank you for the help interpreting the microprofiler! I was able to build some tools to count parts & assemblies that will make debugging much quicker on mobile in the future.
I put in a request with our documentation team to migrate an internal doc I wrote on how to utilize the microprofiler to debug physics behavior to the developer hub.