#1810 front vs. back border during x direction rotation greater than 180 degrees
I believe there is a bug, or for sure inconsistency, in the behavior of borders during rotation, specifically about the x view direction. The documentation indicates:
Bit plot splot
1 bottom bottom left front
2 left bottom left back
4 top bottom right front
8 right bottom right back
16 no effect left vertical
32 no effect back vertical
64 no effect right vertical
128 no effect front vertical
256 no effect top left back
512 no effect top right back
1024 no effect top left front
2048 no effect top right front
Here's an example:
set hidden3d
set border 20
splot x*y
Now, change the rotation about the z axis by clicking the mouse and moving left/right. Notice how both the z-vertical having the tics and annotation always stays to the left no matter the z rotation. Similarly, notice that the base border that is drawn changes coordinate axis so that it always remains what is visually the right-most, front-most border with respect to the viewer. Note further that the tic annotation always remains in front, or more specifically outside the drawing space.
Where it gets inconsistent is changing the rotation about the x direction. Leaving the z-rotation fixed, change the x-rotation by clicking near the bottom of the screen and moving the mouse directly upward. Only go upward to not lose track of the view (unclick and reclick bottom if need to). Here is what I see [skim through this description if you prefer and just try rotating a full 360 degrees vertically in the view]:
0 < x_surface_rot < 90 : Tic annotation underneath (outside of plot space) and right-front border is drawn.
Fine.
90 < x_surface_rot < 180 : Tic annotation still underneath and right-front border is drawn but that border no longer coincides with the tic annotation.
That's acceptable and doesn't disagree with documentation.
180 < x_surface_rot < 270: Tic annotation moves into the plot space rather than switch to another set of axes and remain outside the coordinate space. The highlighted base border remains on the same coordinate axis.
This is the inconsistency. Technically, that border still displayed in this quadrant is no longer the right-most, front-most border of the base. It should be the one plotted inside the coordinate/function space. Furthermore, I think the tic annotation should shift up above the coordinate space.
270 < x_surface_rot < 360: Tic annotation is now outside the coordinate space above the plot. The border that is drawn is still technically not the proper right-front-most border.
At this point the annotation is good, but not the drawn border.
Well, as I see it, the border drawn with x-rotation is not consistent with the documentation or z-rotation behavior. And the tic annotation isn't consistent with itself--and possibly it isn't the desired behavior. Maybe folks want the tics and annotation to follow along with the drawn border, i.e., always remain the front-most. But always remaining outside the function space so that annotation never overlaps the surfaces is fine by me as well.
Attached is a patch that I think is correct and agrees with the original intension given the code indicates "labels on the back axes" in the logic. Basically, all the change does is add a little more sophistication to the surface_rot_x logic in the way surface_rot_z logic is handled, i.e., quadrants. Let me know if you agree.
This mod would have ramifications on feature request ticket
One other thing I wanted to point out is that I stepped through 1, 2, 4, 8, 16, 32, etc. testing each border and noticed the peculiarity that for bottom it is left front--left back--right front--right back, but for top it is left back--right back--left front--right front. Perhaps there is some underlying logic in the code, but if it were arbitrary I would have thought the same pattern would be a memory aid. Probably too late to change now.
I may not be reproducing your test as intended, but I don't see anything odd when I try it.
So for me, no bug is evident.
I've attached plots to illustrate what the issue is. One has to watch very closely as rotating. Imagine the orientation of the plane of the base as it rotates with respect to the viewer and keep focus on which corner is closest to the viewer and when.
The edges themselves all look correct to me in those plots, although there is a strong optical illusion effect in the 3rd plot. Yes it's true that the "right front" edge is no longer "right front" if you flip the plot upside down, but so what? In practice I doubt that anyone would turn off the opposite edge in such a plot. So they will either both be on or both be off.
I do agree that the tic labels are sometimes drawn so that they obscure the surface even though if they were placed on the opposite axis they would be out of the way. Could that be a simple sign flip that is triggered when the plot is turned upside down?
The right-front rule is noticeable when adding the feature of color to the main axis and tics:
https://sourceforge.net/p/gnuplot/feature-requests/446/
Yes, it's just a "-1" change, typical of 180 degree rotations. The quadrant logic of setup_3d_box_corners() is about interchanging that front and back corner when appropriate. See the code in the patch attached earlier.
Similarly, in that code there is a modification that moves the tic-mark annotation via
+ if ((quadrant + 1) & 2) {rather than simply
- if (surface_rot_x > 90) {I agree the text seems like it should be outside the plot range, and that was the intention I assume from the comment in the original code:
There was a reason the labels were moved to the back axes, i.e., to move them in the margins.