I’ve been playing around with bpy.ops.mesh.select_next_loop() and as far as I can tell, the intent is to select the next edge of an edgeloop. As you will see, the behavior of this command is a bit off from that assumption.

I start out with a subdivided plane and try selecting various rings. (my original intent in this was to move a selected ring across the surface.) The images titled these images are illustrations of applying the command over and over to this initial setup.


There are some surprisingly complex things happening here, so I try with a single edge.

As you can see, the function of this command is perplexing given the starting assumptions.
The effect appears highly directional - with some odd behavior happening at the extreme edges of the mesh.
I’m sure you will notice other interesting anomalies by studying the gifs.

Can anyone give me some insight as to why these things might be happening, why its so biased to a single direction, or what the intent of the command is?

My guess is that it has something to do with the order in which the edges/vertices/faces are stored. That order may affect these algorithms when there’s no obvious single “next loop”.

Can you remake one of your gif’s with the index visualizer on? I’ll bet, like Bayessian said, there is some indexing going on too.

I think that it’s just exploring the next edge, rather than the parallel edge loops. It seems like a poorly designed command