Hey, I’m about to make a system that will display a little pop up above close “intractable” bricks whenever a player gets close to one. I’m just not sure what would be the best approach in keeping track of what intractable parts are near the player.
I should also mention that there would be two ranges: one where a little star appears indicating that the object can be interacted with, and a second, closer range where the player is prompted to press a button
I have a few options in mind:
On enter, create a list of all of the parts and check the distance between the player and each part each second. If one of the parts is close enough, start checking for its position more often
Use workspace. FindPartsInRegion3(), then do same check for position more often if part(s) are found
My problem with FindPartsInRegion3() is how would I not go over the maxParts that it checks for? and with which method would performance be the same
Option 1 will work fine, go with that. It will be performant enough. We do this in Egg Hunt and the interval is about 0.3 seconds for close-by parts and 1+ second for far away parts, and with 500 indicators in a test place I could not even see a performance impact.
Different variants of this question are very common. I almost feel like it would be useful if Roblox would implement a spatial data structure with common events and methods. You may be interested in this spatial search article, but unless the number of items is large @buildthomas’s suggestion is a great one.
Region3 could be considered a spatial data structure, but unfortunately if you want to do a radial cast instead of box, you have to do extra work to filter down the results. Region3 also doesn’t support tags.
Out of interest did you test this with FindPartsInRegion3 too? I use it usually assuming it’s more performant, but with a small number of items perhaps not…
If you have many thousands of items I can imagine that being more performant. I didn’t do that because I only had up to some hundreds of items across a whole big map, and with FindPartsInRegion3WithWhiteList you still need to do some processing afterwards to make sure you only get the ones close enough in a sphere around you (since Region3 is an axis-aligned box). It’s not a major difference in implementation, just one extra step beforehand where you filter the list of instances down using the Region3 check, but it was not worth implementing for me at that time.