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
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).
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
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.
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):
As you can see, Region3 is still largely faster
These times have been cleared up by
Your time difference comes from using a whitelist on your PartBoundsInRadius check. Every check spends additional time building the descendants table and then checking every identified part against that table. You region3 query doesn’t do this. It’s generally never beneficial to include the entire workspace as a whitelist.
Additionally, the query dimensions are different. For region3, you defined a region from -80 to 80, so that’s a “radius” of around 160.
If we use a whitelist for PartBoundsInRadius
and Region3, the average times are nearly the same:
If we eliminate the whitelist from both, you get these better times over all, still nearly the same:
You’re also creating a new OverlapParams object for every query. If you just create one, and reuse it every time, you can improve times even more. These are the times if I only create
one OverlapParams and one Region3 object and re-use them for every query:
Now, for the sake of completeness, we can try creating one OverlapParams object
with the whitelist, and same for Region3 with whitelist. Here we see the biggest difference, since OverlapParams queries can more efficiently use whitelists.
Finally, your benchmark doesn’t actually involve finding any parts other than the baseplate - so we aren’t really testing the actual speed of detecting parts. I placed ~40 unanchored parts on the baseplate, and we get the following times (no whitelist, and reusing the OverlapParams and Region3 objects)
So in conclusion, we can see that GetPartBoundsInRadius is around 2x faster than Region3 queries.
But , this should be expected. Radius checks are cheaper than box checks. Let’s try the last test one more time but comparing to GetPartBoundsInBox :
The conclusion stands, the new OverlapParams queries are faster than the Region3 query counter-parts.
Hope this helped clear things up!
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.