Provide ability to draw anti-aliased lines in OpenGL #204
Labels
Comments
|
aashish24
modified the milestones:
Version 2.0 - Long term milestone,
Version 1.0 - Near term milestone
manthey
added a commit
that referenced
this issue
Nov 21, 2016
This resolves issues #204 and #596. Previously, lines were not rendered correctly for several conditions: (a) miter locations were sometimes miscalculated, resulting in inconsistent line widths. (b) when the miter limit was exceeded, an attempt to prevevnt an excessively long line produced skewed segments. (c) On the inside of acute angles on short line segments, some of the triangles used to render lines were twisted. (d) when lines overlap, the overlap was inconsistent. All of this has been fixed. Additionally, we know support: - line caps: butt (default and what was avaulable before), round, square. These can vary by point. - line joins: miter (default), round, bevel, miter-clip. These can vary by point. Miter and miter-clip have a configurable miter limit (one value for the whol feature) which, if the miter would be longer than this, switches to using a bevel or a clipped miter. - antialiasing on edges and end caps. This can be specified for the whole feature. - strokeOffset: This can vary from -1 (shift left) to 1 (shift right), where 0 is the line centered on the vertices, and 1 is with the edge of the line on the vertices. All of this is done by rendering two triangles per line segment and performing much of the computation in the vertex and fragment shaders. There are a few limitations to the current implementation: - there is finite precision in the calculations, resulting in occasional artifacts along miter joins. These are mostly only noticeable on very wide lines using stroke offsets, and, even then, are subtle. - When the line width changes per vertex, sometimes the inside joins are not technically correct. Instead of using the angle of the lines meeting, the angle of the edges of the lines meeting would need to be calculated. - On short line segments, one edge of the miter can be by itself, which would ideally either be antialiased or wouldn't be trimmed. Currently, on wide short lines with multiple segments, the mitered edge can look blocky in limited instances. This method uses 18/15 as much memory as lines used before. There is a debug flag to show all of the pixels sent to the fragment shader. If debug is not specified when the feature is created, the debug code is not even compiled into the fragment shader. There could be some efficiency improvements in the shaders. For instance, it might worth it to have a quick test for simple line segments without joins. The new features and changes are exposed in one of the selenium tests (test/selenium/glLines/?wide=true), which can take a variety of query options, such as strokeOffset, lineCap, lineJoin, miterLimit, antialiasing, strokeWidth, strokeColor, strokeOpacity, and debug. This should be turned into an example that also tests number of lines.
manthey
added a commit
that referenced
this issue
Nov 21, 2016
This resolves issues #204 and #596. Previously, lines were not rendered correctly for several conditions: (a) miter locations were sometimes miscalculated, resulting in inconsistent line widths. (b) when the miter limit was exceeded, an attempt to prevent an excessively long line produced skewed segments. (c) On the inside of acute angles on short line segments, some of the triangles used to render lines were twisted. (d) when lines overlap, the overlap was inconsistent. All of this has been fixed. Additionally, we now support: - line caps: butt (default and what was avaulable before), round, square. These can vary by point. - line joins: miter (default), round, bevel, miter-clip. These can vary by point. Miter and miter-clip have a configurable miter limit (one value for the whole feature) which, if the miter would be longer than this, switches to using a bevel or a clipped miter. - antialiasing on edges and end caps. This can be specified for the whole feature. - strokeOffset: This can vary from -1 (shift left) to 1 (shift right), where 0 is the line centered on the vertices, and 1 is with the edge of the line on the vertices. All of this is done by rendering two triangles per line segment and performing much of the computation in the vertex and fragment shaders. There are a few limitations to the current implementation: - there is finite precision in the calculations, resulting in occasional artifacts along miter joins. These are mostly only noticeable on very wide lines using stroke offsets, and, even then, are subtle. - When the line width changes per vertex, sometimes the inside joins are not technically correct. Instead of using the angle of the lines meeting, the angle of the edges of the lines meeting would need to be calculated. - On short line segments, one edge of the miter can be by itself, which would ideally either be antialiased or wouldn't be trimmed. Currently, on wide short lines with multiple segments, the mitered edge can look blocky in limited instances. This method uses 18/15 as much memory as lines used before. There is a debug flag to show all of the pixels sent to the fragment shader. If debug is not specified when the feature is created, the debug code is not even compiled into the fragment shader. There could be some efficiency improvements in the shaders. For instance, it might worth it to have a quick test for simple line segments without joins. The new features and changes are exposed in one of the selenium tests (test/selenium/glLines/?wide=true), which can take a variety of query options, such as strokeOffset, lineCap, lineJoin, miterLimit, antialiasing, strokeWidth, strokeColor, strokeOpacity, and debug. This should be turned into an example that also tests number of lines.
manthey
added a commit
that referenced
this issue
Nov 21, 2016
This resolves issues #204 and #596. Previously, lines were not rendered correctly for several conditions: (a) miter locations were sometimes miscalculated, resulting in inconsistent line widths. (b) when the miter limit was exceeded, an attempt to prevent an excessively long line produced skewed segments. (c) On the inside of acute angles on short line segments, some of the triangles used to render lines were twisted. (d) when lines overlap, the overlap was inconsistent. All of this has been fixed. Additionally, we now support: - line caps: butt (default and what was avaulable before), round, square. These can vary by point. - line joins: miter (default), round, bevel, miter-clip. These can vary by point. Miter and miter-clip have a configurable miter limit (one value for the whole feature) which, if the miter would be longer than this, switches to using a bevel or a clipped miter. - antialiasing on edges and end caps. This can be specified for the whole feature. - strokeOffset: This can vary from -1 (shift left) to 1 (shift right), where 0 is the line centered on the vertices, and 1 is with the edge of the line on the vertices. All of this is done by rendering two triangles per line segment and performing much of the computation in the vertex and fragment shaders. There are a few limitations to the current implementation: - there is finite precision in the calculations, resulting in occasional artifacts along miter joins. These are mostly only noticeable on very wide lines using stroke offsets, and, even then, are subtle. - When the line width changes per vertex, sometimes the inside joins are not technically correct. Instead of using the angle of the lines meeting, the angle of the edges of the lines meeting would need to be calculated. - On short line segments, one edge of the miter can be by itself, which would ideally either be antialiased or wouldn't be trimmed. Currently, on wide short lines with multiple segments, the mitered edge can look blocky in limited instances. - When a line segment has zero length in screen space, it is not drawn at all. Adjacent line segments may not be drawn exactly as expected. Also, if line caps are used, perhaps zero-length segments should still be visible. This method uses 18/15 as much memory as lines used before. There is a debug flag to show all of the pixels sent to the fragment shader. If debug is not specified when the feature is created, the debug code is not even compiled into the fragment shader. There could be some efficiency improvements in the shaders. For instance, it might worth it to have a quick test for simple line segments without joins. The new features and changes are exposed in one of the selenium tests (test/selenium/glLines/?wide=true), which can take a variety of query options, such as strokeOffset, lineCap, lineJoin, miterLimit, antialiasing, strokeWidth, strokeColor, strokeOpacity, and debug. This should be turned into an example that also tests number of lines.
|
Added by PR #649. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
No description provided.
The text was updated successfully, but these errors were encountered: