#2617 Glitch in displaying multivalued functions in 'pm3d at base'

[Hiroki Motoyoshi]

When I tried to draw a projection on the xy-plane of a parameterized multivalued function using 'pm3d at base' with the 'depthorder' option, a surface containing a glitch was drawn.

This phenomenon resembles the one pointed out in Bug #2604, but the cause is different, and this bug is not depending on the OS environment.

I think that the result of depth sorting from the view of right overhead (or right underneath) should be drawn on the base plane. It would be even better if it could be done in 3D 'polygon' as well.

#
set parametric
set urange [-pi:pi]
set vrange [-pi:pi]
set zrange [-3:2]
set isosamples 50,20
set view equal xyz

unset key
unset xtics
unset ytics
unset ztics
set border 0
set view 60, 30
unset colorbox
set xyplane 0

set title "PM3D surface\ndepth sorting"

set pm3d depthorder

splot cos(u)+.5*cos(u)*cos(v),sin(u)+.5*sin(u)*cos(v),.5*sin(v) with pm3d at sb, \
      1+cos(u)+.5*cos(u)*cos(v),.5*sin(v),sin(u)+.5*sin(u)*cos(v) with pm3d at sb

pause -1

[Ethan Merritt]

I am surprised to see anything at all on the base of the plot. I thought in version 5.4 the depthorder mode of pm3d did not draw to the base. Parametric mode must use a different code path.

I don't remember whether not projecting a depth-sorted plot onto the base was a deliberate decision or whether it just stopped working some time between versions 5.2 and 5.4. Probably the latter. So there is a bigger issue here.

It should in principle be easy to re-sort the pm3d quadrangles along the true z value instead of along the line of sight so that the top/bottom projections were appropriately colored. But I'm afraid the current depth-sorting algorithm makes this difficult. The data is first processed and stored into a single long list of quadrangles. Then list is sorted and rendered once for each requested "at" position (base/top/bottom). The problem is that the stored quadrangles do not retain the original z value, only the transformed coordinate (depth) after rotation by the view matrix. So the original z is no longer there to use for sorting.

In a sense this is exactly parallel to issue #2604, in that the limitation could be overcome by increasing the size of the data structure so that an additional field is available for sorting.

[Hiroki Motoyoshi]

Instead of the multivalued function, even the projection onto the base of two surfaces like the 2nd plot in 'pm3d_clip.dem’ looks to be drawn without depth sort.

Is 2D drawing by set view map also affected by this issue?

unset key
unset colorbox
set view 57, 25
set samples 13, 13
set isosamples 7, 7
set xyplane 0
set xrange [ 0.0 : 10.0 ]
set yrange [ 0.0 : 10.0 ]
set pm3d depthorder 
set pm3d border lw 0.5
set pm3d at sb

splot (x*x+y*y) with pm3d fc "yellow",\
      100-(x*x+y*y) with pm3d fc "forest-green"

pause -1

set view map

replot

pause -1

[Ethan Merritt]

The "projection" onto the top or bottom plane is really just a replacement of all the z coordinates with a fixed value. Obviously once you do that, clipping on z makes no sense, and sorting on z does not distinguish one base-plane segment from another. "set pm3d depth" does have the effect of allowing the base plane and the ceiling plane to be properly positioned in 3D relative to the surface.

This is old code, going back to some time in the 1990s when pm3d was a separate program adapted for use as a special terminal by gnuplot. I'm sure it would not be organized this way if it were being written now. I think it is reasonable to consider revising the algorithm so that the original z coordinates are retained and assignment to the top or bottom plane is instead indicated by a separate flag. That seems beyond the scope of a bug fix. Maybe a project for the development version?

set view map is not 2D drawing. It is full 3D drawing with the view point positioned directly above the surface and looking down. So yes, it has the same limitations with respect to z clipping of components assigned to the top or bottom planes rather than the surface proper.

[Hiroki Motoyoshi]

I'm sorry for the mistake of sample script for 'set view map' in the post.
It should be

set view map
set pm3d at s

replot

It shows the expected result, i.e. "the view point positioned directly above the surface and looking down".

This is old code, going back to some time in the 1990s when pm3d was a separate program adapted for use as a special terminal by gnuplot. I'm sure it would not be organized this way if it were being written now. I think it is reasonable to consider revising the algorithm so that the original z coordinates are retained and assignment to the top or bottom plane is instead indicated by a separate flag. That seems beyond the scope of a bug fix. Maybe a project for the development version?

Thank you for explaining the implementation difficulties. It is sufficient if the set view map works correctly. Even if there is a limitation on pm3d at base for drawing multivariable functions, I think it is acceptable since it is considered to be used infrequently.