I’m proposing a new set of methods for Workspace and a few for BasePart, to allow us to access internal spatial information from Lua. I’ve seen many a naive programmer do something like
[code]local function checkPartColission(partA,partB)
–a bit of math here
local newPart = Instance.new(“Part”, workspace)
local function recurse(t)
for i,v in pairs(t) do
if v:IsA(“BasePart”) and checkPartColission(newPart, v) then
Possible stack overflow aside, this is incredibly bad code. However, many newer programmers (or lazy ones) don’t have the understanding to create a spatial data type and get it to work with ROBLOX. ROBLOX has to have an internal representation, so it would certainly be useful to expose it, or some sort of spatial data type. What I’m proposing is
Octtree Workspace::GetOcttree() – or some sort of other spatial data type; whatever ROBLOX uses internally
Which will allow us to efficiently determine whether or not certain parts have a chance of colliding, thus reducing the number of collision checks, drastically increasing performance.
In addition, for added convenience and ease for newer programmers, the following methods should be added:
BasePart Workspace::GetPartsNearPosition(Vector3 position, double radius)
BasePart BasePart::GetNearbyParts(double radius)
These methods will simplify the parsing of the spatial data type so that newer programmers don’t have to wrap their head around the concept of an octtree or similar, a complex concept for a beginner.
The API for the new Octtree and OcttreeBucket classes themselves would be decided upon based on the internal representation of them, or just a plain old Lua table. Either way, that is a discussion for a future time; right now, we need to either accept this API or propose changes. The way it stands, it is unacceptable to have to write your own spatial data type whilst ROBLOX has one internally.