Alternative method for Mesh.ClosestPoint() on c#??

Hi everyone,

I've been coding on c# a few components to modify meshes. I've found myself using the Mesh.ClosestPoint() method ( sometimes to get a vertex to react depending how close it is to another mesh) on quite a few of them and, although it works just fine, after a given number of vertices and iterations this just slows down the component drastically (even 10 time slower).

I was wondering if there was a faster alternative to this method that I haven't explored? I thought about maybe not using a mesh, and using just points and an RTree instead but the outcome isn't the same, as the closest point to the mesh might be on a different location than the closest vertex of that mesh.

Attached is just a quick example script that works with the logic I'm proposing. It would be awesome if someone could guide me on this :).

Thanks,

Andres

Attachments:

MeshAttraction.gh, 152 KB

Replies to This Discussion

Permalink Reply by Daniel González Abalde on September 13, 2016 at 9:12am

Why are you using a mesh (which involves a curve) instead of the curve directly?

You can try putting the vertices in a Point3dList, which has the ClosestIndex method I use very often. Although I do not know if some spatial partition algorithm is used internally (Rutten, if you read this and know the answer, please tell me), I think is a faster way.

I do not think it worthwhile to use an R-Tree here because your mesh does not have as many vertices (I say this from ignorance, cause I have never used the RTree of Rhino, maybe its easy I dont know, and implement one from scratch would go the hard way).

Also, details to improve performance (or perhaps I have not understood how you are doing), but the way to replace vertices is not to eliminate all and add a new list later, but use m.Vertices.SetVertex(Index, new point).

Permalink Reply by Andres Rivera on September 13, 2016 at 5:43pm

Hi Daniel,

Thanks for the response. The reason why I'm using curves to create meshes now is completely arbitrary, eventually I will be using other meshes, not curves, that's just a bad example I guess, sorry for that.

Hmm that's something I didn't think about, but wouldn't using ClosestIndex would involve using the vertexes of the other mesh (I might not be fully understanding the method yet)? And would then be the same case as with the R-Tree, I would need to subdivide it a lot or populate it with a lot of points in order to get a result as accurate as the Mesh.ClosestPoint (although accuracy might not be as important if it improves performance, I will give it a go).

Thanks for that last tip! I knew there ought to be a better way. I will implement it :).

Permalink Reply by Daniel González Abalde on September 13, 2016 at 6:25pm

Sorry, I'm a bit confused. You need to know the minimum distance between two meshes or you're going to iterate through all vertices of the mesh to move them according to the distance to the attractor-mesh? Or the approach is another?
If you know the closest vertex of attractor-mesh, then you can project it to get the point on the mesh (MeshPoint), that's no problem, or Im wrong?

Permalink Reply by Daniel González Abalde on September 13, 2016 at 7:51pm

Perhaps this will be useful. Just I wanted to try the following algorithm:

v0 = random vertex of Mesh 0

v1 = random vertex of Mesh 1

d = v0 distanceTo v1

For each connectedVertex to v0 in Mesh 0

If connectedVertex distanceTo v1 < d then v0 = connectedVertex

d = v0 distanceTo v1

For each connectedVertex to v1 in Mesh 1

If connectedVertex distanceTo v0 < d then v1 = connectedVertex

Do B while decreases d

Attachments:

DistanceBetweenMeshes.gh, 6 KB

Permalink Reply by Andres Rivera on September 13, 2016 at 11:49pm

In regards to the first question, I am planning to iterate through all vertices of the mesh to move them according to the distance to the attractor-mesh. I guess why I'm a bit sceptical about using the vertices of the attractor-mesh instead is that, as per the image below, the result will be the equivalent to the green line, and the distance that I really want to use, is the equivalent to the black line (which is using the mesh.ClosestPoint method).

So if I use the vertices of the attractor-mesh, I would need to subdivide it considerably in order to get the same (or similar) point which would then again increase calculation time. I guess I just want to avoid running through all the vertices on the attractor-mesh to get the closest one.

Permalink Reply by Andres Rivera on September 18, 2016 at 1:13am

Hi Tom,

Thanks for the advice! The reason I didn't try multi-threading is because it seemed counter-productive to be needing to lock and unlock variables for it to run. Atm it's not really doing it for me and the vertices are reorganized in strange ways once I use the loop. I'll try different ways of using the Parallel Loop and see if performance actually improves, because sometimes it just makes it slower (but then again, I'm no expert on this).

Permalink Reply by Andres Rivera on September 25, 2016 at 8:00am

It definitely does help now that the component is well structured, thanks for the tip :), runs way faster.

Permalink Reply by Daniel González Abalde on September 14, 2016 at 5:27am

You have to use p.DistanceTo(attractors.ClosestMeshPoint(p, double.MaxValue).Point) instead of ClosestPoint method.

Also another way to improve performance is to avoid using the timer and internally calculate all iterations you want. This prevents each step Rhino has to draw the mesh and Gh run downstream components.

Permalink Reply by Andres Rivera on September 18, 2016 at 1:10am

Thanks for the tips, I will have a look at Mesh points and it's properties cause it seems like it will be more useful for other chunks of code as well.

With avoiding the use of a timer, you mean replacing it with a loop of some kind? The thing is I never know how many iterations I would want, that's why the timer was useful for me but I'll try other ways and see what gives me a better performance.

RSS