Path rendering

NV Path Rendering | NVIDIA Developer Zone:

Talks about 2d vector drawing in their words path rendering.

Being able to do 2d paths (and 3d too please, nvidia currently only talks about 2dn visible in the introduction presentation slide 4) would be a useful task to move from the cpu to gpu. Because it’s also graphical.

What is everybody’s opinions about this extension:
NV_path_rendering

(I would like them to allow 3d paths, 3D dimensionality, not just perspective or setting in a 3d environment)

You might check out the discussion on this other thread:

http://www.opengl.org/discussion_boards/ubbthreads.php?ubb=showflat&Number=300872#Post300872

(I would like them to allow 3d paths, 3D dimensionality, not just perspective or setting in a 3d environment)

It is easy enough using NV_path_rendering to restrict the transformations you apply to paths to an affine 3x2 matrix instead of the fully generality of a 4x4 matrix. Just zero the appropriate 4x4 matrix elements.

(The same thing could be said for conventional OpenGL; nothing forces you to render with a depth buffer or a 3D or projective matrix.)

I encourage you to try out the NVprDEMOs.zip (and look at the corresponding source code in NVprSDK.zip). You’ll find most of the demos constrain themselves to 3x2 affine transforms.

A few of the demos such as nvpr_warp_tiger and nvpr_tiger3d demonstrate 2D projective and 3D projective transformations of paths respectively; the others use conventional 3x2 affine transforms for simple 2D.

While you might not want projective, depth-tested rendering of paths, I think there are going to be a lot of developers that will really appreciate the ability to do things like add labels using TrueType fonts on the system and have this path rendered text mix seamlessly with their 3D objects.

  • Mark

I have a feeling that this extension does too much. I’d remove all the font processing. It is way too high level. It could be a layer on top of this extension. If anyone needs to render the text seriously then the API in this extension is simply not enough. Look at layout engines like Microsoft’s Uniscribe or IBM’s ICU. Handling complex scripts is way too complex to be part of OpenGL.

The same goes for high level command glPathStringNV. One API like glPathCommandsNV would be totally enough. NVIDIA can make a favor and release an opensource library that translate PS or SVG syntax to these low level commands.

In any case, thanks for this extension. It is very powerful. Promoting parts of this extension to core would be fantastic.

Take out the concept of fonts and it’s more difficult to do an end-run around OpenVG.

A glyph is a cached path in some form or other. So there is some synergy and you certainly don’t want to revert to paths for every glyph or string.

@Mark Kilgard

I’m trying to say that I want to also make 3d paths where the paths themselves are specified in 3d coordinates.

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.

@Everyone

I don’t see grouping paths.

I find some things should be unified in fewer more general, flexible, powerful and universal functions.

It would be really handy if Nvidia would make it independent from the file formats used. This way it could be used and adapted for everything.
The extension suppose to describe the very primitive/essence of paths. Not a whole bunch of decorations and constructions. Because you can make them out of the primitives anyway.
It wouldn’t be a good use of silicon to implement stuff this way.
It’s a but similar to the OpenGL fixed function pipeline.

You can always introduce format support libraries and sets of standard styles with an SDK that adds these more constructed stuff. Just as there are libraries for OpenGL.

This stuff is great but it needs to be improved.
There are a lot of generalizations possible that can reduce the amount of primitive functions while making them more flexible and powerful.

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. :slight_smile:

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.

  • Mark

@ Mark
Thanks

Didn’t instancing supposed to reduce the amount of memory used where possible by using one object as a reference for all the instances of that object used?

It doesn’t actually group any (random) path together the way I want or is there a way to use it like that?