I’m wondering the same thing here.
I’m working on a character collision system using capsule colliders, and I can’t get collisions to register on terrain, only physical parts in the world. Unlike you, however, I am using GetPartBoundsInRadius though.
Are there plans to add terrain detection in this API?
but gettouchingparts doesnt return an empty table if cancollide is off
From the developer API reference:
If the part itself has CanCollide set to false, then this function will return an empty table UNLESS it has a
TouchInterest(AKA: Something is connected to its Touched event).
– https://developer.roblox.com/en-us/api-reference/function/BasePart/GetTouchingParts
ah explains it all, thank you man
It was returning terrain. Now it’s not. You are right.
@Razorter @EtiTheSpirit @GMaxZet
None of this API includes terrain right now, which matches the old Region3 API behavior. (However, Part:GetTouchingParts will include terrain)
We could add this though, probably via an OverlapParams.IncludeTerrain parameter?
I’m sure I had Terrain instance there. Must been a glitch.
It would be cool to have the ability to query the terrain using this API. Thank you, you rock!
Terrain is technically a part so yes please. If it’s also possible, can you add IgnoreWater so it’s consistent with RaycastParams?
I doesn’t say anywhere on the developer hub that the Region3 functions are deprecated.
Because they haven’t been marked as that yet, but trust me, if a Roblox Staff Member says that they’re deprecated then they’re deprecated.
I wonder if the first parameter (PartInstance part) of the third new function introduced (WorldRoot:GetPartsInPart) actually includes the MeshPart. If no, then this third new function is pointless since we can basically do it using the first new function 
I’m sure it will work, if not then imagine the hitboxes people have to create with just squares and spheres. Ouch.
That means the third function is custom and free for all, sounds nice! 
If it doesn’t, im sure Zone+ is updated and/or updating their module with the latest query API for all to use 
I can’t get it to work with MeshPart bones!
Is it because OverlapParams checks against part.Position and for bones should check for bone.WorldPosition (or bone. TransformedWorldCFrame.Position) ?
I think this method needs a boolean version. Bool = IsPartInPart(PartA,PartB) If I want to ask if a certain part is simply overlapping another part. Such a function may be less intensive on game performance and a lot simpler to use.
That’s what I wanna know. Though, I did run GetPartBoundsInRadius in a fast loop and its an extreme resource hog (talking like >50% CPU usage). I find that looping through the parts and checking their distance with the good old (pos1 - pos2).Magnitude was less resource intensive, but I do understand why as it’s trying to factor in the bounds of a part rather than just a simple distance check from their positions.
Update on this: I did a test to see which is faster (Region3 vs BoundsInRadius).
These were my results (each was ran 10 times):
All times:
0.1491571000078693
0.13990179996471852
0.14120559999719262
0.13626439997460693
0.1535322000272572
0.1385526999947615
0.14146419998724014
0.16613239998696372
0.13969529996393248
0.1388802999863401
Average:
0.14447859998908824
All times:
0.3513048999593593
0.3413050000090152
0.3363081999705173
0.3346049999818206
0.3367011999944225
0.3251165000256151
0.33610730001237243
0.32732949999626726
0.33658229996217415
0.33615290001034737
Average:
0.33615127999219113
As you can see, Region3 is still largely faster
These times have been cleared up by @kleptonaut
So your saying, that Region3, a recently deprecated thing is still faster than the new flashy OverlapParams?? Roblox can’t be that high to deprecate a system thats faster than the new one.
I mean, Region3 just takes the part positions in a square. PartBoundsInRadius takes into account the bounds of the part though. Of which is more expensive to calculate instead of just its position.