blob: 9be8f90b1f30fe01603945bc2ad5f5e110a0370f [file] [log] [blame]
Name Strings
Mark Kilgard, NVIDIA (mjk 'at'
Jeff Bolz, NVIDIA (jbolz 'at'
Michael Chock, NVIDIA (mchock 'at'
Last Modified Date: March 27, 2015
Version: 2
OpenGL Extension #471
OpenGL ES Extension #234
This extension is written against the OpenGL 4.3 (Compatibility)
Specification but can apply to OpenGL 1.1 and OpenGL ES 2.0 and up.
This extension requires NV_path_rendering.
This extension introduces a new path command modifier to the
NV_path_rendering extension to indicate that a path command represents an
edge (either straight or curved) that is shared with another path.
When used in conjunction with NV_framebuffer_mixed_samples, a shared edge
(or a whole path including shared edges) will use modified rasterization
rules in order to ensure that groups of raster samples associated with a
given coverage sample will all produce consistent coverage results, in
order to avoid artifacts described further in the issues section at the
end of this document.
New Procedures and Functions
New Tokens
Allowed to be added to command tokens in elements of the <commands>
array parameter of PathCommandsNV and PathSubCommandsNV:
Modify Section 5.X "Path Rendering" from the NV_path_rendering extension:
Add to the end of Section 5.X.1 (Path Specification)
When the value of SHARED_EDGE_NV is bitwise exclusive-ORed with any of the
path command tokens in Table 5.pathCommands (but not the character
aliases), the path outline generated by this path command is considered a
"shared" version of the original command. When such paths are stenciled
(see section 5.X.2.1), coverage for groups of raster samples corresponding
to the same color sample must be produce the same result (i.e. must all be
covered or all be uncovered) with respect to this particular path command's
contour edge. Depending on the implementation, this modified coverage
determination may be applied to all edges in a path if that path contains
any shared edges. When such paths are covered, groups of raster samples
may also be treated the same way (i.e. altering properties of some samples
in order to produce the same coverage for all samples in the group).
Additions to the AGL/GLX/WGL Specifications
Additions to the OpenGL Shading Language
GLX Protocol
1. What is the GL_SHARED_EDGE_NV value for?
RESOLVED: Path rendering sometimes requires subregions of two
paths to be drawn such that they are "watertight". This means
that the color samples along this shared contour should not have
any coverage gaps or double hits.
The problem with mixed sample frequencies is that fractional
coverage is computed as a result of the stencil test. A color
sample might be 25% covered by one path command edge of path X
and then 75% covered by the identical path command edge of path
Y such that path X covers the "righthand" side of the color
sample and path Y covers the "lefthand" side of the color sample.
Such situations can cause an artifact known as "conflation"
that allows a background color to "leak through" the edge when
the edge is intended by the content creator (often an artist or
perhaps a path preprocessing tools) to allow no such leakage.
Consider the watertight edge when the background color is RED
(1,0,0,1), path X's color is GREEN (0,1,0,1), and path Y's
color is BLUE (0,0,1,1). If we draw path X first, we get 25%
GREEN and 75% RED (the background color) composited into the
framebuffer assuming a GL_ONE,GL_ONE_MINUS_SRC_ALPHA blend mode
with the GL_RGBA coverage modulation mode. The result is
(0.75,0.25,0.0,1.0). Now if we draw path Y first, we get
75% BLUE and 25% of (0.75,0.25,0.0,1.0). This result is
However the arguably "correct" watertight result is
(0,0.25,0.75,1). The problem is if we process path X and path Y
in separate passes, we risk "blending" in some of the background
color. The source of this artifact is the assumption that we
can translate boolean per-sample coverage into a "fractional"
coverage value.
Note that this situation occurs even when the paths being rendered
(X and Y in this example) are 100% opaque.
At the cost of losing some sub-color sample coverage determination
accuracy, we can avoid this artifact by marking as a "shared
edge" path commands that are intended to be watertight with
edges of the identical path command in another path object.
When such commands are encountered, coverage computations done
by NV_path_rendering can be careful to decide the coverage of
secondary samples with respect to this path edge identically to
their respective primary sample. This ensures the coverage (at
least with respect to this particular edge) is either 0% or 100%.
Note that unshared edges from path commands not marked as shared
by the addition of the GL_SHARED_EDGE_NV value are processed
at the effective raster sample rate. This ensures that edges of
the path retain a high level of antialiasing quality.
This capability is most interesting to path rendering standards
such as Flash.
2. Should the GL_SHARED_EDGE_NV value be bit that can be bitwise
ORed into a path command?
RESOLVED: No. Instead the GL_SHADED_EDGE_NV value of 0xC0
(192) should be exclusive-ORed (^) to construct path commands
with a shared edge.
Rationale: The NV_path_rendering assignment of 8-bit token
values is arranged to match OpenVG for commands OpenVG supports
and numbers the non-OpenVG commands downward from 255 so there is
not a bit value to bitwise OR (or even add) that guarantees
unique values, particularly considering the character alias values
(such as 'C' for GL_CUBIC_CURVE_TO_NV).
Bitwise exclusive-ORing with 0xC0 does provide unique values
for all current (and expected future) path command tokens.
3. The SVG and PostScript path string grammars don't have a way to
express shared edges. Is this a problem?
RESOLVED: No. We support these grammars "as is" from SVG and
PostScript. These standards don't really have a way to convey
shared edges in paths as Flash shapes allow.
4. What does GL_MOVE_TO_NV^GL_SHARED_EDGE_NV mean?
RESOLVED: Bitwise exclusive-ORing GL_SHARED_EDGE_NV works for
any legal path token.
because the GL_MOVE_TO_NV don't really generate an edge (and
likewise for its variant GL_RELATIVE_MOVE_TO_NV).
Yes, it is legal.
5. What about 'C'+GL_SHARED_EDGE_NV? Are these allowed?
Character aliases don't support the bitwise exclusive-ORing of
GL_SHARED_EDGE_NV. This is to reduce the risk of collisions
with character aliases and future path commands.
Revision History
Revision 2, 2015/03/27
- Add ES interactions
Revision 1
- Internal revisions.