Some issues with 3D plots

[uleysky]

First, the command

gmt psbasemap -R0/10/0/20/0/30 -JX5c/10c -JZ15c -Bswnez1 -pz135/40/0

gives an error

psbasemap [ERROR]: Bad interval in -B option (x-component, a-info): wnez1 gave interval = 0
psbasemap [ERROR]: Bad interval in -B option (y-component, a-info): wnez1 gave interval = 0
psbasemap [ERROR]: Option -B parsing failure. Correct syntax:

  -B Specify both (1) basemap frame settings and (2) axes parameters.
     Frame settings are modified via an optional single invocation of -B[<axes>][+b][+g<fill>][+i[<val>]][+n][+o<lon>/<lat>][+s<subtitle>][+t<title>][+w[<pen>]][+x<fill>][+y<fill>][+z<fill>]
     Axes parameters are specified via one or more invocations of -B[p|s][x|y|z]<intervals>[+a<angle>|n|p][+e[l|u]][+f][+l|L<label>][+p<prefix>][+s|S<secondary_label>][+u<unit>
     <intervals> is composed of concatenated [<type>]<stride>[l|p] sub-strings. See basemap documentation for more details and examples of all settings.
psbasemap [ERROR]: Offending option -Bswnez1

If I replace "sw" with "ws" or "s" with "S" in the last -B option, the command works fine. The bug is small but curious.

Second, when shifting the xy plane by zlevel parameter of the -p option, the "+b" flag does not draw the bottom face of the cube

gmt psbasemap -R0/10/0/20/0/30 -JX5c/10c -JZ15c -Bwsenz1+b -pz135/40/10 -P >test1.ps

Also, the manual says

+b (for 3-D plots) to draw the foreground lines of the 3-D cube

but some of the drawn lines are not foreground.

Third, the command

gmt psbasemap -R0/10/0/20/0/30 -JX5c/10c -JZ15c -Bxa+lx -Bya+ly -Bza+lz -BwsENZ1+b -px135/40/0 -P >test2.ps

produces a result that I find it difficult to interpret. It looks like the z-axis is pointing wrong.

[joa-quim]

-Bswnez1

What is that 1 doing there? Without it it works fine.

gmt psbasemap -R0/10/0/20/0/30 -JX5c/10c -JZ15c -Bxa+lx -Bya+ly -Bza+lz -BwsENZ1+b -px135/40/0

Yeap, this one looks buggy. Here, removing the 1 makes no difference.

[joa-quim]

I seem to remember that -p still has some weird behaviors in some corner cases. This works

gmt psbasemap -R0/10/0/20/0/30 -JX5c/10c -JZ15c -Bxa+lx -Bya+ly -Bza+lz -BwsENZ+b -p135/40/0 -png lixo

[uleysky]

-Bswnez1

What is that 1 doing there? Without it it works fine.

The corner on the xy plane at which the z-axis is drawn. Number from 1 to 4.

[uleysky]

I seem to remember that -p still has some weird behaviors in some corner cases. This works

gmt psbasemap -R0/10/0/20/0/30 -JX5c/10c -JZ15c -Bxa+lx -Bya+ly -Bza+lz -BwsENZ+b -p135/40/0 -png lixo

Yes it works because the default is -pz. But I need -px to shift the yz-plane along the x-axis (as the xy-plane is shifted along the z-axis in the first picture).

[joa-quim]

Ah, yes. Since I never used those corner options I forgot about them (and pretending to remember all -B varieties is high presumption).

[joa-quim]

I think this one is easier to interpret and shows better the bug. Notice that I changed the y limits to show that it's not mixing y and z coordinates

gmt psbasemap -R0/10/0/25/0/30 -JX5c/10c -JZ15c -Bxa+lx -Bya+ly -Bza+lz -BwsENZ1+b -px135/40/5 -png lixo

[joa-quim]

-p is somehow mixing the dimensions sizes. See this

gmt psbasemap -R0/10/0/25/0/30 -JX5c/10c -JZ15c -Bxa+lx -Bya+ly -Bza+lz -BwsENZ1+b -py135/20/0 -png lixo1

But now we change the size of the z axis to the same as y, we get the correct plot

gmt psbasemap -R0/10/0/25/0/30 -JX5c/10c -JZ10c -Bxa+lx -Bya+ly -Bza+lz -BwsENZ1+b -py135/20/0 -png lixo2

[uleysky]

No, this is still incorrect. Pay attention to the y- and z-axes, they are parallel.

[joa-quim]

The plane is correct. The labels not

gmt psbasemap -R0/10/0/25/0/30 -JX5c/10c -JZ10c -Bxa+lx  -Bza+lz -BwsENZ1+b -py135/20/10 -png lixo

[seisman]

xref: #529

[uleysky]

Agree. In your first drawing, the plane is also shifted correctly, only the frame is drawn incorrectly.

[joa-quim]

Looking better at this I'm no longer convinced that this is a bug. What it does is the, useless, re-projection of one of the planes on another wall. And not using a cube the plane sides have do the same size as the wall where they are projected and hence we see what we see.

But on a more useful exercise, I'm trying to plot an image one the sides of a cube (that way well be the vertical sides of a grdview plot). And here we have bugs as well.

This one is correct (commands in Julia but with plain GMT generated syntax below)

julia> basemap(R="-75/-60/-50/-40/0/999", JZ=8, J=:merc, p=(135,30), Vd=1)
        psbasemap  -R-75/-60/-50/-40/0/999 -JM15c -Baf -Bza -JZ8 -p135/30 -P -K > c:\TMP/GMTjl_j.ps
julia> image!("@maxresdefault.jpg", pos=(map=true,anchor=(-75,-50), width=(15,8)), p="y135/30", show=1, Vd=1, name="atorig.jpg")
        psimage @maxresdefault.jpg  -R -J -py135/30 -Dg-75/-50+w15/8 -K -O >> c:\TMP/GMTjl_j.ps

Now let's try to move it along the latitudinal axis. It wrongly moves it along the zz axis

julia> basemap(R="-75/-60/-50/-40/0/999", JZ=8, J=:merc, p=(135,30), Vd=1)
julia> image!("@maxresdefault.jpg", pos=(map=true,anchor=(-75,-48), width=(15,8)), p="y135/30", show=1, Vd=1, name="moveatlat.jpg")
        psimage @maxresdefault.jpg  -R -J -py135/30 -Dg-75/-48+w15/8 -K -O >> c:\TMP/GMTjl_j.ps

@remkos do you still remember where is the code that deals with this?

[joa-quim]

More work and more comprehension. The above image is not bugged either. It's raised in the xz plane because I first moved it up along lat with the Dg-75/-48 (origin is at -75,-50) and it was the -py135/30 final rotation that put it in that position.

The real problem that I'm facing right now is that the z in azim/elev/z is ignored. Doing the trig in Julia to compute the necessary X,Y offsets I can now

[remkos]

It was only designed to work on those three planes as illustrated in @joa-quim 's last post.
I remember from back when I created the implementation (>10y ago) that particularly the one illustrated before did not work.
The transformation matrix is actually not that difficult for the image projection, but I think Ghostscript appears to have limitations when negative numbers end up in it.
I never wrote those out (in frustration). But know there are.
The frames were later many times modified. I won't claim they were working 100% in the past, but also abdicate responsibility for it.
In any case the relatively simple transformation approach has faults and they may be due to limitations in Ghostscript.

[joa-quim]

Remko, what I did was to compute the missing z feature obedience in terms of -X<off>, -Y<off> (had to resort to mapproject to compute the new origin along the axis I wanted to slide on). We can´t blame Ghostscript for that. I tried to see if I could do the same thing in C but the code is very complicated for me to decipher it.

And note also that plotting on the North side is not currently possible because it needs that z. Only the South side should work well.