bugGNU Octave - Bugs: bug #57464, patch plot of quadrilateral ill...

 
 

bug #57464: patch plot of quadrilateral ill shaped

Submitter:  Hg200 <hg200>
Submitted:  Sun 22 Dec 2019 07:41:13 PM UTC
   
 
Category:  Plotting Severity:  3 - Normal
Priority:  5 - Normal Item Group:  Matlab Compatibility
Status:  Confirmed Assigned to:  None
Originator Name:  Open/Closed:  * Open
Release:  * dev Operating System:  * Any
Fixed Release:  None Planned Release:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

Tue 24 Dec 2019 10:42:38 AM UTC, comment #12: 

All update functions are executed immediately after a graphics property is set. So even when setting the "xdata", "ydata" and "zdata" in a single "set" command, the update functions for each property are executed one after the other.
I assume that the "2d-mode" is executed when "xdata" and "ydata" are already set but "zdata" isn't yet.
Maybe the fact that we don't defer some callbacks until after all properties are set is partly causing the slow performance.

Also most probably, it would be sufficient to only execute part of update_data after setting "[xyz]data". But I fear that the coplanarity test is probably the computationally most expensive one.
However, I haven't looked into that yet. Also I probably won't be able to for the next week or two.

I understand that trying to follow the chain of callbacks in graphics.cc can be confusing. But any help to improve that code (especially performance related) is always welcome.

Markus Mützel <mmuetzel>
Group administrator
Mon 23 Dec 2019 06:30:06 PM UTC, comment #11: 

@Markus:
I have made a complete new built with your patch applied. It is awful slow. But i can confirm the problem is solved and the MWE as well as the streamribbon is displayed correctly.

As i have seen earlier during debugging for example fvc (face vertex data) is called at least 3 times. it looks that something like a netlist (similar to what a mesher creates for a finite element analysis) is created there from the vertices given to patch () and written to idx and vert. but why 3 times? the first time it is in a so called "2d" mode. or is this a gdb artifact?

it is somewhat beyond my scope but sounds crazy enough to spend a whole day just stepping from _go_patch and see what it is happening in this mysterious graphics.cc. this will result most likely in more questions than answers but maybe there are also some findings - who knows ;-)

Hg200 <hg200>
Mon 23 Dec 2019 04:38:57 PM UTC, comment #10: 

Regarding comment #6, FLTK and Qt both use gl-render.cc code so the behavior is the same.

Rik <rik5>
Group administrator
Mon 23 Dec 2019 04:15:50 PM UTC, comment #9: 

@hg200: You are right. When setting the "[xyz]data" the update_data function never is executed.

The attached patch fixes your tests for me.
But drawing patches feels slow with it. Maybe some update functions are executed several times (unnecessarily)?

(file #48112)

Markus Mützel <mmuetzel>
Group administrator
Mon 23 Dec 2019 03:55:39 PM UTC, comment #8: 

I filed a separate bug report (bug #57471) about switching streamtube to use a surface object as opposed to a patch object.

Rik <rik5>
Group administrator
Mon 23 Dec 2019 03:51:55 PM UTC, comment #7: 

A quick way to guarantee whether code is reached is to add


assert (0);


before the code in question.  You may need to add


#include <cassert>


as well for access to the library function.

This will immediately abort the program as soon as the assert is reached.  It is a somewhat clumsy debugging mechanism, but sometimes, particularly if there are a lot of callbacks, I don't always trust the debugger gdb to guarantee a stop at a particular point.

Rik <rik5>
Group administrator
Mon 23 Dec 2019 02:33:29 PM UTC, comment #6: 

I know nobody will believe me but i think


patch::properties::update_data  ()
coplanar_partition ()


is not executed. I can't halt either at breakpoint nor stop the program if i put there any stopper conditions like an endless loop. Who calls update_data () and where? I only see prototypes and the implementation.

Then i have another question: Same problem occurs if we set the graphics_toolkit to FLTK. Does has FLTK its own interface to opengl or is the data also processed through gl_renderer?

What i will do anyway is to fetch a complete new repo and start over with a fresh make.

Hg200 <hg200>
Mon 23 Dec 2019 10:58:11 AM UTC, comment #5: 

That really is unexpected.

It might be that the code for coplanar partitioning fails. That is in graphics.cc function "coplanar_partition" (at around line 9733).

Or it might be the drawing. That is in gl-render.cc function "draw_patch" (in particular the code starting at around line 3390).

IIRC, OpenGL tessellator conflates points or constructs new ones if the passed points are non-coplanar (with sometimes unexpected results).
I'm guessing that is what you found. So it would probably make sense to start looking at "coplanar_partition" or "is_coplanar" in graphics.cc.

Markus Mützel <mmuetzel>
Group administrator
Mon 23 Dec 2019 09:49:17 AM UTC, comment #4: 

Even more strange. In the attached script 3 points of a square are fixed and one point is rotated around. It looks like there are angles when only a triangle is shown.

In Matlab this demo shows a filled plane for all 360 degrees.

(file #48108)

Hg200 <hg200>
Mon 23 Dec 2019 08:28:58 AM UTC, comment #3: 

The result is still the same with Octave 6.0 (hg id 1a75fca6ad5d).

I wonder where the fifth vertex in the center face is coming from.

Markus Mützel <mmuetzel>
Group administrator
Mon 23 Dec 2019 06:49:23 AM UTC, comment #2: 

Tested with 5.1.0 on Windows and with d053ff4321b5 on Linux. Matlab test was on R2018b.

You are right: The streamribbon graphics handle in matlab is surface () and not patch (). I had not thought of that. Then I will also prepare a fix for streamtube.m. Same problem there (patch must be replaced by surface).

Hg200 <hg200>
Mon 23 Dec 2019 05:00:12 AM UTC, comment #1: 

Which Octave version did you use for your test?

Wrt streamribbon: Which graphics object does Matlab use? If a user modifies graphics properties after using that function, code cold become incompatible if the used graphics objects differ.

Markus Mützel <mmuetzel>
Group administrator
Sun 22 Dec 2019 07:41:13 PM UTC, original submission:  

The patch plot command can be used to plot polygons like quadrilaterals. The four vertices may not be within a plane. In this case the quadrilateral is split in order to show it correctly.

Sometimes the quadrilateral is displayed ill shaped (split angle too steep?). picture1 shows the result of the attached script test_patch.m in octave as well as matlab. The plot output differs.

The second picture (picture2) shows a streamribbon where this behaviour can become an issue. One plot is made with patch () the other with surface (). It looks like surface () shows quadrilaterals always correctly.

For streamribbon.m i will continue with surface () instead of patch () therefore marking as Matlab Compatibility.

Hg200 <hg200>

 

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

Attach Files:
   
   
Comment:
   

Attached Files
file #48112:  bug57464_patch_update_data.patch added by mmuetzel (2KiB - application/octet-stream)
file #48108:  rotate_rectangle.m added by hg200 (1KiB - text/x-objcsrc)
file #48100:  picture1.png added by hg200 (32KiB - image/png)
file #48101:  test_patch.m added by hg200 (490B - text/x-objcsrc)
file #48102:  picture2.png added by hg200 (23KiB - 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 mmuetzel (Posted a comment)
  • -email is unavailable- added by hg200 (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 10 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2019-12-23 rik5 Item GroupIncorrect Result Matlab Compatibility
    2019-12-23 mmuetzel Attached File- Added bug57464_patch_update_data.patch, #48112
        Item GroupMatlab Compatibility Incorrect Result
    2019-12-23 hg200 Attached File- Added rotate_rectangle.m, #48108
    2019-12-23 mmuetzel StatusNone Confirmed
        Releaseother dev
        Operating SystemGNU/Linux Any
    2019-12-22 hg200 Attached File- Added picture1.png, #48100
        Attached File- Added test_patch.m, #48101
        Attached File- Added picture2.png, #48102

    Back to the top

    Powered by Savane 3.13-4448.
    Corresponding source code