A part type with absolutely no physics


#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.


#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.


#23

Sorta like Source’s trigger brushes?


#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.