Grasshopper

algorithmic modeling for Rhino

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

Views: 1221

Attachments:

Replies to This Discussion

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). 

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 :).

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?

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

A)

    v0 = random vertex of Mesh 0

    v1 = random vertex of Mesh 1

B)

    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 

C)

    Do B while decreases d

Attachments:

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.

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).

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

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. 

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

About

Translate

Search

Photos

  • Add Photos
  • View All

Videos

  • Add Videos
  • View All

© 2024   Created by Scott Davidson.   Powered by

Badges  |  Report an Issue  |  Terms of Service