1

I have two simple cube-shaped primitives that are pushed together. Where the polygons connect, there is a razor-thin seam where the polygon edges match up (see pic, red arrow).

enter image description here

Each face owns its own vertices, they are not shared with indicia. I have confirmed with debugging that the coordinates of the vertices at each end of the seam that should be occupying the same position ARE occupying the same position/normal/uv. The winding of the faces that join together are the same. I have even adjusted the code to MANUALLY COPY the positions, normals, and UV of the vertices in question just in case there was some floating point error that was too small to be display.

Can anyone explain what's going on here? Is there a way to fix it without literally joining those vertices into a single vertex and indexing it?

I've included a wireframe pic in the screenshot as well. I can tell from the wireframe that the two lines, though overlapping, are a bit off. But with all coordinates at the same value, what is it??

KiraHoneybee
  • 495
  • 3
  • 12
  • Your vertex positions must be different. Your debugger may be showing you a rounded number, you are comparing the wrong vertices, or there is something else that's changing between the primitives (like a model matrix). – Yakov Galka Aug 04 '21 at 02:51
  • Graphics APIs are *very* specific about [rasterization](https://en.wikipedia.org/wiki/Rasterisation#Triangle_rasterization) conventions. You need to check that the vertices have exactly the same initial values, and are going through the exactly same transforms. Without any code, I can only make guesses though. – Brett Hale Aug 04 '21 at 05:19
  • 1
    is this your own/custom rasterizer ? this happens when you do not sort the the line end points in specific order while rasterizing. So `line(A,B)` produce different pixels then `line(B,A)` creating these gaps. Other cause is different rounding of float coordinates for each primitive. In such case is better to have table of points convert them and use them as indices instead of have copies of points for each primitive... – Spektre Aug 04 '21 at 07:12
  • Thank you Spektre, when I reversed the line direction it worked. Of course, that's a problem for me with culling, but I'm working on an alternate solution. I just needed to know what I was dealing with. – KiraHoneybee Aug 05 '21 at 00:10
  • @KiraHoneybee if you have access to the rasterizer then there should be function that rasterizes line into [left/right buffers](https://stackoverflow.com/a/19078088/2521214) in there sort the endpoints by x coordinate ... so simply swap the endpoitns `if (x0>x1)` but only after you decide to which buffer the line will be rasterized. Btw. without this fix the holes will detect places in mesh where winding rule does not strictly match between touching faces of BR mesh – Spektre Aug 05 '21 at 07:24
  • Voting for reopen as the cause is already identified and its a common problem not mentioned in most (or any I saw) tutorials on rasterization usually remedied by dirty/slow hacks like enlarging faces and or producing multi pixel width boundary lines instead of simple remedy of the real cause. And I think this deserves an QA in here on SO – Spektre Aug 05 '21 at 07:28
  • 1
    @Spektre: the question needs to be edited then to be clear that it asks about **implementing** a rasterizer, and OpenGL tag be removed. As it stands it asks about a problem in a renderer, presumably using some common OpenGL implementation, without providing any code to reproduce the problem. At the same time OpenGL is very clear about primitives sharing an edge generating each fragment exactly once. – Yakov Galka Aug 05 '21 at 20:08

0 Answers0