Access to connected Vertices (Solved)

[Daniel Brassard]

Got a little problem, maybe someone can help.

I have this cube (see image) where I can extract various vertex/edge/polygon attributes. I would like to traverse the data structure to find the connected vertices.

As an example:
Using VertexToEdges you find VertexID(2) has five edges coming out from the vertex: Edges (1,12,0,8,18)
Using EdgeToVertices you find for each Edge, the vertices of the edge in order ((2,3),(2,1),(0,2),(6,2),(2,8))
The last step is to remove the VertexiD(2) from the last array to get the connected vertices at that point.

How, using the VertexToEdges and EdgeToVertices arrays, can I select the connected vertices (3,1,0,6,8) to VertexIndex(2) using ICE?

This look simple but I can't seems to find how to do it and display them on the screen similar to the EdgeToVertices array.

Thanks for the help, much appreciated!

[Bullit]

I am not sure i have found what you wanted. I let the topology node that inspired me there.

Edit: i just realized you want the vertex that are connected to those edges. My Mistake.

[Bullit]

In this i think i got it(the red values) , but is a sort of a hack i am sure someone that knows more about arrays will get something more pretty and efficient. For example i had to choose manually either the first or the second vertex in "get vertices index from edge" node since there isn't an order from vertex 2 to the others.

[Daniel Brassard]

Thanks Bullit,

Unfortunately, the result is not what I am after. What I am looking for is displaying for each vertex, the vertices connected by those edges. The problem is the VertexToEdges is an array of Edges Index per point where The EdgeToVertices is an array of vertices index per Edge, so their is a switch context that is not allowed.

I am trying to traverse the existing data structure elegantly to assemble a simple Vertex-Vertex data structure.

http://en.wikipedia.org/wiki/Polygon_mesh

[Bullit]

The 7,6,0,3 are the vertices connected to vertex 2.


Edit: in the screen you do have the (light yellow)vertex ID, (blue)edge ID, (violet) edge ID's connected to vertex 2, it lists those not connected as -1 , (Red) the vertices connected to vertex 2 : 7,6,0,3.

[rray]

You can use PointNeighbors I believe, but extracting it from the edge information is an interesting challenge, would have no idea how to do that right now.

[grahamef]

You can exploit the fact that while a vertex can have any number of edges, every edge has exactly two vertices.

Get EdgeToVertices (arrays of size 2 per edge), select the 0th element (integer per edge), and plug into Build Array from Set (array of integers per object) to save as a custom attribute. Repeat for the 1th element.

You now have two arrays, one with the 1st vertex of each edge and one with the second vertex, both ordered by the edge ID.

So now get VertexToEdges (array of integers per vertex), and use that with Select in Array and the two arrays to get 2 arrays of vertex indices per vertex. (Select in Array lets you use an array of indices to select and returns an array of the corresponding elements).

Use Build Array to merge the two arrays. Now the only problem is that each vertex's own index is included multiple times in the result. However you can use VertexIndex and Find in Array to return an array of corresponding array indices, and then use Remove from Array to get rid of them.

You should be left with an array per vertex of the connected vertex indices.

[rray]

Ah nice, ICE stuff always seems like hoop jumping compared to normal algorithms, but really it's one of the easiest ways to design code that works in multithreading.

[Daniel Brassard]

Thanks GrahamF,

I was close, did try the build array from set with index 0 and index 1, did not follow thru with the last bit thinking I was in the wrong direction due to the size of the arrays (24 elements per array for this simple cube). I was actually writing the stucture by hand to see the steps I needed to go through, verify the resulting arrays and where i was wrong in my thinking. Glad the solution is simplier.

I'll try it when I'm back in front of XSI.

Cheers!

[rray]

what works too is (if it's not for exercise I'd use that)
pointneighbors attibute->get vertex index

[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!