bugGNU Octave - Bugs: bug #67274, polar plot background patch...

 
 

bug #67274: polar plot background patch obscures data when view changed

Submitter:  José Luis García Pallero <jgpallero>
Submitted:  Fri 04 Jul 2025 02:13:09 PM UTC
   
 
Category:  Plotting Severity:  3 - Normal
Priority:  5 - Normal Item Group:  Incorrect Result
Status:  Fixed Assigned to:  None
Originator Name:  jgpallero Open/Closed:  * Closed
Release:  * 10.2.0 Release: 
Operating System:  * Any Fixed Release:  11.1.0 (current default)
Planned Release:  11.1.0 (current default)
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

Sat 12 Jul 2025 06:18:56 PM UTC, comment #7: 

Changeset seems to work.  Marking as Fixed and closing report.

Rik <rik5>
Group administrator
Thu 10 Jul 2025 03:43:08 PM UTC, comment #6: 

Thank you very much, Nicholas

José Luis García Pallero <jgpallero>
Thu 10 Jul 2025 03:39:20 PM UTC, comment #5: 

i'm only seeing:  compass, rose, ezpolar, and the ricks, thetaticks, rticklabels, thetaticklabels functions that call polar, and all of them still pass their tests, demos look fine.

finished a make check without errors, so pushed to default as:
https://hg.savannah.gnu.org/hgweb/octave/rev/0aa3318a4812

this change should be part of octave 11. the workaround at the end of comment #1 should hopefully allow you to move forward with your desired process until then.

marking as ready for test.


Nicholas Jankowski <nrjank>
Group Member
Wed 09 Jul 2025 04:02:05 PM UTC, comment #4: 

patch vs default attached. not really BIST-able (unless there's some view-order property that can be checked for graphics objects to see what's in front/visible?) but does add a viewpoint change demo that was previously obscured. passes 'test polar' but haven't run test suite or looked for anything else that calls polar yet.

(file #57382)

Nicholas Jankowski <nrjank>
Group Member
Wed 09 Jul 2025 03:33:51 PM UTC, comment #3: 

ok, it looks like @Rik added that back in 2014 in
https://hg.savannah.gnu.org/hgweb/octave/rev/56bff71de2ca
connected to bug #39495, comment #5

I don't see any mention in there of why z=-1 was chosen, so maybe it was arbitrary to ensure no interference and assuming persistent 2D front view. If the goal was to give a nice solid black border to the circle, it appears that the border color never comes through (the gray, sort of aliased border from the outside line is visible in all cases vs the solid black patch border) no matter the patch position.

patch is fairly simple, just changing "-ones" to "zeros" in that line. will play around with it and try to break it.



Nicholas Jankowski <nrjank>
Group Member
Wed 09 Jul 2025 02:02:17 PM UTC, comment #2: 

to answer my last question, the patch creation block in polar is:


  ## Draw colored disk under axes at Z-depth = -1
  patch (x(:,end), y(:,end), -ones (circle_points, 1),
         get (hax, "color"), "parent", hg);


So it's deliberate, but I'm really not sure why. I'll try to dig through changelogs and see if there's a reason.  It's a non-matlab compatible object creation.  I was concerned that having everything in z=0 would create rendering 'order' issues, but with the patch in the z=0 plane everything still appears to remain visible from any orientation. Checked in qt, fltk, and gnuplot graphics toolkits, and no issues except for gnuplot sometimes throwing warnings about drawing patch objects (not consistent and didn't dig into it).

unless someone can point out a good reason for a z=-1 patch location, I'll work up a patch for this on default that puts it at z=0.

Nicholas Jankowski <nrjank>
Group Member
Tue 08 Jul 2025 07:20:52 PM UTC, comment #1: 

this isn't related to view or rose.  it's an issue with how polar plots are created. in particular, the 'patch' object used to create  the white background.  see the following:


polar(0:30:360);
view(3)


using the 3d view, we see that for some reason the polar plot creates a circular patch object for the white 'background' at z=-1.  the patch is opaque, so when you changed the view to flip 180deg to make the z axis point into the page instead of out of the page, the patch object was in the way. this can also be seen with an off angle view from 'below':


view([-1,-1,-1])


where the patch partially obscures the plot, as shown in the attached.

Checking matlab's polar function, there is no separated white patch object. everything appears to be in the z=0 plane and can be viewed from both sides.

in octave, manually moving the patch to the zero plane appears to allow visibility from both directions.  I don't know if there are conditions where coincident lines and patches will obscure each other. But something like the following adapted to your specific case may provide a temporary workaround for you:


polar(30:30:360);
patchhandle = findall(gca, 'type', 'patch');
set(patchhandle, 'zdata', zeros(size(get(patchhandle,'zdata'))))
view(90,-90)



updating bug title and marking as confirmed.  I haven't looked at polar to see if there's an intentional reason for putting the patch at z = -1, but if not maybe this can be changed for the next version of octave.



Nicholas Jankowski <nrjank>
Group Member
Fri 04 Jul 2025 02:13:09 PM UTC, original submission:  

Suppose the code:

A = randn(1,10);
subplot(1,2,1);
plot(A);
subplot(1,2,2);
plot(A);
view(90,-90);

In this case the the view() command works and produces the same result in Octave and in Matlab.

Suppose now this code using rose():

A = abs(randn(1,10000));
A = A./max(A)*720*pi./180;
subplot(1,2,1);
rose(A,30);
subplot(1,2,2);
rose(A,30);
view(90,-90);

rose() plots the origin on the X axis and the data are representd counterclockwise. I want the angular origin coincident with the positive direction of Y axis and data represented clockwise. In order to do that I apply the order view(90,-90). In Matlab it works, but the result in Octave is incorrect. The origin and angular direccion is right, but the data are not plotted. Attached I send two images.

Is it a bug in view() implementation in Octave?

José Luis García Pallero <jgpallero>

 

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

Attach Files:
   
   
Comment:
   

Attached Files
file #57382:  polar_patchmove_bug67274.diff added by nrjank (2KiB - application/octet-stream - patch moving background patch to z=0 and adding view change demo)
file #57376:  obscured_plot.png added by nrjank (33KiB - image/png - plot of background patch obscuring plot details from other views)
file #57360:  matlab.png added by jgpallero (54KiB - image/png)
file #57361:  octave.png added by jgpallero (62KiB - image/png)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by rik5 (Posted a comment)
  • -email is unavailable- added by nrjank (Updated the item)
  • -email is unavailable- added by jgpallero (Submitted the item)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only group members can vote.

     

    Follow 13 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    18:18 rik5 StatusReady For Test Fixed
        Open/ClosedOpen Closed
        Fixed ReleaseNone 11.1.0 (current default)
    2025-07-10 nrjank Planned ReleaseNone 11.1.0 (current default)
    2025-07-10 nrjank StatusPatch Submitted Ready For Test
    2025-07-09 nrjank Attached File- Added polar_patchmove_bug67274.diff, #57382
        StatusConfirmed Patch Submitted
    2025-07-08 nrjank Attached File- Added obscured_plot.png, #57376
        StatusNone Confirmed
        Operating SystemGNU/Linux Any
        SummaryIncorrect results of view() when applied to a rose() plot polar plot background patch obscures data when view changed
    2025-07-04 jgpallero Attached File- Added matlab.png, #57360
        Attached File- Added octave.png, #57361

    Back to the top

    Powered by Savane 3.15-e6e5.
    Corresponding source code