I’m trying to do something like this where if I click then I get all the vertices in a small area of where I clicked.
If it’s just as many verts as are in this picture, just brute-force it. You might benefit from copying the verts out of the Mesh once at start, unless of course they are dynamic.
If it is for more, then you may need to divide them into spatial lists (small spatial buckets) so you can consider a smaller subset of them for what might be within your area of interest.
If you want to see more vert-mashing stuff, my procedural generation package MakeGeo has a bunch of examples of making geometry in code:
MakeGeo is presently hosted at these locations:
So when you say spatial lists or spatial buckets, you are referring to spatial hashing? Sorry these terms are brand new to me. 
People have also mentioned using an octree or finding the verts through shaders. What is your opinion on these approaches?
As an engineer, my position is to use the simplest most straightforward approach that performantly solves the problem.
That might even be just brute-force search over the entire data set , if the data set is suitably small.
This is what I’ve gotten so far: https://i.imgur.com/RbZiq7I.gif
I use gizmos to represent which vertex is closest to the position of my RaycastHit and I use the RaycastHit.trangleIndex to find the point that I hit.
However, as you can see from the GIF, there are problems when my range of vertices tries to pass over the seams of my mesh. The vertex order is messed up as shown by the numbers after I cross the seam. What would be a good approach to fix this?
I’ve implemented this “gizmo area” by drawing the vertices near the target vertex using the vertex indices like so (snippet: https://i.imgur.com/A1elBjd.png, full code: https://pastebin.com/GQBm9Jsg)
Steps:
-
define how they are messed up
-
define how you want them to be
-
sort them accordingly.
Thanks for the clarity.