Hi again Buoyancist,
I just finished the GL section of ofBook; it took me a while to get thru that. So, those examples use OF_PRIMITIVE_TRIANGLES, but you could see if the following applies to using OF_PRIMITIVE_LINES. Basically, the vertices of the mesh are set (along with colors and textures if appropriate), and then the mesh is indexed according to the order of drawing. So, in the case of triangles, three sequential indexes create 1 triangle, and the subsequent three create the next, etc. Indexes are repeated if necessary, and are ordered in a regular and consistent way. So, drawing a square (2 triangles) uses 4 vertices (1, 2, 3, 4) and 6 indexes((1, 2, 3), (2, 4, 3)). The order of indicies is important.
So with that in mind, if you’re creating indices without color, and they are in indexed and drawn in the order that they’re created, could the triangle-nature of the GPU explain why there are 1/2 as many lines as when that color is specified? I guess the GPU interpolates between colors when they are different, and since it seems to see the world as triangles, maybe its interpolating the color of the line differently depending on the location of the vertex in a world of triangles (instead of lines). In other words, for 4 vertices, the first triangle will form from indexes 1-3, with vertexes 1, 3 having a defined color and 2 having an undefined color. The second triangle will form from indexes 2-4, with vertexes 2, 4 having an undefined color and 3 having a defined color. So maybe it interprets the line from the first triangle as having an interpolated color, and the line from the second triangle as having undefined color. I could be completely wrong; this is pure speculation and a semi-educated guess. It would be fun to try omitting the color twice in every 4th run of the loop and see if fewer lines disappear. Or, you could try alternating the omitted color and see what happens with omitted lines.
Also, I’m still hazy on type conversions, but I wonder if the i < (0.75wallMax) is a float? If it is, then the true value could be something like 750.000001 or whatever, which would make 1 extra pair of vertices (but only sometimes (?)). So anyhow, you could try creating an int max = 0.75wallMax, and then using it in the loop as i < max. Or alternatively try i < ((int)(0.75*wallMax)). I’ve had plenty of trouble lately with integers, integer division, and type conversions. Hysterical but frustrating.
Again you’ve probably figured these things out by now. Glad the ofBeginShape() and ofEndShape() from earlier worked. I’m not sure what the best way to make vertices is; to some degree I think it may matter what you end up doing with them. If they’re for an ofPolyline, then they may be best made “that way”, as opposed to an ofMesh (cpu side) or ofVboMesh (gpu side) which may be best made in a slightly different way. The different oF classes may have slightly different representations of “vertices”. I’m pretty sure that ofPoint is a psudeoname for ofVec3f. The ofMesh object resides on the cpu side of things, while the ofVboMesh is more of a gpu object (in gpu memory). The ofBook tutorial (if I remember right) explains that the ofVboMesh object also has some bool variables that track if its been updated or not. If not, it just redraws the same mesh from the gpu memory. If it has been updated, it gets an updated copy from the cpu (slow transfer time, relatively). But I think the ofMesh just sends a new copy to the gpu every time the mesh is drawn.
OK well anyway hope this helps. its been fun to write about it on a Sunday night. Take care.