Giving contact points and normals in addition would dramatically expand the usefulness of this API, not to mention bringing it up to par with actual game engines.
8 Likes
Agreed. The raycast API gives us contact points, normals, materials, etc. This API seems to imitate raycasting in how it is called, but what is returned is far less useful. I hope a future update brings us the ability to access contact points and normals.
Why? Imagine the use case of using GetPartsInRadius to check what is damaged in an explosion, but you want things farther away from the explosion to take less damage. Without any contact point info, this is pretty much impossible with this API and would require writing some custom collision code.
7 Likes
To be honest it would be awesome to have it directly implemented in this API, but i’m pretty sure that you can use magnitude for that already.
That is, assuming a part’s Position is close to its bounding box. Sometimes you deal with large or long parts that have a center very far away from where the explosion overlaps.
If I wanted to make a different song system with ReplicatedStorage for each map in a Minigame-type game, would I want to consider using this?
I’m a beginner scripter still, but I think I’d use this.
EDIT: Ok I looked into those times and they are inaccurate. I think there were two problems with your benchmark script: your Region3 definition uses the wrong positions, and FindPartsInRegion3 has MaxParts set to 20 by default. These are the accurate times:
FindPartsInRegion3:
GetPartsInBox:
You can see GetPartsInBox is a bit slower, but not by much. However I’m pretty sure we can make it just as fast if not faster when you are passing in a Box that is axis aligned (like Region3).
Performance will also vary depending on their sizes, relative positions, and assemblies. If you query a zone with 1000 parts, but that’s comprised of only 5-6 assemblies, you should get much better time than if it’s 1000 assemblies. Performance should scale more with the number of assemblies than number of parts.
There is more we can do the maximize efficiency of the new overlap queries. We recently did this with raycasts, but some of this hasn’t been applied to overlaps. You can expect them to be improved over time.
31 Likes
Oh, you mean with parts such as rectangles, which don’t have the same size on all axes?
1 Like
So these are region3s that we can rotate now?!?!?
Well that’s… that’s soul crushing. I would’ve hoped the introduction of this new API would allow us to do that to begin with because that’s a use case that I know we and a lot of other developers have, trying to do spatial queries multiple times every frame.
Are some of the improvements you mentioned going to allow this to be used multiple times per frame or no? If so, then I can’t see this much more as just a consolidated Region3 API and I’ll be back to avoiding it like the plague. I’ll also have to twiddle my thumbs with my current Touched/GetTouchingParts “hack” and wait until we get shapecasting which hopefully won’t suffer the same performance problems.
10 Likes
The recent updates have been great, first improvements on Raycasting in both performance and range, And now this!
I am very happy with this, now I wont have to add a TouchInterest to a part every time I want to make a script using GetTouchingParts, this is great!
FWIW I’m getting results showing both GetPartsInPart vs GetTouchingParts and FindPartsInRegion vs GetPartBoundsInBox being within 5% of each other performance wise (just one example with ~100 parts):
13 Likes
Awesome, it will be helpful for developers I love it!
Pretty cool, hope this will also increase the performance on the server with my combat system that was using Region3
Finally! I’ve been waiting Roblox to release this feature. I’ll be using this in my games! 
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’.
2 Likes
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.new() RaycastParams.Filter = function(Part) return Part.CanCollide and Part.Transparency < 1 end local LaserHit = workspace:Raycast(game.Players.GFink.Character.Head, Vector3.new(0, 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!
8 Likes
AFAIK you actually always could, but it was really complicated. Required EgoMoose to be on the case there, hehe
1 Like
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?
9 Likes