Anyone know how to convert FindPartsInRegion3 to WorldRoot:GetPartBoundsInBox.
Semi-joke aside, is there a performance difference between FindPartsInRegion3 versus GetPartBoundsInBox? I run a very small region check every heartbeat for my anticheat and I’m curious if it’ll improve speeds/decrease possible script activity in Script Performance.
Edit:
I’m extremely pleased with this update. Originally I had some not-so-performant code when running a Region3 check every heartbeat and with this new library I was able to easily condense it. Because of this new library I cut down on a nice chunk of script activity.
You really just don’t want to be nice for once, but that type if thing is called a BENCHMARK, theres a very low chance you would need that many parts in one part, but it is used for BENCHMARKING performance.
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.
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.
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.
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.
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.
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):
.
