On Wed, 2011-08-24 at 06:43 +0200, Mark Kilgard wrote: > Jeremy, > > Very cool to see this OpenSceneGraph support for NV_path_rendering.
And even cooler to get an @nvidia.com response. :) > I hope you'll explore the ability to mix 3D and path rendering within a > depth-buffered perspective scene as discussed in the "Mixing Path Rendering > and 3D" whitepaper. > > Any CUDA-capable NVIDIA GPU under Windows or Linux can use NV_path_rendering > with Release 275 drivers or later. > > A few suggestions for your osgNVPR::Path object: > > * Consider having the "_colors" be a path "paint" object. Solid color (what > you have now) is one paint style, but linear gradient color, radial gradient > color, and image paint are others common to path rendering standards. (See > the nvpr_svg SDK example to see how simple the shaders are for linear and > radial gradients.) > > * Eventually you could have "paint" shaders where you can use arbitrary > assembly, Cg, or GLSL shaders to paint your paths during the cover operation. > Environment mapped or bump mapped paths are possibilities. > > * Have separate fill and stroke paint. Sometimes you want the stroking to > happen "before" the filling (such as for matting text rendering) but usually > the stroking is an outline around the path drawn over the filled version of > the path. Have an option for either. "null" paint would skip the filling or > stroking. > > * Have methods to set stroking styles (end caps, join style, dash pattern, > dash caps, and stroke width). > > * Be able to initialize a path from an actual string of text and a font name > (and font style). This way someone can create a osgNVPR::Path for "Hello > world" in Arial or whatever. > > * Have a mode to say whether mixing with depth testing should be done. > > * Provide an option to "cache" the drawing commands for a path object in a > display list. All the NV_path_rendering commands are display-listable. > Because the NVIDIA OpenGL driver is dual-core enabled, this allows you to > draw a path with a single glCallList command relayed over to the driver > thread on another core. This gives your app thread more CPU cycles. > > * You should be able to support "picking" support with the > glIsPointInFillPathNV and glIsPointInStrokePathNV queries. Since you have > the bounding box queried already, it makes sense to test against the bounding > box first before doing the (more expensive) glIsPointInFillPathNV query. > > I look forward to seeing how this develops. Really good suggestions, all stuff I'd like to do... Unfortunately, I did most of what is currently in osgNVPR over a weekend in a attempt to see if there was any interest in funding for such a NodeKit in OSG. As of yet, there has been none, so development will be on hold (for now). > - Mark > > ------------------ > Read this topic online here: > http://forum.openscenegraph.org/viewtopic.php?p=42207#42207 > > > > > > _______________________________________________ > osg-users mailing list > osg-users@lists.openscenegraph.org > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org > _______________________________________________ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
