I posted this problem before but I think I was misunderstood. Very simply, I need to select a vertex on a poly or a mesh nearest a given point (not another vertex)- that is, a point three array[a,b,c] that specifies a point in three space. It might even coincide with the location of a vertex, but this still doesn’t allow me to select that vertex. There’s no Getvertbypoint method that I can see in mxs. It’s probably a two line solution that doesn’t involve abstruse algorithms but I just can’t see it.
So Denis, thanks for the blindingly fast algorithm- but it’s overkill. I just need one vertex, not a whole lot, nearest a given point – not nearest another vertex. Thanks again for your time.
Use for loop to loop through all verts, measure the distance between the given point and each vert and you will get the closest vert.
Simple Example, not the most efficient, but hopefully quite clear to understand.
(
--start our test distance to be massive
local dist = 1e9
--declare a variable so we can find out which vertex is closest.
local closestVert
--declare our test Point
local testPoint = [0,0,0]
--Loop through every vertex
For i = 1 to $.vertices.count do
(
--calculate the distance between the test point and the vertex positions
local testDist = distance testPoint $.vertices[i].pos
--If the test distance is less than the current distance, change the current distance
if testDist < dist do
(
dist = testDist
closestVert = i
)
)
format "The Closest Vertex is:% at a distance of:%
" closestVert dist
)
I’m flattered the famous dave Wortley has responded, thank you , but looping through every vertex could get quite expensive .
how about using MeshProjIntersect interface’s ClosestFace function and loop over that face’s verts, checking distance for each one. On a large mesh it should be faster than checking all verts, on a small mesh might be slower because of build time for the acceleration structure
Hmm…I tried the brute force script and it was pretty damn fast actually. Unexpected
Actually you cant avoid linear time in this case isn’t it? It will always depend on N number of vertices in your target mesh.
Actually you cant avoid linear time in this case isn’t it?
yes in a one off case this is true, but if it needs repeating continually in an animation or a realtime situation then some extra initial overhead e.g. sorting the verts into a voxel grid wins.
sorting the verts into a voxel grid
Klvnk any examples, references, algorithms etc. on this approach ?