bugGNU Octave - Bugs: bug #51938, Contour lines of meshc disappear...

 
 

bug #51938: Contour lines of meshc disappear when calling axis

Submitted by:  None
Submitted on:  Mon 04 Sep 2017 08:06:57 PM UTC  
 
Category:  Octave Function Severity:  3 - Normal
Priority:  5 - Normal Item Group:  Incorrect Result
Status:  Fixed Assigned to:  None
Originator Name:  sbeau Originator Email:  -email is unavailable-
Open/Closed:  Closed Release:  4.2.1
Operating System:  Any

Add a New Comment (Rich Markup)
   

You are not logged in

Please log in, so followups can be emailed to you.

 

( Jump to the original submission)

Sat 02 Feb 2019 06:27:18 AM UTC, comment #9: 

Fixed on the development branch in this cset: https://hg.savannah.gnu.org/hgweb/octave/rev/a7dfb00d5bf5.

This will be a part of the Octave 6.1 release.  To access the fix sooner download axis.m from the Mercurial development branch and replace your local copy.

Closing report.

Rik <rik5>
Project Administrator
Wed 06 Sep 2017 08:00:30 AM UTC, comment #8: 

I may have found the property I was looking for.  The "handlevisibility" seems to affect whether or not the object is included in the axes data elements for auto-ranging.  Attached is a new patch in which the contour placement does not alter the zlim settings.  I think this is more along the lines of what people are expecting.  However, often, as in the case of gnuplot, the contour plane is technically in the z-range but is an extended area having its own parameter controlling the percentage of space to add.  Note, however, that Octave as it stands can't do that because this line of code:

    [~, htmp2] = __contour__ (hax, zmin, varargin{:});

is using zmin.

(file #41743)

Dan Sebald <sebald>
Wed 06 Sep 2017 07:23:53 AM UTC, comment #7: 

I've attached a simple patch that adds a listener to the axes that passes the contour handle into the function so it may be used to adjust the zlim.

The following works about right:

graphics_toolkit qt
figure
[X,Y] = meshgrid(-3:.125:3);
Z = peaks(X,Y);
meshc(X,Y,Z)
axis('equal')

albeit a little clunky.

However, pressing "Autoscale" has a problem.  Although the listener is called, the placement of the contour seems to affect auto-zlim range.  I've lessened the effect by de-activating zlimmode adjustment temporarily, but once it gets turned back on the range readjusts.  In the patch I've printed out the actual value of zlim minimum to illustrate.  I suppose the autoscale is designed to leave a bit of space beyond the data limit even if that data limit falls at a nice whole number.  (Without turning off auto-adjust, the code will get into a short feedback loop where it keeps adjusting until finding a stopping point.)  If someone can think of a way around this auto-adjusted zlim caused by the placement of the contour, let me know (e.g., is there a way to take the particular contour object out of the list of data elements used to determine auto-range?).

(file #41742)

Dan Sebald <sebald>
Tue 05 Sep 2017 06:22:21 PM UTC, comment #6: 

"listener", that's what I was trying to think of.  Thanks.

Dan Sebald <sebald>
Tue 05 Sep 2017 06:20:01 PM UTC, comment #5: 

The code that sets the level is here in meshc.m:

    zmin = get (hax, "zlim")(1);
    [~, htmp2] = __contour__ (hax, zmin, varargin{:});

The bad is that there is nothing in axis.m that resets the contour.  The good is that the contour is an hggroup with a parameter for the zlevel.

    kids = get(gca,'children');
    get(kids(1))
    zlevel = -10

Hence we should be able to make things work, for "axis" anyway, but automating something like the following:

figure
[X,Y] = meshgrid(-3:.125:3);
Z = peaks(X,Y);
meshc(X,Y,Z)
axis('equal')
zlevel = min(get(gca,'zlim'))
kids = get(gca,'children');
set(kids(1), 'zlevel', zlevel)

and that does in fact work.  So, any scripts that modify the axes ranges need to go through the list of graphics objects, test if they are contour (if they have the 'zlevel' property, I assume) and change the zlevel property.

That wouldn't be a difficult set of changes to make, but what about the z-range being changed via the mouse?  I don't see any way of changing z limits via the plot, only x and y limits.  Except of one considers the "A" autorange button, then that alters the Z-range.  I've tested Qt plot by printing something in axis.m when the "axis('equal')" is called--unfortunately, when the "Autoscale" is pressed in the Qt plot window that doesn't make its way back to the axis.h routine.  So what to do in that case, I don't know.

Dan Sebald <sebald>
Tue 05 Sep 2017 06:14:41 PM UTC, comment #4: 

@Dan: Probably you are right.  What does Matlab do for

figure
[X,Y] = meshgrid (-3:.125:3);
Z = peaks (X,Y);
meshc (X,Y,Z);
zlim (-3, 10);
view (330, 15);
print mesh.png

If Matlab is always drawing the contours at the lower Z limit, then Octave needs to have a listener on the Z-axes and redraw as necessary.

Rik <rik5>
Project Administrator
Tue 05 Sep 2017 05:33:04 PM UTC, comment #3: 

Acknowledging the behavior here, and noting that this is "Any" operating system.  Also, the contours disappear in the gnuplot toolkit as well, so that means contour lines are not being handled by gnuplot (since gnuplot handles contours without forcing some z coordinate on the lines...they always are associated with the border) and that its not a real low level function of gl-rendering where the problem lies.

Sort of mid-level routine would be my guess.  But I'm also wondering if there is a design problem in the sense that only the lowest level of plotting can determine what the eventual axis limits will be.  Or maybe the contour drawing needs to be done with one of those feedback functions such that when the user rescales the plot or moves the axes about via the mouse wheel then the Z-position of the contours is changed.  The equivalent concept for gnuplot would be using gnuplot's internal contour commands, because gnuplot is the only code that knows what the final plot limits are.

Dan Sebald <sebald>
Tue 05 Sep 2017 02:39:36 AM UTC, comment #2: 

The contours aren't deleted, but they are located an Z == -10.  The call to "axis ('equal')" merely sets the lower Z lim above that.  Try adding

zlim ([-10, 10]);

at the end of the code segment.

Rik <rik5>
Project Administrator
Tue 05 Sep 2017 01:57:14 AM UTC, comment #1: 

I found that if you do an autoscale then the contour lines show again.

Doug Stewart <dastew>
Mon 04 Sep 2017 08:06:57 PM UTC, original submission:  

Here is the code:

figure
[X,Y] = meshgrid(-3:.125:3);
Z = peaks(X,Y);
meshc(X,Y,Z)
axis('equal')

The function meshc will correctly draw the contour lines but the execution of axis('equal') will delete the contour lines from the figure. We don't see this behaviour in Matlab.

Anonymous

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by sebald (Posted a comment)
  • -email is unavailable- added by rik5 (Posted a comment)
  • -email is unavailable- added by dastew (Posted a comment)
  • -email is unavailable- added by None (Submitted the item)
  •  

    Do you think this task is very important?
    If so, you can add your encouragement to it.
    This task has 0 encouragements so far.

    Only project members can vote.

     

     

     

    Follow 8 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2019-02-02 rik5 StatusNeed Info => Fixed
        Open/ClosedOpen => Closed
    2017-09-06 sebald Attached File- => Added octave-contour_listener-djs2017aug06.patch, #41743
    2017-09-06 sebald Attached File- => Added octave-contour_listener-djs2017aug05.patch, #41742
    2017-09-05 rik5 SummaryContour lines of meshc disapear when calling axis => Contour lines of meshc disappear when calling axis
    2017-09-05 rik5 Item GroupNone => Incorrect Result
        StatusNone => Need Info
        Operating SystemMicrosoft Windows => Any

    Back to the top


    Powered by Savane 3.5