Access to connected Vertices (Solved)

[Daniel Brassard]

As you said, you will still have to translate the array per point to find the index using the get VertexIndex node. (I think that behind the scene the Point neighbors is actually doing the reverse i.e its finding from the structure the point Index and give you the resulting coordinates from the vertex array)

The point of this exercise is to navigate a data structure and then to use it to your advantage. Grahamf suggestion would lead to the point neighbors as well via the vertex index. What is the point of complicating myself with something that already exist?

The aim is to understand how to traverse a data structure using the nodes exposed by ICE (which I thing is some form of edge data structure) and vary the search to create other data structure (winged-edge, half-edge, quad-edge, DCEL, DLFL, etc) by creating other arrays that are not present or exposed by ICE.

This first exercise creates a simple data structure called the Vertex-Vertex structure. ICE is a perfect tool to learn visually what are data structures.

Now you can see my madness.....MADNESS, THIS IS SPARTA!

[grahamef]

Just a point of precision...

PointNeighbors gives an array of locations, which can be shown as XYZ positions if you display them numerically. However, they are indeed locations, not positions, and you can use them to look up data like VertexIndex.

[Daniel Brassard]

So if I get it correctly, it is showing the location in the vertex array (X1,Y1,Z1,X7,Y7,Z7 ...), not the position is 3D space. Correct?

[grahamef]

So if I get it correctly, it is showing the location in the vertex array (X1,Y1,Z1,X7,Y7,Z7 ...), not the position is 3D space. Correct?

No. What I mean is that when you display locations as numeric, it's not showing you the raw location data (which are actually triangle IDs + barycentric coordinates). Instead it's converting the location to a position, as if you had plugged the location into Get Data, selected PointPosition, and displayed that numerically.

But don't be fooled, it's really a location not a position (i.e. not the vector that the display might have you believe that it is).

[rray]

Locations are the "official" means through which data is read from surfaces. The "Locations" concept is great. They're really fast too - that's why there is no "PointNeighborIDs" attribute, you can just read the PointIndex through the Neighbor points locations (as you can the position, UVs etc etc as Grahame wrote)

[Daniel Brassard]

Thanks Grahamef

It works. Here is the solution to help others.

Cheers!

[Daniel Brassard]

And the easy solution as mentionned by RRay/Grahamef using the PointNeighbors location.

[Bullit]

So simple...