Quoted from a separate thread I’d made, in the incorrect forum.
Let’s say I have a world coordinate. It doesn’t necessarily correspond to a vert or object in the scene. How could I go about checking to see if this coordinate falls within a mesh’s space?
For example, I might do some sort of area check around the focus coordinate, perhaps at 0,0,0 and each time an object passes within the specified range of this coordinate the script outputs a positive signal.
What I’m trying to accomplish is my own A* pathing script. So far my script generates a list of all vert positions in each object with a property ‘obtype = “ground”’. Next I need to check each position in the list and see if there is an impassable object at or near that position, such that no character could pass through that position.
Yeah. I guess I was hoping there was a more elegant way to do it. I certainly could just put each scene object in a dictionary and compare it to the pathing map dictionary. As you said, Mahalin, that seems like it would destroy speed. I might mess with it anyway. At the start of the game the Mapper script gets all objects that contribute their mesh data to pathing and gets vert positions. It generates a map based on that. I can give objects a property called “active_state” and have them be “active” or “static”, and when the Mapper script initializes it figures out which verts correspond to static obstacles, and rules them out from the start.
From there, the Mapper script will have a loop which cycles through the leftover nodes and determines if obstacles cover them. I can use distance checks to turn active objects on and off, so that AI units too far away to be a concern stop running their script, and similarly ignore any verts at a distance further from the player than would otherwise matter.
A big reason I started doing this is the inability for Blender, currently, to allow for changes in NavMeshes. I tried a few methods for reinstancing the NavMesh but to my recollection I never succeeded. The idea was for a script that could account for randomization and movement of obstacles that are more complex than the current obstacle-avoidance method (going around it). It doesn’t seem to be smart enough to go around anything more complex than very simple geometry.