bugGNU Octave - Bugs: bug #38779, patch failure with quadrilateral...


bug #38779: patch failure with quadrilateral face

Submitted by:  None
Submitted on:  Sat 20 Apr 2013 01:27:22 AM UTC  
Category:  Plotting Severity:  3 - Normal
Priority:  5 - Normal Item Group:  None
Status:  Confirmed Assigned to:  None
Originator Name:  Dan Newman Originator Email:  -email is unavailable-
Open/Closed:  Open Release:  dev
Operating System:  GNU/Linux

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)

Fri 23 Sep 2016 02:12:43 PM UTC, comment #9:

I didn't see this bug before I opened a new one for the same issue where I posted a changeset: bug #47677

I think one of the two can be closed as a dublicate.

Markus M├╝tzel <mmuetzel>
Project Member
Mon 24 Mar 2014 03:39:16 PM UTC, comment #8:

To be honest, I don't think that rendering a polygon with 3D non-planar contour is a simple problem. Maybe using GLU tessellation is simply not the right way to do it, but I don't know any better.

Michael Goffioul <goffioul>
Project Member
Mon 24 Mar 2014 03:20:04 PM UTC, comment #7:

Thanks Michael. It appears that this simple problem (a single polygon drawn incorrectly) is going to require a complicated solution.

Rik <rik5>
Project Administrator
Mon 24 Mar 2014 01:24:41 PM UTC, comment #6:

I've done some more debugging, which gave a few additional clues. I don't have more time to allocate to this atm.

As part of the tessellation process, as described in [1], the polygon is projected onto a plane, where the triangulation is done. In this case, it determines that the projection plane is perpendicular to Y axis. So the GLU algorithm considers that the first 2 vertices of the polygon create a degenerated edge and merge them.

What I've noticed is that the problem starts to appear when the Y coordinate gradient becomes small compared to the other axis. So a possible way to mitigate the problem can be to prescale/normalize the coordinates before sending them to OpenGL (which would also solve the problem of limited precision of floating point numbers). Though I'm not sure this would be a perfect solution, and you could still find edge cases where this problem occurs while tessellating non-planar polygons.

[1] http://stackoverflow.com/questions/12852029/what-is-the-algorithm-behind-the-glutess-functions

Michael Goffioul <goffioul>
Project Member
Mon 24 Mar 2014 11:12:13 AM UTC, comment #5:

Yes, from debugging it a little bit, it seems that is what's happening: combine is called to merge vertices. I'll try to debug further to understand why this is happening, at the moment I still don't know why.

Michael Goffioul <goffioul>
Project Member
Mon 24 Mar 2014 05:23:58 AM UTC, comment #4:

Another thing that happens is that the combine() routine of patch_tesselator gets called when the number of vertices is dropped from 4 to 3. So, it really seems that OpenGL is the one that is dropping the vertex.

Rik <rik5>
Project Administrator
Mon 24 Mar 2014 03:46:16 AM UTC, comment #3:

Matlab draws this patch object correctly. The following code was run on Matlab and it generates a quadrilateral. The two png files are attached.

(file #31017, file #31018)

Rik <rik5>
Project Administrator
Sun 23 Mar 2014 07:51:55 PM UTC, comment #2:

I've tried to do some more debugging on this, but have not had much luck. I've added Michael Goffioul, who wrote the original GL renderer code, to the CC list in case he has an idea about what is happening.

The vertices are correctly added by Octave to a patch_tesselator object in the draw_patch routine in the file gl-render.cc. I checked by adding some printf statements. I also checked the patch tesselator object by putting a printf routine in the vertex() callback routine. Here there seems to be a problem because I only see 3 vertices printed. If I change the initial x-coordinate in the patch pts to 10.5 then I definitely get 4 vertices in the callback routine. So, it would appear that OpenGL itself is taking out one of the vertices. However, this might be because we haven't set the right options to OpenGL and it is filtering polygons. I don't really know.

Separately, it's a different part of the draw_patch routine which puts the markers on the vertices, but that code at least recognizes the fourth vertex as shown by the code below.

The patch face (polygon) is still a triangle connecting only 3 vertices, but the 4 vertices are marked with red 'x'.

So, I'm stumped at this point.

Rik <rik5>
Project Administrator
Thu 27 Jun 2013 04:29:19 AM UTC, comment #1:

This bug is confirmed. It is very sensitive to the actual values of the pts. For example, changing x(1,1) by .0001 is enough to force the correct interpretation.

I don't have time to look into this, but for anyone who is interested you probably want to start with the function draw_patch in libinterp/interp-core/gl-render.cc. It appears to be a renderer bug rather than a bug in graphics.cc since the data on faces and X,Y,Z points is stored correctly.

Rik <rik5>
Project Administrator
Sat 20 Apr 2013 01:27:22 AM UTC, original submission:

I'm using the fltk graphics toolkit.

The patch command sometimes (very rarely) fails to draw quadrilateral faces correctly. A minimal demo is:

This should draw a non-planar quadrilateral element. Instead it draws a triangular element joining points 2,3,4 only.

Note that this was extracted from a larger graphic with several hundred vertices and faces, some quadrilateral and some triangular. All were rendered correctly except this one.



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

Attach Files:

Attached Files
file #31017:  patch_test.png added by rik5 (7KiB - image/png)
file #31018:  patch_test2.png added by rik5 (11KiB - image/png)


   bug dependencies.

Items that depend on this one: None found


Carbon-Copy List
  • -email is unavailable- added by mmuetzel (Posted a comment)
  • -email is unavailable- added by goffioul (Posted a comment)
  • -email is unavailable- added by rik5
  • -email is unavailable- added by rik5 (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.


    Please enter the title of George Orwell's famous dystopian book (it's a date):



    Follow 7 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2016-09-23 rik5 Dependencies- => Depends on bugs #47677
    2014-03-24 rik5 Attached File- => Added patch_test.png, #31017
        Attached File- => Added patch_test2.png, #31018
    2014-03-23 rik5 StatusPostponed => Confirmed
        Release3.6.2 => dev
    2014-03-23 rik5 Carbon-Copy- => Added michael goffioul
    2013-06-27 rik5 StatusNone => Postponed

    Back to the top

    Powered by Savane 3.3