Automatic alignment of ticks in 3D scenes

[archmoj]

This PR improves automatic alignment of ticks on 3D axes. The best single orientation for each axis (depending on the camera position and orientation) is found and used by vertex shader.
In the earlier work it was possible for the ticks on an axis to align themselves in two different directions and stay upwards. But such behavior was not completely desirable in some perspective views.
@alexcjohnson

[archmoj]

gl-vis/gl-plot3d@master...align-ticks

[archmoj]

gl-vis/gl-axes3d@master...align-ticks

[alexcjohnson]

@archmoj interesting - The code looks great and it does exactly what we discussed, can't argue with any of that! But now that I see it and play with it, I'm actually not convinced that this is better than having each label independently restricted to [-90,90] degrees rotation as implemented in #3084. I kind of think the improved consistency from label to label is not worth the reduced legibility of individual labels. What do you think?

@etpinard @antoinerg thoughts?

[antoinerg]

such behavior was not completely desirable in some perspective views.
Hello @archmoj, can you point me to some examples of those perspective views where the results are undesirable.

I kind of think the improved consistency from label to label is not worth the reduced legibility of individual labels.
@alexcjohnson I do agree that the labels oriented with an angle outside [-90, 90] look weird to me and are probably a bit harder to read. On the other hand, I am not sure I fully appreciate what we're gaining in consistency. I need to see an example and test it out more.

[alexcjohnson]

@antoinerg when @archmoj first implemented the rotated labels I said I wished the labels for one axis would all get the same rotation, so you could read them as a series. That’s the consistency argument. Try it on master, as you slowly rotate a scene you’ll see the labels flip one at a time as each grid line passes through vertical. In this PR they all flip together.

[archmoj]

such behavior was not completely desirable in some perspective views.
can you point me to some examples of those perspective views where the results are undesirable.
@antoinerg These old and new files may be easy to compare using Swipe option.

[archmoj]

What do you think?

We could setup the shader to be able to serve both functionalities (as well as others e.g. option:2 for horizontal/vertical, option:8 for 8 directions ...). For example I could simply allocate option:0 (now used for debugging) for the ranges between [-90,90]. Then the question would be which option 0/1 should be the default behavior. I personally think that when either the ticks include some text or the user need to print the graph it would be nice to give them options to switch to this new behavior.

[archmoj]

@antoinerg
Here is an example of the previous behavior:
created by @alexcjohnson before.

[antoinerg]

This is maybe not the right place to bring this up but why aren't we making the label facing us and always horizontal?

For example, why aren't the Moneyness axis labels simply horizontal:

A lot of 3D scatters are done that way. For example:

This is the easiest thing to read IMHO. I most certainly don't appreciate the different edge cases and shortcoming of this approach.

[alexcjohnson]

This is maybe not the right place to bring this up but why aren't we making the label facing us and always horizontal?

Absolutely, a reasonable place to bring it up. I can certainly see cases where horizontal is better, and a lot of simple situations fall into this camp. But there are also cases - particularly when there are lots of ticks (so it can be ambiguous which label goes with which tick) or long labels (so they can overlap each other) - where to my eye it's much better to rotate the labels. So if we only have one behavior I think it should be this one (specifically restricting each label independently to [-90, 90] degrees) but I'd be happy for us to enable fixed angle (normally fixed at 0) and consistently rotated angles in a subsequent PR.

[archmoj]

It is actually pointing to this change on gl-axes3d:
gl-vis/gl-axes3d@master...align-ticks

[alexcjohnson]

OK great - I'm glad this now leaves all the mocks as they were before the PR. Since this doesn't have any immediate effect anymore, let's wait and see if @etpinard's opinion changes the result at all.

[alexcjohnson]

Oh actually, I forgot, this PR includes the Chrome 51 title rotation fix, right? In that case, lets go ahead and merge the upstream PRs and this, and we can discuss whether to change the default behavior and/or add another config parameter in a separate PR. 💃

[etpinard]

I'm glad this now leaves all the mocks as they were before the PR.

I'm very glad of that as well. 👍

@etpinard's opinion changes the result at all.

I much prefer the behavior now. 🥇

---

Pro tip for @archmoj: you should delete your PR branches after merging them (I've done so here, no worries), to reduce the chance of collisions between local and origin branch names.