A part type with absolutely no physics

Feature Requests Engine Features
#21

This would be an extremely useful feature. Parts with the sole purpose of being rendered with no other unnecessary baggage would be an invaluable tool.

Possible use cases:

  • 3D skyboxes (ie. mountain ranges, open fields, other details the player will never interact with)
  • Small, dense, world details
  • Parts intended to be used within GUIs
  • Parts used as containers for things like ParticleEmitters and SurfaceLights
  • Parts that are purely for non-solid detail such as foliage

These parts would never need to be interacted with. No physics data updating whenever these parts are moved, no events other than those inherited by Instance, no non-visual properties, and no interaction with physical constraint systems.

Stripping all of these unnecessary details could provide a lot of performance gain to games that are already pushing the envelope, and with so much of Roblox’s playerbase living on mobile where constraints are much tighter, any performance improvements are extremely valuable.

Some fun stats comparing the impact of canCollide parts

Disclaimer: I am not a statistician.

For curiosity’s sake I was mucking around with Studio today trying to see if I could measure the gain from using noCollided parts. I settled on trying to measure the difference in PhysicsStepTime for different scenarios.

These are just rough numbers because I didn’t have time to run a bunch of trials.
These were collected on a baseplate with a stack of 1513 anchored, “touching” parts. Parts were 72x53 and 0.05 studs thick for the trials not involving intersections, and 1 stud thick when doing trials involving intersections. The camera was not moved between trials. There were four trials for each stat, each trial an average over 30 seconds. All four trials were averaged to produce each of the numbers below.

  • With collisions, with intersecting parts = 0.0185ms
  • With collisions, no intersecting parts = 0.0197ms
  • No collisions, with intersecting parts = 0.0129ms
  • No collisions, no intersecting parts = 0.0152ms

PhysicsStepTime for “No collisions, with intersecting parts” is 30.27% less step time than “With collisions, with intersecting parts”.
PhysicsStepTime for “No collisions, no intersecting parts” is 22.84% less step time than “With collisions, no intersecting parts”

These are very small numbers to begin with, and I am not a statistician, so I’m not sure if any of this is significant, but it doesn’t look like these differences are imaginary. By removing collisions (but nothing else) we appear to shave down physics step time by a significant amount.

12 Likes
Does CanCollide off help with fixing up lag?
#22

It might be nice to have a ProximityTrigger like in Cryengine. Basically, it’s a remote event with a physical presence in the workspace, and when a player enters its proximity, it’ll fire and something can respond and happen. But it simulates no physics and only fires when a player touches it.

4 Likes
#23

Sorta like Source’s trigger brushes?

2 Likes
#24

This would be a great feature to have for use with meshparts and unions - especially since having Default collision fields cause a huge amount of lag when crossing with another part.

1 Like
#26

Support! I am currently using making a system that creates parts used for effects only client-sided for more smoothness and better fidelity. However, one problem that I keep running into is the use of welds. If I try to weld a local part to a part the server can see, replication completely breaks, as detailed by this thread.

However, if we had the ability to create parts that don’t use physics, this problem should not occur because the weld won’t need to send extra physics data that doesn’t make sense to the server. By adding non physical parts, a developer not only gets more performance, they get more ways to use said parts in their creations.