A part type with absolutely no physics

Support

1 Like

Attachments? Can you please give a more clear use case I’m having trouble seeing what this would be used for.

2 Likes

When you put a mesh/particle/light/sound in a part solely for the visual effect, roblox does a bunch of physics operations in the background for no reason. This takes up unnecessary processing time and it can become significant very quickly, especially with a lot of these effects.

2 Likes

I believe particles, lights, and sounds all work in attachments as of recently thanks to @Davidii.

I could see a use for it on meshes, though. Sometimes I wanna weld things on a character that do absolutely nothing ever physics wise.

3 Likes

This doesn’t make parts obsolete. You’re restricted to a zero-size emitter if you use attachments.

15 Likes

this has gotta happen, support

it’d probably not be placed in “BasePart” but more into its own seperate group “NoPhysicsBasePart” (or something like that)
“NoPhysicsMeshPart”, “NoPhysicsUnion”, all that stuff.

1 Like

There’s tons of uses for it. Parts that don’t interact with physics and can’t be detected by raycasts and pathfinding service and all the jazz.

Basically a way to create lots of lightweight parts that don’t lag if you make tons at once.

Could be used for things like flamethrowers, tree leaves, fog, special effects, and distant details.

9 Likes

Support!

2 Likes

In Unity, this is the default behavior until you explicitly add in certain physics components for an object. Of course, this would be counter to Roblox’s original vision of everything being simulated in-game (is that still the ultimate vision?)

I think this feature would be great for game makers. But I’d love to see some stats as to how much performance gain is achieved by doing this versus anchored and non-cancollide parts. Especially on mobile.

7 Likes

Since the dawn of time we’ve been able to make things anchored and non-cancollide, and people have done it in nearly every popular game. It has huge performance benefits compared to simulating every single thing on the screen, which allows games to both look decent and run on phones. But the performance benefit could be so much greater if there was a way to completely ignore all physics.

10 Likes

indeed it would

2 Likes

we need this

1 Like

Support - Even for inanimate objects like grass that just sit in the workspace, this would be useful for. It would allow for a lot more particles and a lot more detail without sacrificing performance. I would, however, like to make sure that this would include meshes placed into the parts. Foliage would be a great use of this.

6 Likes

we still need that …

2 Likes

Wow, I didn’t know those things work directly in an attachment. That’s a step in the right direction.

And yea I also need the ability to stick a SpecialMesh or MeshPart on a character that does nothing with physics

5 Likes

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

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

Sorta like Source’s trigger brushes?

2 Likes

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

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.