ofMesh indices are out of order

I am trying to go through the indices of an ofMesh. It is fairly simple, basically a series of corners and edges. The indices refer the the vertices, as normal.

However, the zero is…not zero. The numbering for the indices starts at 1, and then progresses through to the last, and along the way there is zero. If I draw lines between the various connected points, along the way they will become screwed up, passing through the object instead of only along the edges.

This makes it difficult to arrange a reorganized array of indices for the analysis of points, as well as calculating normals for comparisons.

Is there a way to fix the sorting of indices easily?

if you are using autoindexing then these will be “out of order” since the default mode is triangle strip.
you need to set the mesh mode.

ofMesh mesh;

//or this other one

now when you draw you dont need to worry about indices. a line wil be drawn between consecutive vertices.

you might find useful some of the chapters here http://openframeworks.cc/learning/#ofBook


The mesh for the wireframes is created using OF_PRIMITIVE_LINES (includes only the outline of a voronoi cell), at line 119 here: https://github.com/patriciogonzalezvivo/ofxVoro/blob/master/src/ofxVoro.cpp ) .

Even by changing this while creating the mesh, without an implied order during creation, won’t they still be unsorted?

Then that is something that @patricio might have done.
If you don’t specify any indexing for a mesh it will simply use the order at which you added it’s vertices.
so, if you use OF_PRIMITIVE_LINES for each pair of vertices it will draw a line connecting them, so if you have vertices v0,v1,v2 and v3 it will draw a line from v0 to v1 and from v2 to v3 BUT not between v1 and v2. So if you want to have some continuous lines you need to duplicate vertices of use indexing accordingly. (Actually indexing is to avoid duplicate vertices).

You should read the following

BTW, I’m i bit lost with what is troubling you, so if you could post some example code or screenshots of what you are getting and what you would like to get it would be great.


sorry it’s taken a while to reply… I’ve been trying to figure out what I am describing.

This question was in relation to a different question ( link: getting sides of simple mesh ) I am going through the indices of a mesh and, for each point, creating a vector<vector< ofPoint > > of the joined points.

The ultimate goal was to rebuild each face of the mesh. As noted, however, there is no zero index in the vector, [0] exists, but is empty. point [0] is referenced properly by other points, however.

Even without the zero index, using the ‘connections’ for each point, I then calculate the three normals for each of these three pairs, in the hopes of finding all of the pairs with the same normal and joining them together to make a polyline for the side.

Unfortunately, with the zero index for the initial vertices missing I get a jumbled mess of lines connecting the wrong corners instead of the desired polyline for a face.

The ‘final’ goal was also to find which corners faced different objects but I could never figure out how to utilize the normals properly. Getting the face would have been handy (like adding a material shine to the top face, for instance).

This is an (admittedly crappy) image of the objects in question: http://gersart.tumblr.com/post/154124239204/i-need-to-figure-out-how-to-make-the-flattest

This is an image of objects with lines extending from centre of mass through corners created with a node child at each corner with the rock centre of mass as a parent node.
Tomorrows task is to rotate the rocks so most of their mass (points) is at the bottom, and their largest flat side is at the top. This may not be the same ghing, i suspect. #openframeworks...

While I don’t ‘need’ the question anymore (I am constructing the lines between objects differently, but the results are not as elegant), I would like to know how to solve the puzzle of rebuilding the sides of these simple meshes.

well, I feel like an idiot.

indices are stored in pair. Increment accordingly.

for (int i=0; i<indices.size(); i=i+2) NOT for (int i=0; i<indices.size(); i++)

no wonder I was getting odd results.