Previous | Next --- Slide 24 of 36
Back to Lecture Thumbnails

"Keep following next->twin and you'll get vertices"

Shouldn't this be twin->next (like the previous slide says)? I'm assuming we're trying to get all the adjacent vertices of a given vertex.

Edit: nevermind, I see that the previous slide wasn't giving the full picture. The vertices we want are:





So each time, we add a next->twin.


Is there a way to represent non manifolds with halfedges or halfedge-like data structure? Or do we have to store a non manifold shape with a different data structure? If so, how do graphics programmers differentiate the different data structures?


Is there any requirement on the ordering of the "next" pointers? Based on this list, it seems like they could jump around the mesh arbitrarily as long as the pointers form a closed loop. Is it also required that the next half edge starts where the current half edge ends?


I thought twin->twin is just itself? how do we get all the edges by following that.


So HalfEdge describes manifolds if and only if with very strict programming constraint? Will incur many strange bugs if pointers not handled properly.


For the first red non-manifold shape, can we add some small deltas to the center edge to make it manifold? (essentially creating 5 separate edges.) If the delta is small enough, the visuals are probably going to look the same.

For the second red non-manifold shape, can we split it up into two manifold?

I guess in general is make non-manifold into manifold a viable approach? It seems viable in at least some shapes, but it might be hard to do it in general, understanding how to split for example.


By how much is halfedge being more efficient?


what are some data structures used to represent non-manifold shapes, is tianez's solution one that's used in practice?


On such diagram from second to left, what would calling an half edge from a vertex pointer would return? (if vertex is connected to multiple half edges)


Would we need to encode any other data in the struct?