Triangle side is not straight line

I have application to draw thick lines. It is drawn using triangles. The problem is one side of triangle is not straight. This is the image showing the drawn picture:

[ATTACH=CONFIG]727[/ATTACH]

These are the vertices:
x 0.5
y 0.8500000238

x 0.5
y 0.150000006

x -0.1499999762
y 0.150000006

x -0.5
y 0.8500000238

x -0.8500000238
y 0.8500000238

x -0.8500000238
y 0.5 float

x -0.8500000238
y 0.5

x -0.1499999762
y 0.150000006

x -0.8500000238
y 0

x -0.150000006
y 0

And the indices: 0, 1, 2, 0, 2, 3, 4, 3, 2, 4, 2, 5, 8, 7, 9, 8, 7, 6

This does not happen only with these vertices, but also if I draw it with other vertices. I have no idea why since the y coordinate does not change.

Did you tried to shake your monitor? Unless those specific numbers are cursed by an evil wizard, the information given is insufficient to find the problem. Reveal the mystery of your drawing algorithm, otherwise “I have no idea why since the y coordinate does not change”.

These are the final points produced by the algorithm. Those are sent to GPU and drawn…

Yandersen’s dark and hilarious Canadian humor aside, we need more information to help you (shader program if applicable, the actual draw calls, VBOs, and projection/camera/modelview matrices, etc.). Are you drawing anything else?

Yeah, sry! :slight_smile:
[b]MirzaSe[/b], if those numbers are going directly to gl_Position without being multiplied by any matrices, then the vertical lines should be straight. But I believe you use some modelview or projection transformations, and there is the point where calculation errors come from.

Even if you compose your modelview matrix by 90 degree rotation and check it, the numbers in it will not be straight 1.0 and 0.0. Therefore the 90 degree rotations are better to do manually placing 1.0, -1.0 and 0.0 in proper locations of the matrix. If you are doing any other degrees of rotations (especially nesting those) - forget about straight lines. Recalculate the modelview matrix on CPU without nesting transformations (use angles as source arguments producing matrix as result; handle 90, 180, 270 rotations as exceptions to bypass deg-rad conversions and sin-cos calculations as those will introduce calculation errors).

Thank you, you saved my life :slight_smile: It was problem with translation …