Don't enter local physics simulation on single parts that can't be collided with

Feature Requests Engine Features
#1

In my game I have a very physics-heavy derby mode where many player-controlled vehicles clash to destroy eachother. However, as parts fall off the vehicles it starts to get very laggy for players who are near those parts, and I’ve found this to mainly be because of local physics simulation. Here is a video which demonstrates the issue:

The parts in the video are configured to not collide with other vehicles at all using collisiongroups, so the physics simulation is completely unnecessary in this case and just causes extreme physics lag.

If Roblox is able to address this issue it would be great improvement to the performance of the physics engine and prevent unnecessary, hacky and server-costly workarounds such as adding force-less BodyGyros or BodyPositions to every object that shouldn’t have physics simulation. It’s something I’m planning to do but decided to post this first in hope of a real and better fix.

If this isn’t possible to do I would instead like to suggest an official way to disable local physics simulation on objects that don’t need it for your use case. (If this can already be done in a good way please let me know!)

7 Likes
#2

Anchor the loose parts once they stop moving. That should help a lot. You can do this by simply watching the magnitude of the velocity and rotvelocity. Once it drops below a certain threshold, anchor the part. Something like this:

while (part.Velocity.Magnitude > 0.1 and part.RotVelocity.Magnitude > 0.1) do wait(1) end
part.Anchored = true
6 Likes
#3

Thanks, i’ll probably do this too if I have to. It doesn’t fix the inital lag spike when a lot of parts are destroyed at once though, which is probably the most severe in my use case since atleast one car is always right next to the parts when they fall off initially.

1 Like
#4

True. I think your post here shows a larger problem. If parts shouldn’t collide due to collision groups, then it doesn’t make a lot of sense that you’re getting performance hits for it. I guess my suggestion is more of a workaround for the problem, but I hope that the actual problem can be addressed or explained by a Roblox engineer. Maybe it’s a bug?

#5

Yeah I wonder, hope some roblox engineer can update

2 Likes
#6

Hi Panwellz - What game is it? We’ll take a look.

Thanks.

2 Likes
#7

Car Crushers 2: [6 New Cars!] Car Crushers 2 - Roblox

Use this teleporter in the lobby to get to the derby servers

image
image719×416 226 KB

1 Like
#8

From the microprofiler in your video it looks like most of physics time is spent in stepContacts. Collision contacts can still be generated in parts that shouldn’t collide if either of them are listening for touch events. Is the car listening for touches?

Allowing you turn all collision checking off even if a part is listening for touch events is something we hope to include in the future.

#9

The cars have 3-4 hitboxes with touch events connected to them, but the parts shouldn’t have anything connected.

I’ll try disabling the car touch detection tomorrow and see if that changes anything, will update here.

1 Like
#10

I still seem to get pretty much the same performance hit after disabling all touch events and redoing the test in the video. I’ve gone through all my touch functions in Find All Scripts and scanned the workspace for TouchTransmitters during the test, but nothing was active.

The parts still light up as red when getting close to them with “Are Owners Shown” enabled however, and that’s when the lag starts. Don’t know if that’s the problem though.

1 Like
#11

Could you send a repro where I can drive the car through some rubble and take a closer look? You can DM if you prefer.

From Physics Best Practices:

When parts are highlighted red, they are being simulated on your device, but you do not own it. This is generally just a transitional state used to avoid instability. The parts become simulated for a frame, then are corrected by interpolation.

If the parts are staying red when driving through and not eventually matching the color of the car, there could be another problem, but I’ll need to take a closer look.

#12

I think I understand this, and this might be a limitation of how “on contact local simulation” is implemented. Even if objects can’t collide, we still may have contacts with them that are put to sleep.

Can’t promise a short timeline, but I think I can make this happen fairly simply in the near future.

3 Likes
#13

This fix would still be very useful. It would be good to have the garuantee that physics isn’t calculated between two objects when it doesn’t need to, without needing to add deprecated bodymovers or doing other workarounds.

Are there still plans to go through with it at some point down the line?

2 Likes