As a Roblox developer, it is currently too hard to find parts which are tangent or “close enough” to tangent to eachother, especially with complex part geometries.
If Roblox is able to address this issue, it would improve my development experience because it would allow me to find parts which are touching, or at least are close enough to touching within some desired threshold or envelope.
My primary use-case and motivation for this would be for joining touching, but generally non-interesecting parts, or otherwise doing logic based on part tangencies. Kind of like a “will it MakeJoints” API but more generalized.
Currently, a common strategy is to use GetPartsInPart with a very slightly up-scaled part, however this only works on surfaces with normals that point away from the origin of the part, since any other surfaces will actually be reduced, and is likely much more expensive than it needs to be for the suboptimal outcome. (Afaik it’s also not technically completely sufficient to cast on both upscaled and downscaled parts for more complex geometry too even though this does do a better job for interior surfaces)
A small envelope or more robust/mathematical way to find part tangencies in the form of a spacial query would be great for many abstract applications.
Expectations
These are some behaviours I think the average developer would probably expect to see in a feature like this (regardless of the technical complexity that might be required)
- If a part is physically resting on another via the physics engine you would expect them to be considered tangent
- You would expect the above to hold true regardless of the grounded status or physics properties of the part, aka you’d expect it to be deterministic and not dependent on the physics simulation
- You would expect the above to work with Ball parts, MeshParts, & Unions with complex geometries
- For ball, block, and wedge parts you would expect this to be mathematically robust like with
MakeJoints - The behaviour on interesection is unclear and could be undefined, or it could be well defined - I think the most useful behaviour would be to have intersections included but this is just my opinion
- I personally might be inclined to expect poorer performance than spacial queries, and I would expect an API like this to be aimed less at realtime applications, however this only arises from the particular use cases I would have for this feature. Other developers would certainly see this differently I think.