It’s still detecting collisions (“touches”) for physics despite this property. Performance will not improve when you disable this property as collisons are still calculated for these parts. Going through your entire game and disabling this property for all your builds won’t improve performance in your game, especially considering no Touched events are connected to these parts in the first place.
1 Like
It will improve if CanCollide is set to false or the CollisionFidelity is set to Box though.
Finally this is built in, the performance ease impact is going to brilliant. I for one have tens of thousands of parts in one game using hacky workarounds for CollisionGroups against non touch applicable instances.
Collisions are still calculated for parts with CanCollide set to false, going through your builds and making them all CanCollide false wherever possible does not enhance performance afaik.
Changing CollisionFidelity on Unions and MeshParts to something like Box or Hull over Default will improve performance as there is much less work to calculate collisions for that part.
This stated in my post:
Parts with CanCollide may also be generating unnecessary physical contacts with other parts when CanCollide is True, finding these parts and disabling CanCollide on them can improve performance.
8 Likes
How does this behave if the property is changed after a .Touched event connection is created?
I’d say it’s always worth it if you know the part will never need to collide or fire a touch event on anything.
The performance improvement you see is going to depend on how many parts, their size, how much they are moving, and how many parts were colliding with them before.
Also as I stated, the full performance improvement will not be relevant for another week or so (it’s coming with general collision improvements across the board)
5 Likes
@ProbableAI @Blizzya
Touch event will disconnect and error will throw, updated the post to answer this!
2 Likes
that behavior is strange. You’re disabling CanTouch on the client so it shouldn’t affect server sided Touched events? This looks easily exploitable
2 Likes
Well the connection is client sided in the video because I ran that code on studio command bar while toggled to client so there is literally nothing exploitable there.
As you can see in this screenshot, when you connect it from server and change the property value on client, it doesn’t care:
1 Like
I understand this new property’s application for performance increases and convenience, though I am kind of confused what it would be used for otherwise. Are there any example use cases where this is foremost necessitated?
P.S Saying it determined first impressioned me it returned a comparison result if they could, but I realized it sets the property instead.
1 Like
Is there any use to this feature apart from the performance? or am I missing something?
1 Like
Another great studio update by Roblox! First the baseplates, then the orientation indicator, and now the CanTouch property!
Keep up the great work, Roblox!
1 Like
How much of a performance gain is there for BaseParts with CanCollide set to true but CanTouch set to false?
It can simplify your Touch event filtering.
Let’s say you have a car game with cars made of ~100 parts each. Maybe you have a Part on the car with a touch event listener for processing vfx when the car hits obstacles (maybe there’s more than one!). Let’s also say there are several other cars, but none should collide with one another (ie ghost racers).
Without CanTouch, whenever cars move through each other there could be 100+ touch events firing on each car. You would need to manually add logic to the touch event connector to filter out those parts and still take the performance hit of 100 touch events.
With CanTouch (and Workspace.TouchesUseCollisionGroups), you can easily filter out the parts you don’t want to fire touch events, without adding more code.
I don’t think there are use cases that absolutely necessitated this property, but it can significantly simplify things.
10 Likes
Setting CanTouch to true for a part with CanTouch set to false which is within another part will cause a crash in both studio and in-game 100% of the time:
Expected behaviour:
Behaviour after CanTouch went live:
Repo open-source place:
https://www.roblox.com/games/6166477769/ZonePlus-Playground
This will significantly impact games with ZonePlus that utilise zone.partEntered and zone.partExited events:
19 Likes
If you want an object to be completely ignored in .Touched events, this new property is a much better solution than creating a global ignorelist table.
2 Likes
Thanks for the report, investigating now.
We have disabled this for now due crashes in certain cases. I’ll post here when it’s active again!
32 Likes
What can I expect in terms of performance optimizations for a game where literally every single object in workspace is Anchored and non-CanCollide? This also includes things like humanoid character models – literally everything is Anchored and non-CanCollide. I also don’t use any raycasts, region3’s, etc; humanoid state is set to not do anything. I also move every single part in workspace with one BulkMoveTo batch CFrame update call.
1 Like
This could’ve been really handy several years ago! My friends and I ran an experiment back in 2014 with two identical cars: one drove and the other flew. The flying version generated measurably less lag because the wheels never came in contact with the ground. Putting this level of control in our hands opens intriguing possibilities.
3 Likes