## 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: -unavailable- Open/Closed: Open Release: dev Operating System: GNU/Linux

Add a New Comment (Rich Markup):

## You are not logged in

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>
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>
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.

Michael Goffioul <goffioul>
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>
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>
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.

Rik <rik5>
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>
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>
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.

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)

Depends on the following items: None found

Items that depend on this one: None found

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

Do you think this task is very important?
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):