This question is more of a curiosity than something that I “need to know to get things done”.
I’m new to 3D programming (but not new to programming in general). I’m trying to develop one component of a game what will be a hex-based grid system for the game. I’ve written the code to generate the hex meshes (as 4 triangles, to optimize as much as possible). I can display the hexes in a proper grid pattern for the landscape or board, or whatever you wish to call it). For a simple example where I actually use 6 triangles for a hex (which is less than optimum) I got to wondering: are 6 lines faster or just as fast as 6 triangles?
I don’t remember seeing anything in the documents about this, but a quick Google search brought me to http://msdn.microsoft.com/en-us/magazine/cc163449.aspx , where they mention:
“In 3D graphics programming, there are no lines, no Bezier spline curves, no rectangles or ellipses. Every 3D object is a collection of triangles in three-dimensional coordinate space. Triangles are intrinsic to 3D programming because each individual triangle always defines a flat surface, yet collections of triangles can mimic a solid object and even approximate a curved surface. As you get deeper into 3D programming, you’ll start seeing everything in your life in terms of triangles.”
Now, if Microsoft uses this (in DirectX, etc) then maybe it’s really just how every 3D package/framework works (at its base) and that lines are really just a triangle (points A, B, and C, where A = B and A != C). If so, then this would mean that drawing 6 lines would be equivalent to 6 triangles (for an outline shape only [think: triangle.setMode(Mesh.Mode.Lines)]). Is this true? Or are lines optimized somehow?
Sorry if this is the wrong place to ask about this (maybe this is just a general framework question instead of a jMonkey question), but this seemed as good a place as any to ask.
I just hope I’m making sense. 
Thanks,
Jason
Good question, asked well
I’m not enough of an expert to actually answer the question but I had a quick question about your hex grid - are you creating each hex as a separate object or are you merging them all together into one?
I’m creating them all as separate objects. Using heightmaps for terrain, I can use the hexes more for a grid system (ie map grid, object placement). I figure that even a 200x200 grid would be 160,000 triangles, which seems high but my limited understanding tells me it’s might be manageable, especially since most will not be viewable at the same time.
I may re-visit this, though, and find a way to map the landscape to individual co-ordinates on the terrain, where I can then highlight the hex/etc if need be. Might depend on if lines are considered primitives like triangles are; if so, then 6 lines per hex might be faster than 4 triangles per hex (if that even suits my purposes). We’ll see.
160,000 triangles is a fair amount but doesn’t sound too bad (depending on how much else is going on) - however 200*200 = 40000 objects is. The graphics card is capable of crunching insane numbers of vertices but the engine has to do a lot of work to get all those objects to it in order for it to start crunching.
That’s why there are optimisation things (a geometry merger and a batch node thing) to combine objects for you.
Take a look at the discussions on voxel worlds as it goes into that sort of thing in more detail.
MeshMode.Lines is used to draw lines. Triangles are used to draw areas (surfaces). If you’re gonna make a wireframe mesh you can use lines. If you need to fill the areas between the lines, you have to use triangles.
@androlo said:
MeshMode.Lines is used to draw lines. Triangles are used to draw areas (surfaces). If you're gonna make a wireframe mesh you can use lines. If you need to fill the areas between the lines, you have to use triangles.
Yep what he said. For normal textured or colored stuff it always has to be triangles. Even if some cards might support fancier fill shapes you will always want to use triangles to make sure your meshes are properly renderable.
@androlo said:
MeshMode.Lines is used to draw lines. Triangles are used to draw areas (surfaces). If you're gonna make a wireframe mesh you can use lines. If you need to fill the areas between the lines, you have to use triangles.
@normen said:
Yep what he said. For normal textured or colored stuff it always has to be triangles. Even if some cards might support fancier fill shapes you will always want to use triangles to make sure your meshes are properly renderable.
Guys, I think he knows this. He's asking if drawing lines is faster or slower than drawing triangles.
I know this used to matter back in the fixed-function pipeline days but I don't think it does anymore.
At any rate, you will have to draw way fewer lines than you would triangles. Even though you (the OP) are thinking 6 lines or 6 triangles... for a grid of hexagons you should not be drawing all six sides of every hex. If two hexes share the same side then only draw one line. And as zarch hints, you want to batch all of the hexes into one (or a few) giant meshes... not a million single-hex meshes.
...and at that point, I don't think it matters much which method you use.
Thanks to all for your responses!
@zarch: i dont think i thought far enough to realize that 20000 objects would be a bit much. Guess ill have to consider optimizing them into one giant mesh, which is perfectly reasonable considering what theyll be used for. I will do some searching on voxels, tho. Thanks for the tip.
@pspeed: you are correct about using fewer lines, but i was thinking in simpiler terms and worst case scenario for those numbers. Thanks for your info!
From what can gather, lines are just another primitive in the pipeline, so for display purposes those might be better. A demo i already did (in Processing) actually created the grid using only shared lines. I never bothered to get a count of them, but i could do the ssme thing here, too.
I appreciate the feedback everyone! Helps me get my mind in the right place for all of this.
Just a hint: if creating a hex grid, don’t think of hexagons, think of thee lines 60 degrees apart:
The entire grid can be made from just this one set of lines repeated over and over on a staggered grid… and you won’t have to worry about which edges are shared because none are duplicated.
This is pretty significant when you think about it because it kind of shows that as the grid gets larger, you get closer to averaging only one line per hex… that’s a pretty significant savings over six lines per hex.
From what can gather, lines are just another primitive in the pipeline, so for display purposes those might be better.
Exactly. If you're gonna use lines then yeah, do a line mesh from the start (using line indexing etc.).
I may re-visit this, though, and find a way to map the landscape to individual co-ordinates on the terrain, where I can then highlight the hex/etc if need be.
If you batch all the objects, picking will become harder. Batching means all hexes in the batch would use the same material and mesh.
@androlo said:
If you batch all the objects, picking will become harder. Batching means all hexes in the batch would use the same material and mesh.
True. However in this specific case (a regular grid) that's actually not too bad as it would be reasonably straightforward to map x,y co-ordinates to the correct hex on the grid.
Ive already done something similar to this for the Processing demo i wrote, where all i did was display lines. In that case i treated the grid as a set or rectangular cells; the hard part was figuring out which side of the hex lines the mouse pointed to, which i managed to get. If i can get the coords the mouse is pointing to on a giant ‘landscape rectangle’ then getting the correct hex should be simple enough. Then i could create a hex object and display that, if need be, with little overhead of object creation (1 object for landscape, 1 for hex location, plus extras depending on what was happening [highlighting path finding, etc]).
@pspeed’s idea might work out well for drawing it with lines, leaving me to treat it as one object.
Yeah, re: which hex… they’re essentially just a staggered grid of center points. Find the nearest center point to the pick location and you know which hex.