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

 
 

bug #38779: patch failure with quadrilateral face

Submitted by:  None
Submitted on:  Sat Apr 20 01:27:22 2013  
 
Category: PlottingSeverity: 3 - Normal
Priority: 5 - NormalItem Group: None
Status: ConfirmedAssigned to: None
Originator Name: Dan NewmanOriginator Email: -unavailable-
Open/Closed: OpenRelease: dev
Operating System: GNU/Linux

Add a New Comment (Rich MarkupRich Markup):
   

You are not logged in

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

 

(Jump to the original submission Jump to the original submission)

Fri Sep 23 14:12:43 2016, 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 Mar 24 15:39:16 2014, 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 Mar 24 15:20:04 2014, 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 Mar 24 13:24:41 2014, 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 Mar 24 11:12:13 2014, 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 Mar 24 05:23:58 2014, 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 Mar 24 03:46:16 2014, 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 Mar 23 19:51:55 2014, 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 Jun 27 04:29:19 2013, 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 Apr 20 01:27:22 2013, 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.

Anonymous

 

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

Attach File(s):
   
   
Comment:
   

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

 

Digest:
   bug dependencies.

Items that depend on this one: None found

 

Carbon-Copy List
  • -unavailable- added by mmuetzel (Posted a comment)
  • -unavailable- added by goffioul (Posted a comment)
  • -unavailable- added by rik5
  • -unavailable- added by rik5 (Posted a comment)
  • -unavailable- added by None (Submitted the item)
  •  

    Do you think this task is very important?
    If so, you can click here to 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
    Fri Sep 23 16:42:49 2016rik5Dependencies-=>Depends on bugs #47677
    Mon Mar 24 03:46:16 2014rik5Attached File-=>Added patch_test.png, #31017
      Attached File-=>Added patch_test2.png, #31018
    Sun Mar 23 19:51:55 2014rik5StatusPostponed=>Confirmed
      Release3.6.2=>dev
    Sun Mar 23 19:21:41 2014rik5Carbon-Copy-=>Added michael goffioul
    Thu Jun 27 04:29:19 2013rik5StatusNone=>Postponed

    Back to the top


    Powered by Savane 3.1-cleanup