This is something that I see come up a lot. Problem: You need to determine if a point in question lies within a specified rectangular prism (cuboid). The plugin which shares the the name with the construct does this by brute force. Unsatisfactory. I don't know the best method, since the cuboids can overlap, but here is the general outline of the algorithm I'm working on: Take your collection of cuboids. For each define the bounding sphere. Define two widely separated points, lets call them A and B (I'm using 0,0,0 and 100K,100K, 1K just for nice round numbers. In practice they could be chosen more cleverly, but first the problem at hand) Find the point closest to each point lying on each sphere (two points per sphere) Find the distance to those points for their respective sphere and sort the spheres into two lists based on their distance to each point. Each sphere stores two sorted lists of "peers", one per base point. This is the list of spheres which "overlap" with this one. By this I mean that the maximum distance and the minimum distance of the two sphere from the point (near and far side if you drew a line from the point through each sphere's center) overlap. That is the setup, and every new cuboid added needs to be inserted into the list at the proper point. Considering that sorting algorithms are O(nlog(n)) and determining peers is just a little slower than that with some clever optimizations that is fast enough for such rare events (compared to lookups) To determine if you are in a cuboid at a give point: Perform a binary search on each list of spheres, finding the two spheres that the point is closest to on each list. O(log2(n)) Since we used the near points when sorting the list we only care about the one that we are bigger than. Check if the point is even within the near / far range of the sphere. If not, then we are certainly not within any cuboid. Return a negative match. This gives the algorithm a best case run time of O(log(n)) even if we don't do any clever caching of results (which we can, but that is another discussion) If we DO fall within the range of a sphere on both lists then we have to compare these two points (and their lists or peers) Perform an intersection of the two lists of peers to produce a list of potentials. On two sorted lists this is linear. You now have a much smaller list of potential matches than the whole. The slowest part is the merge of the two lists, but each list comparison takes less cpu power than the six tests require to determine if you are within a cuboid (3 axisis, a <= testPoint <= b). Test each one individually and if you like do a clever cache of your results. I'd prefer to return the list of matches (if more than one) sorted by volume (specific gets first dibs) but at this point that is left to the individual need of the plugin. For the clever cache I suggest finding a cuboid that encompasses as much empty space as possible (for non matches), the matches cuboid(s), or a cuboid that encompasses all the matches. This way while a player is in a known area their results will return in O(1) runtime or slightly moer if you have to further test a short list of cuboids. Any thoughts? Is this algorithmically correct? Is there a faster method that I'm not seeing or finding? Let me know.