Custom mesh triangle order

Hi, I have a question concerning custom meshes. I couldn’t find an answer or some general ‘rule of thumb’.

Say I am creating a quad (ABCD), this quad can be created two ways:

A---B
| / |
C---D

Triangle 1: ABC
Triangle 2: BCD

But it could also be created using the triangles ABD, ADC. This can result in varying ways of displaying the quad.

A---B
| \ |
C---D

When I look at the mesh of the terrain generator in jmonkey, I see that for the terrain quads, the two possible ways are used:

http://wiki.jmonkeyengine.org/lib/exe/fetch.php/jme3:advanced:terrain-lod-high-medium-low.png

Is there a reason/rule/… how a quad is subdivided in triangles, or is it just ‘random’.

Currently I’m thinking of having it implemented (for terrain generation) as: pick the first vertice and create a triangle based on the 2 vertices that are the closest.

It’s not random. It’s code. Which way you draw the line makes little difference.

The terrain has high level of detail and low level of detail, etc… so it generates more than one mesh depending on distance.

I object! :chimpanzee_smile:

People who have ever modeled a low poly game character or sharp features with large triangles will agree that it does make a significant difference.

Also for terrain: You can have very sharp ridges in one diagonal direction but it’s impossible in the other diagonal direction.

Triangle strips (often used them for terrains and planets) must have the same winding for all quads that are part of that strip (if you don’t want any “degenerated triangles” in that triangle strip).

However, since we have more and more polygons (at least on stationary PC and some notebooks), plus the tesselation technique in graphics cards and OpenGL / DirectX - this becomes less and less important.

The only thing that is really important is that it should be counter-clockwise.
At least in the past that was a good hint, because backface culling made things faster.
If you disable backface culling then it should not matter.

I am indeed going for a low poly look, that’s why I am asking, since I do notice a difference. I’ll post some screenshots in a few hours.

You could write your own terrain based on the existing one.
You could use this:
||/||/|
|/||/||

Instead of this:
|||||
|||||

I don’t know if the jME terrain uses triangle strips - you would have to switch to triangle soup or triangle fans if it does.

The advantage of that new layout would include: sharp ridges possible in all directions (North, North-East, East, South-East, South, South-West, West, North-West).

Maybe you even switch to triangle soup combined with any layout for any of the terrain quads.

Or you switch from regular grid to larger triangles that are not regular (e.g. after some shifting of all vertices and then running a non-regular LoD algorithm on that triangle soup).

For terrain it makes little difference which way you pick. a) You should be consistent as it will look strange otherwise. b) no matter which consistent way you pick, some place will have sharp edges that wouldn’t have had them the other way… but if you flip it, then somewhere else will.

JME definitely uses triangle strips. And in that case, I think you go through some pain to alternate… and the winding reverses with each triangle.

And usually is the same for each quad, like I said. I’ve coded in OpenGL, using triangle strips.

No sharp ridges possible for one of the two diagonal directions with jME terrains.
If you construct your heightmap in such a way that sharp ridges are included, it makes a difference.

Should not be too difficult since regular grid terrains is not the hardest task of all times.

jME terrain does look strange already for the places where different LoDs are connected. The OP noticed that and wondered why.
When using the “star pattern” that I proposed, such differences would not appear. At the cost of not doing triangle strips anymore - which I can hardly estimate (are triangle strips more efficient even on today’s latest graphics hardware? how much more efficient? Should save some index buffer transfer…).

I wonder what remy_vd wants to achieve … maybe we will see some example pictures later… :chimpanzee_smile:

JME stitches the LODs together so the adjoining borders will be different than the rest of the mesh.

Note: using another technique this would not be necessary. For example, dropping texture stretched skirts at the edges looks 100% right and is way simpler. But that’s not the technique used for JME terrain.