Reverse octree's depth first iterator order

[frozar]

Warning: this PR is based onto #2204

Fix the order in which the octree is walked through by a 'depth_first'-like iterator.

[taketwo]

Could you briefly describe (here) how the order is changed? Are we fixing some implementation flaw or rather changing behavior to something that makes more sense? Could this break someones code?

[SergioRAgostinho]

It seems like instead of starting from index 0 is starts from index 8. It's just starting the traversal from the end, horizontally speaking.

@frozar what's the use for this? Was something broken?

Edit: I think the tests hint the problem. The octree key values which are closely tied to the depth we're looking weird before and now seem to make more sense.

[frozar]

Clarification

Hi there, I think this PR change the behavior of the iterator in a way it makes more sense. I will try to explain it on the simple octree example I provided in a previous PR:

Graphically, this octree appears as follows:
         root
       ' /  \ `
    '   /    \   `
 '     /      \     `
000  010      100  110
      |             |
      |             |
     020           220

If we consist the previous LeafNodeDepthFirstIterator, the leaves were visited in this order: "220", "100", "020" and "000".
With the change, the leaves are now visited visited in this order: "000", "020", "100" and "220".

The second order is the good one for me.

Side effect of this change

Usually people don't care about the order in which the iterator provide octree nodes I think. If someone use an algorithm which is sensible to the order of the octree nodes he deals with, maybe this change will fix some Issue ^^. If really it's a big issue for somebody, maybe both iterator should be provide: in one order and its reverse.
In my opinion, it's not necessary.

About implementation

Last point about the implementation, as the Depth First Iterators use a stack internally, surpringly to get the octree nodes in the correct order, we have to push them in the reverse order, and it's fine.

Also, why do I use a do while and not a for (child_idx = 8; 0 <= child_idx; --child_idx)? Because child_idx is a unsigned char. In this case, the for loop way would never end, because an unsigned char is always positive.
Also I would like to keep child_idx as a unsigned char because if I change it, I get a warning on line where a method expect a unsigned char as argument, if you see what I mean.

[frozar]

I hope everything is finally alright for this tiny PR.