Expand BasePart.Touched event

Feature Requests Engine Features
#1

A person by the name of nighttimeninja314 came up to me today and asked me if I could post his client idea on the devforums. I don’t know if it’s allowed or not, but here goes:

“If you could post this on Suggestions and Idea thread on my behalf, that’d be amazing.”

"Currently, the only parameter the BasePart.Touched event provides is the part that was touched. Because we do not have access to mesh data for irregularly shaped objects (MeshParts, CSG, Etc), It would be extremely helpful if we could expand the event so that it contained the following parameters.

(Formatted similarly to the wiki’s API class)

Parameters:
OtherPart
Type : BasePart

Center
Type : Vector3

MTV
Type : Vector3

The parameter “Center” would essentially be the center of the collision location. For example, if the main part is exactly on stud above the touched part and they both had the same size, center would be the very center of the touched part’s top surface. This parameter would return a Vector3 if the touched part is either on the surface or intersecting the main part. Otherwise, it would return nil.

The parameter “MTV” (Minimum Translation Vector) is a vector that describes the minimum amount of movement the touched part would require to stop intersecting the main part. If the touched part is on the surface or is not intersecting the main part, it would return Vector3(0,0,0)

Now, I can see that this may be a bit expensive to calculate every time a collision is made, so if this is not possible, I’d recommend calculating the new parameters through the following methods.

part:CalculateCollisionCenter(otherPart)
and
part:CalculateMTV(otherPart)

(Naming can change)

Thank you for reading this."

I hope he gets support for this, it seems like a very good idea!

(If an idea like this has been posted before I am sorry.)

4 Likes
#2

I’m not a scripter, so sorry if I messed up on anything here.

#3

I don’t see very many uses for this (although that doesn’t necessarily mean it shouldn’t be a part of the API)

Basically what I want to say is currently for non union, or non meshparts calculating the collision center between two parts is do-able.
Unfortunately there’s no real good way to allow this with meshparts of unions as it stands because we don’t want to make the file format a readable property of the object (that’s a massive security risk you would be running, as players would just copy/paste the value of the property into a fbx file and load it into blender if they were stealing assets)
So in regards to meshparts and Unions I see why this might be useful.
(I only bring up it being a readable property is players wanted to make their own collision functions.)

A logical problem with this post is the MTV part, MTV in most cases can be derived from the center of collision.

I would suggest giving the user this link ( Documentation - Roblox Creator Hub ) so that they can make a collision system as articulated as they want.

#4

He replied with this:

"Thank you for your response.

Calculating these properties is indeed possible and I’ve tested it out with simple parts. Wedges, corner wedges, spheres cylinders and such take much more work as exceptions must be made for their unique geometry. My personal take on solving the problem was okay, but extremely inefficient. I feel that this would also be helpful in cases involving terrain as each material has different geometry patterns.

If the reason we don’t provide mesh data is to counteract asset theft, why can’t we just expose the collision geometry instead? It is rarely close to the asset’s visual shape and can potentially be discovered using some sort of difficult and expensive raycasting methods."

#5

I think the use cases are very scarce, it needs to be elaborated upon why you would need this. If this will be used for a custom physics engine then that won’t work, you need more information than that. For complex shapes you will also need to know all detailed information on the geometry of the shape (i.e. convex decomposition) before you can properly handle physics and collisions.

I would also like to say that it isn’t customary to act as a middle-man like this (not just the OP, but the entire thread), and you should ask people for permission when you want to share what they said to someone who’s not on the forum. (Since this is a private forum category.)

#6

I won’t comment on the proxy suggestions thing at the moment, but I will throw in my two cents for a use case, as I’ve thought about this kind of feature before.

The main thing I would like to use something like this for is visual effects. Imagine if you will a metal part scraping against stone, and you want to have sparks fly. For this you would want to know where the collision occurred so you know where to center the effect.

2 Likes
#7

If something like this ever happened, I would prefer that it be a query-based thing rather than bloating the Touched event with more data that you might not ever use or want. Something like PhysicsService:GetCollisionPoint(partA, partB).

1 Like
#8

My 2c: Collision position would be extremely useful information to have. MTV would not be useful information for most practical purposes.

ninja’d me; I was about to post exactly that.

1 Like
#9

Fair 'nough. Or even returning a table of all of the contact points.

5 Likes
#10

Definitely. It’d be nice if there was a pleasant way to define a collision manifold, but you’ll take what you can get…

1 Like