Just give us the contact points and normals, come on
15 Likes
Is it just me or are we getting quite a lot of apis in Workspace as of recently?
6 Likes
Does this mean theoretically speaking if tried to use this method on a part that is in a different WorldRoot, it would error?
1 Like
This couldn’t have come at a better time. As we’re starting to develop our experience more, we have both mob and boss enemies that are capable of performing wide scale special attacks. We currently rely on some Touched hacks for hitboxes that aren’t raycasts. Additionally looking forward to using this for my own personal projects - I have a lot of use cases involving this kind of spatial work.
Could we have some performance details on how this compares to the now-deprecated (WOO YEAH) Region3 APIs? Would it be safe to perform these multiple times every frame or do they carry the same performance details as Region3? I would be really interested in seeing how the APIs compare or if this is just one of those all-in-one methods with a new and better name.
Looking forward to shapecasting next!
23 Likes
I agree. 
Definitely an easier and nicer update than before. 
1 Like
This is really nice, thank you! If we have to pick between the box and radius, which one is more performance friendly?
Additionally, will using the bounds call avoid any sort of narrow phase calls on meshes?
7 Likes
I wonder if it can be used in radar detection systems for bases to detect enemy and sound alarm, or to use as sensor to detect intruders and sound alarm, or to catch speeders or street racers, or as a car feature for adaptive cruise control to adjust vehicle speed and blind-spot monitoring and detection, also sensors to warn of objects, maybe to apply the brakes.
1 Like
This is a very exciting update and one I and I would guess many people have been waiting for. More appreciated that we got confirmation that there will be levels of detail for developer’s to choose from in the future. Hoping that full accuracy will be an option as it definitely has its use cases.
I’m also very curious what these cases are. The wording of the post makes me believe there are plans to deprecate the function in the future.
3 Likes
Not really necessary. If you need it for your case and CollisionGroups are not suitable, then add your own Attribute or CollectionService tag to those parts called CanQuery and either:
- Loop through the results and disregard any with the Attribute / tag you made
- Create the blacklist of these parts (possibly easiest if you go down the CollectionService route)
- Create a whitelist of the parts you do want to query
2 Likes
This is excellent, and I see this as having great potential for things like hitboxes and safezones.
How can one use these new APIs to replace usage of Workspace:IsRegion3Empty? Is somebody simply be able to check if the table that is returned has nothing indexed in it and deem it empty?
2 Likes
Absolutely amazing, I’ll have to use this in my safezone system
Next we could probably get support for multiple workspaces?
Could be great for keeping users in the same game but different sections of the map.
5 Likes
Yes.
local function IsBoxEmpty(cframe, size)
local params = OverlapParams.new()
local parts
params.MaxParts = 1
parts = workspace:GetPartBoundsInBox(cframe, size, params)
if #parts > 0 then
return false
else
return true
end
end
3 Likes
I think these niche cases could be developers that relied on GetTouchingParts returning a blank table when CanCollide off.
1 Like
There kinda already is in a way depending what you need them for: WorldModel | Roblox Creator Documentation
The documentation says “for a ViewportFrame” because that’s almost always what they’re used for, but they basically are a full Workspace of their own, which you can use for stuff like doing region queries / raycasts against secondary world that exists in ServerStorage or something like that.
17 Likes
Awesome change! It seems much easier than having to use Region3s.
Are these more performant than Region3 though? Just a question.
4 Likes
It’s just that some might still want to use it for convenience, it can be handy to use within Touched event callbacks for pars and you don’t know what WorldRoot they are in. There are no plans to replace/change it any time soon though.
Should be pretty much the same performance wise. GetPartsInPart can just simplify things as you do not need to worry about the collision properties of the Part.
CFrame defines the center of the box, and orientation is taken into account. (updating post to clarify this)
It sure is 
I think radius, but not by much. The bounds queries do not perform any narrow phase, even on meshes. They only account for the bounding box of the part.
I haven’t checked tbh 
. These methods are using the new optimized collision detection system exclusively. Region3 checks weren’t before, and now they do (everything is). If I get the time I could test and report a bunch of benchmarks, but also anyone could do that now 
48 Likes
Thanks a lot, this is gonna be really useful for my placement system. Is there any performance difference between :GetTouchingParts() and :GetPartsInPart()? I assume its faster.
2 Likes
Typo: FilterDescendantsInstance
Should be FilterDescendantsInstances
3 Likes
What should we use instead of that function?
1 Like
#workspace:GetPartBoundsInBox( cframe, size, op ) == 0
tip: you can also set OverlapParams.MaxParts to 1, so the function early outs as soon as a single part is found.
11 Likes