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.
13 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.
I have a question! anchored true does not mean ignore all physics??
1 Like
Here’s another workaround without modifying CanCollide, CanQuery, Anchored, etc.
Create a WorldModel instance under workspace and parent whatever you want to it.
This may or may not be an intended behavior so it can be removed in the future.
I haven’t done much experiments on this.
Also. Sorry for bumping this old thread.
1 Like
Does WorldModel ignores physics?
This feature request has been fulfilled with the addition of the CanQuery property, which disables any interactions with physics. and the CanTouch property which prevents any Touch events - which were both added in 2021.
This topic should just be closed. The feature has been added. There’s nothing left to discuss.
1 Like
This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.