Introducing OverlapParams - New Spatial Query API

Finally! I’ve been waiting Roblox to release this feature. I’ll be using this in my games! :smiley:

Goodbye with complex things to figure out rotation regions! I hated having the hacky methods.

1 Like

Is there any reason why there is no broadphase with narrowphase like with collision detection?

Also in the future is it possible to add a function which uses geomtry data we pass to see what parts are in it?

Like with a new type called ‘Geometry data’.


This is amazing! No more complex math just to find all this out. I will be using this almost immediately for a project of mine. Contact points and normals included with this or ? If not, please add it. It’s so useful.

While still very useful, unfortunately OverlapParams makes the same mistake that RaycastParams made with filtering. I’ll just rip from a suggestion message I sent to the dev engagement team regarding RaycastParams last week:

The current filtering method is useful but the functionality could be expanded much further. If I want to, say, filter out parts from the raycast whose transparency is 1 and that aren’t collidable, I would have to do either of the following:

  • Generate a RaycastParams object with all the transparent, cancollide=false objects on the map right before the raycast begins (very inefficient)
  • Make my own raycast wrapping function. It would initially raycast with no filter and then check if the returned instance fits my condition ( if RaycastResult.Instance.Transparency < 1 and RaycastResult.Instance.CanCollide then return RaycastResult end ), but re-raycast with the last object filtered with RaycastParams if the condition fails.

This is frustrating since I have to use a wrapper function for basically every case where filtering would be useful. If RaycastParams allowed for a callback function to be passed through and called internally before returning the RaycastResult, it would make the filtering process much easier.

Code example:

local RaycastParams =
RaycastParams.Filter = function(Part)
    return Part.CanCollide and Part.Transparency < 1

local LaserHit = workspace:Raycast(game.Players.GFink.Character.Head,, 1, 0) * 1000, RaycastParams)

The same problem and solution can be shown here with hardly more than just finding+replacing RaycastParams with OverlapParams. Allow us to filter with our own callback functions, rather than having to do some recursive wrapping function trick!


AFAIK you actually always could, but it was really complicated. Required EgoMoose to be on the case there, hehe


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 :).


can finally get rid of this silly line :cowboy_hat_face:

1 Like

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?

1 Like