GPU-accelerated path rendering

[YarUnderoaker]

I'm trying to port nvpr_font_file demo to Pascal. All works fine, except

  glPathParameteriNV(pathTemplate, GL_PATH_STROKE_WIDTH_NV, 50);
  glPathParameteriNV(pathTemplate, GL_PATH_JOIN_STYLE_NV, GL_ROUND_NV);

both command cause GL_INVALID_OPERATION.
In this time I can't check, but may be is this due to lack of library freetype6.dll in project folder? How it interact with application?

[ScottManDeath]

It seems that the extension ignores geometry and vertex shaders, so now I'm wondering how one would do e.g. (geometry shader) instancing to replicate a path into multiple layers of a 2D texture array without having to render it N times and bind each individual layer to make it work and changing e.g. the modelview matrix for each pass. With triangles one would use GS instancing ...

However, using gl_ViewportIndex for the ARB_viewport_array extension requires a GS in order to route stuff into the different viewports, which can be handy when e.g. rendering into 2x2 subdivided viewport. So how would I be able to render paths into each viewport without having to render them 4 times?

[Gedolo]

Fonts are (in a more limited way) already possible.
http://code.google.com/p/freetype-gl/

The little library that uses shaders and other basic building blocks does speak to me as a good solution. Doing this for paths would not create problems if licence of the font library is free enough.

Also I don't understand why paths aren't geometry?

Aren't vertices also kinda like paths?

I see why not using the tesselation pipeline but not why the path stuff couldn't be integrated into geometry shader.
That will probably ask a new generation of hardware.

[YarUnderoaker]

both command cause GL_INVALID_OPERATION.

I added GL.PathCommandsNV(pathTemplate, 0, nil, 0, GL_FLOAT, nil) before and error is disappeared.
I guess, in SDK demo this line must be too, because after I added it, stroke width start look better.

[Mark Kilgard]

Also I don't understand why paths aren't geometry?

Very good question. Paths are a well-developed concept in resolution-independent 2D graphics. PostScript, PDF, SVG, Flash, TrueType, Quartz 2D, Cairo, Skia, XPS, etc. all have the concept. It helps to understand what a path is.

If you are super-familiar with OpenGL, but haven't really been exposed to path rendering, it's really easy to think "everything is just triangles, right?" and really miss what makes path rendering standards distinct. Start by divorcing the notion of a path from concept of a geometry batch (commonly, a bunch of triangles, often in a mesh, as in standard OpenGL).

Paths really are a sequence of path commands. Examples of path commands are MoveTo, LineTo, QuadraticBezierCurveTo, ArcTo, ClosePath, etc. The palette of available commands varies by path rendering standard, but they all have some command commands. All at least have MoveTo, LineTo, and QuadraticBezierCurveTo.

There are plenty of 2D authoring tools that let you author path content. Adobe Illustrator and Inkscape are the two best known.

A path consists of zero or more trajectories. A trajectory is nothing more than a connected sequence of 2D segments (potentially curved) that are connected to each other. You might also call this a spline. Each trajectory or spline can be closed (meaning the start point of the trajectory is the same as the end point) or open (meaning the start and end points are distinct). A closed trajectory or spline is often called a contour. Math types might call a contour a 1-dimensional manifold.

Once you have this basic notion of a path, you are ready to render a path. That can be done by either filling or stroking the path after its has been transformed from path space to window/device space.

Filling a path is like the idea of "coloring between the lines" in a coloring book. When a path is not closed, it is "forced" to be closed by a line segment connecting the start and end point. But that analogy only goes so far because paths can self-intersect each other and a single path might contain multiple contours. As you'll see, it also potentially matters whether the path winds clockwise or counter-clockwise. This makes it necessary to determine in a rigorous way whether a point in space is "inside" or "outside" the fill of a path. You do this by computing the winding number of a point in the 2D plane with respect to the path. You count how many times the path winds around the point. Another way of doing this is casting a ray in an arbitrary direction to infinity and counting the net number of times a ray cross the path where counter-clockwise crossings are counted as positive (+1) crossings and clockwise crossings are counted as negative (-1) crossings. (These two interpretations are identical mathematically.) If the number of crossings is non-zero for a point with respect to a path, the point is within the path. Otherwise, the point is outside. Alternative rules exist as well. The other common rule is the even-odd rule where you are inside if the winding number of a point w.r.t. the path is even (and outside if odd). Other rules might ask if the winding number modulo some power of 2 is non-zero; in this sense, the even-odd rule is simply a "modulo 2" rule.

Notice that filling is a "global" operation. You can't just look at a subsequence of path commands in a path and be able to determine whether a point is inside the filled region of a path or not. Because some sequence you are not considering could "cancel" or "add" the point back into the filled region of the path. You've got to consider the whole path to make an accurate determination of what's inside and outside the path.

Stroking a path is quite different from filling a path. Instead of computing the winding number of a path, the analogy is taking a pen (like a calligraphy pen) and pulling it over the path (raising it off the paper when MoveTo commands are encountered and lowering the pen at the new location) such that the pen's tip is always orthogonal on the path and centered on the path. Essentially you are "stroking" out a region of 2D path that is within the stroke of the path.

There are a lot of (important) embellishments to stroking involving stroke width, end caps, join styles, dash patterns, and dash caps that complicate what it means to be "inside" the stroke of a path. While I'll only mention these stroking embellishments in passing, they are important to most major path rendering standards. For this reason, NV_path_rendering fully supports them.

Notice there's no concept of points/lines/polygons (the familiar geometric primitives in 3D rendering). Indeed, the boundaries of paths are actually defined by (parametric sub-regions) of polynomial curves (rational polynomial curves in the case of partial elliptical arcs). This is *way* different from 3D graphics where every primitives edge is "just" a line segment.

The implications of the higher-order nature (in the polynomial sense) of stroked or filled path boundaries are substantial. With filling, two path commands, each specifying a cubic Bezier segment, might intersect. That's the intersection of two 3rd order curves. Just determining where these two curves might intersect would require solving a 6th order (3+3) equation. In the case of a stroked path, the boundary of a stroked path of a cubic Bezier segment is specified by a 10th(!) order curve.

I hope this helps explain why paths aren't simply "geometry" in the simple sense supported by 3D APIs.

None of what I'm saying is unique to NV_path_rendering. All path rendering standards deal with these issues and practicalities. This complexity is one of the reasons GPUs have not accelerated path rendering particularly effectively. NV_path_rendering seeks to change that.

Aren't vertices also kinda like paths?

Another good question, but, no, vertices are really NOT kinda like paths. Paths are typically defined by control points associated with the path's command sequence. Each control point is defined by two path coordinates. Each control point may specify an absolute 2D position (x,y) or a relative 2D position (dx,dy) that is relative to the end point of the prior path command in the path's command sequence. Some path commands use path coordinates for purposes other than specifying 2D control points. Commands to specify partial elliptical arcs specify flags, radii, or angles as path coordinates. The SVG partial elliptical arc command is an example of such a path command.

Even if you discount the non-control point path coordinates used for partial elliptical arc parameterizations, you'd be naive to confuse a vertex with a control point. Whereas vertexes are boundary points on a geometric primitive, a control point might not actually even be on the path. For example, the quadratic Bezier segment command in path rendering specifies two control points. The first is an extrapolating control point NOT part of the path segment's curve.

A path is really a convenient way for artists to specify a region within 2D planar space. Paths are NOT just a mesh of triangles. Paths are resolution-independent. Paths have higher-order boundary representations. Paths can be self-intersecting and have multiple disjoint pieces and holes. A path can be unbounded in the number of path commands (and corresponding path coordinates) that make up a path.

As great as vertex shaders and geometry shaders are for 3D geometry specified as batches of points/lines/triangles, paths just aren't that sort of animal.

I see why not using the tessellation pipeline but not why the path stuff couldn't be integrated into geometry shader.

Geometry shaders operate on geometric primitives constructed from a fixed number of vertexes and operate by emitting vertexes that are likewise constructed into similar geometric primitives.

Paths aren't triangles and don't have vertexes so paths can't be feed to a geometry shader. Likewise for vertex shaders.

Perhaps it is worth saying that NV_path_rendering (as with pretty much all path rendering implementations) do NOT operate by breaking paths into triangles and then rasterizing the resulting triangles. Doing so isn't efficient because tessellation is a fragile (in the sense that it must be done very carefully in terms of numerical operations), sequential, and ill-suited for the curved and resolution-independent boundaries of paths. Most path rendering implementations operate through scan-line rasterization. NV_path_rendering is a bit different because it harnesses the massively parallel and pipelined nature of CUDA-capable GPUs to directly evaluate the stroking and filling determinations for transformed paths.

- Mark

[Mark Kilgard]

both command cause GL_INVALID_OPERATION.

I added GL.PathCommandsNV(pathTemplate, 0, nil, 0, GL_FLOAT, nil) before and error is disappeared.
I guess, in SDK demo this line must be too, because after I added it, stroke width start look better.

Thanks for the bug report. Yep, the pathTemplate object wasn't being created first so you couldn't set parameters on it. The fix is exactly what you describe.

Here's a suggested C code fix, similar to what you found worked:

  /* Use the path object at the end of the range as a template. */
  pathTemplate = glyphBase+numChars;
  glPathCommandsNV(pathTemplate, 0, NULL, 0, GL_FLOAT, NULL);

Yes, with this fixed, you actually get to see the stroking.

Expect this to be fixed with the next NVprSDK.zip update.

Thanks again. Otherwise, have you found the simpler NVprSDK demos port to Pascal pretty cleanly? Probably nvpr_svg is too much work because of the extensive C++, but many of the others should be simple enough to translate.

- Mark

[YarUnderoaker]

have you found the simpler NVprSDK demos port to Pascal pretty cleanly?

Yes, everything is clear and simple. I have low skill of using Visual Studio, but I could easily compile examples.
Thank you very much for this great extension.

[elFarto]

Hi Mark

Thank you for this extension.

Have any of the other Khronos members expressed interest in moving this extension to EXT or ARB status? Could this extension be implemented on (for example) AMD's hardware, or does it require some specific piece of functionality only found on NVIDIA's GPU?

Thanks & Regards
elFarto

[Mark Kilgard]

elFarto,

> does it require some specific piece of functionality only found on NVIDIA's GPU?

Yes, NV_path_rendering requires your GPU to be CUDA-capable.

- Mark

[Gedolo]

Make it so it does NOT require compatibility.
Seriously, make sure it only requires core!!!