I’m happy for the stuff that can be done but I do NOT want to be constrained to 3x2 matrices.
I want the full generality of a 4x4 matrix.
Be happy then. NV_path_rendering uses the standard 4x4 modelview and projection matrices only with the viewport/depth-range transform.
I encourage you to look at the nvpr_tiger3d example in the NVprSDK distribution. You’ll see use of fully general 4x4 matrices to render multiple instances of the classic PostScript tiger (the path rendering equivalent of the Utah teapot in 3D graphics) in a 3D scene that actually includes a Utah teapot.
The path objects in NV_path_rendering (same as paths in all other other path rendering standards) are two-dimensional entities, but NV_path_rendering objects (unlike any other path rendering standard of which I’m aware) can be transformed into 3D projective space and you can use the same Cg, GLSL, assembly or fixed-function fragment shading you use for 3D rendering to shade your paths. See Mixing Path Rendering and 3D whitepaper for details.
I’m trying to say that I want to also make 3d paths where the paths themselves are specified in 3d coordinates.
The path objects themselves are inherently planar objects. But once they are transformed by a 3D projective matrix, they become planar objects in 3D projective space. That means they can be depth tested against other projective 3D geometry.
Thinking about 3D paths where the path coordinates are themselves described with 3D control points is an interesting idea. I’ve not thought through the implications of that. It sounds pretty exciting.
For now, tools like Inkscape and Adobe Illustrator are 2D tools for authoring content and all the path rendering standards (SVG, PostScript, Flash, HTML Canvas, TrueType, etc) are likewise 2D so there’s a lot to figure out.
I don’t see grouping paths.
Check out the API for instanced stenciling and covering of paths. This is one way to group paths.
The other approach is using display lists. NV_path_rendering commands can be placed in a display list like most OpenGL commands. This allows you to create a display list that, say, draws the PostScript tiger as 240 paths in layered order.
The nvpr_tiger3d example mentioned earlier (as well as the nvpr_svg example) has the option to use display lists to “group” the rendering of paths. This is a great example of how making path rendering first-class functionality benefits from the existing structure provided by OpenGL.
NVIDIA’s OpenGL driver automatically takes advantages of CPUs with two or more cores to split up your application’s execution from the driver’s processing. This happens automatically. It’s particularly effective for display lists. The entire display list traversal happens on a second core so your application can continue working.
If you run the nvpr_svg example, try using the ‘0’ (zero) key to toggle use of display lists (or pick the “Toggle display lists” option from the right-click pop-up menu). If you have a multi-core CPU, you’ll find the rendering rate does improve when display lists are enabled exactly for this reason.