Gridpoints question


(Remy Konings) #1

Hi all,

I have two grids, based on a rectangle grid. One a rectengle and one is made out of a picture.

I have the locations in rhino of each point from both grids.
What i want is to ceck the list above for the values underneat panel. I want to end up with a list of points so i could get all the points from the rectengle grid except the points that correspont with the other panel.


(John Brock) #2

Assigned to Grasshopper category.


(David Rutten) #3

Can you post a *.gh file with both those point sets? It’s probably easiest if you just internalise all the data, instead of including all the components that were used to generate the respective points.

You can probably use the [Set Difference] component to remove all the points in the grid that also exist in the other grid, but you may have to round the point coordinates to some decimal places first because the Set components won’t treat two points as identical unless they are really identical. I.e. (325.0, -521.0, 0) is not the same as (325.0000000000000002, -520.999999999999998, 0).


#4

@DavidRutten This seems like a weakness, maybe even an oversight in these components. Certainly they should provide for a tolerance parameter and use it when doing comparisons?


(David Rutten) #5

That would require switching to an entirely different kind of comparison algorithm. At the moment all the data inside ‘sets’ is hashed, and these hashes are then compared to each other. This is super fast. Testing points with tolerances will require some sort of k-dTree to speed up searches.

The Set components are mostly meant for simple data types like integers and text, types that do not suffer from rounding errors. However strictly speaking they would work for anything hashable to floating point numbers, colours, vector, points and so on are also allowed.

I agree with you that tolerances would be useful, but it’s far too much work to add to GH1 at this point.


#6

Well, I take your point and recognize the cleverness of the hashing approach but since all geometry in Rhino is floating point, don’t you think it would be a good idea to provide for doing the rounding you suggested on the way into the hashed set so that equality comparisons can be made easily?


(John Brock) #7

To paraphrase David, I think he agrees with you on the usefulness, so he might very well work on this for GH2, but not for GH1.


(David Rutten) #8

Hmm, not sure. I guess a single rounding integer which controls the number of decimal places for all floating point data might would be easy to add and reduce the use of 1~2 components, but I’m worried users will mistake this for genuine tolerance based comparisons.

The problem with rounding is that values that are very close together to begin with can end up being very far apart, if they just happen to lie on opposite sides of the rounding threshold. Your screenshot shows that you don’t have that problem in this case, but more random data can easily result in ‘mysterious’ bugs like this.

Like John said, I’m sympathetic to the idea, but implementation will have to wait for Grasshopper 2.0 because I want to get this right, and that’ll be a lot of work.


(Remy Konings) #9

Hi @DavidRutten, here the files you requested.

I’m not formiliar with internalising all data :slight_smile: I’ll take a look at it.

Mcneel.3dm (35.1 KB)

Mcneel.gh (130.0 KB)


(Remy Konings) #10

The Set Difference component indeed worked very well. There are a lot of calculations to be made. If you have any idea of making it quicker or less intense, i would like to get your feedback on that.

Thank you for the help already.