Introducing OverlapParams - New Spatial Query API

Note: I’ve updated my initial reply to the benchmark post to address inaccuracies.

GetPartsInPart should be just as fast as GetTouchingParts, it’s mostly the same process internally. I’m saying I’d avoid calling it every frame if InBox or InRadius would suffice.

It does both, it’s just that the InRadius and InBox functions don’t do narrowphase, which is why they are faster.

Yea, I think the plan would be to allow you to pass in a Part to GetPartsInPart even if it’s not in Workspace/WorldRoot (like it could just be in ServerStorage). We aren’t able to do this yet however. Do you think that would be sufficient?


Yah that would be sufficient for what I’m doing.


Awesome feature that I have been waiting for a long time! I had to use EgoMoose’s rotated region module to be able to run regions with rotation. The one thing I have a question about is the WorldRoot:GetPartsInPart. Would there be any method that would allow checking the region with a reference instance (could be a meshpart) where you would supply the size and cframe for? For example: WorldRoot:GetPartsInReference(MeshPart, CFrame, Size).

1 Like

I am in support of this as it sounds very useful. My current method is just assigning them to a collision group when they are added as a descendant of workspace.

[/spoiler] ok it sounds great! I could use this in my placement system[spoiler]

I remember asking for this feature 6 years ago, my prayers went through!!

Thanks so much, the rotatedRegion3 module broke a few months ago and started becoming unreliable so this is a welcome update and I can finally remove my band-aid fixes.


Can we get an OverlapIgnored property on OverlapParams which would work the same way as WorldRoot:ArePartsTouchingOthers()? Or maybe a CubicAreaOverlapIgnored property?

1 Like

So can someone clear this up for me, is this perfomance wise better than region3, gettouching parts. and can i use these new methods to replace them for hit detection, combat, abilities.? because i’ve seen some comparison saying that new methods are slower

Hopefully this helps you to decide what to use :).

1 Like

can finally get rid of this silly line :cowboy_hat_face:

Finally had the chance to play around and introduce these into ZonePlus. All-in-all, really awesome, it’s finally great to have an official substitute for RotatedRegion3 on top of all the additional performance gains!

Expanding upon this, it’d be great to have an option (for instance a property within OverlapParams) to return parts outside the Workspace (such as in ReplicatedStorage), in addition to being able to pass through objects not in Workspace.

With ZonePlus, we essentially reverse how checks are performed. Instead of casting queries on the zone parts themselves, queries are instead performed on player characters, using the zone parts as a whitelist.

This has been one of our most heavily requested feature and would be a really neat addition to the API!

Then with ZonePlus we could create a new constructor that generates parts from a given region and parents these to ServerStorage/ReplicatedStorage (which is currently impossible to do):

local zone = Zone.fromRegion(cframe, size)

This is already possible, you simply need to put the parts outside of the workspace inside of a WorldModel, and you will be able to raycast and region query against them on the WorldModel the same way you would against parts in the Workspace by calling those functions on the Workspace.

Returning a mixture of parts from different physical spaces doesn’t make a ton of sense, but creating a separate physical space for parts to exist in via a WorldModel already works.


The post talks about baseparts, but I’m curios if this would work on anything else. Notably, meshes and terrain?

Meshes and Terrain are technically BaseParts as they inherit from that class so the answer is, probably yes.

Are there any plans to have this support terrain? This would save me a lot of time programming and probably resources too if done because my solution now is to use raycasting to get terrain.

1 Like

This is perfect for my dynamic destruction script!

Support in what way? Terrain is voxel based, so you can naturally query whether cells are full / empty using the GetCell / GetCells ReadVoxels API

1 Like

Terrain::GetCell is deprecated, and Terrain::GetCells dosen’t exist.
Use Terrain::ReadVoxels instead.


My bad, thought I remembered the API off the top of my head but I should have looked it up. My brain is still thinking in 2014.