Hi ??, Any change you could provide at least a first name?
W.r.t Nurbs implementation, I would either write a custom Node that manages a the source data that defines the NURBS and a subgraph containing the scene graph representation of it, or write a custom Drawable leaf that implements the OpenGL rendering itself. You might even go for a combination of these, both a high level node and a lower level drawable for rendering patches of an overall NURBS assembly. Use of GLU would favour the lower level drawable, as done in the osgteapot example. As you have found out osg::Shape is not meant to be extended in the way you were thinking, its role is just for geometric primitive definition as used by collision detection and physics engines. W.r.t number triangles per geometry/drawable, modern graphics hardware favours quite large blocks of data, thousands or tens of thousands of triangles per geometry is perfectly reasonable. You can still get reasonable performance with millions of triangles, but generally dividing it up smaller chunks is better for performance. Personally I'd do NURBS in shaders now, just start with a regular mesh and compute the vertex positions down on the GPU via a vertex shader. Robert. On Wed, Mar 12, 2008 at 9:17 PM, Night Hawk <[EMAIL PROTECTED]> wrote: > Hello all, > > I am working on few NURBS classes and would like to know design > guidelines to make them work effectively with rest of OSG. As a start > one simple renderer class (based on GLU) and two tesselator classes > are on the plate. After reviewing many comments in various articles > and forums, it seems converting the surfaces to polygons and rendering > them is more practical than trying to evaluate them directly. One > tesselator class to divide the surface into uniform triangles and > another class to sub-divide based on "curvature" - both are producing > a list of triangles from a NURBS surface. > > Now I am looking for how to supply this triangle geometry to OSG > effectively. I saw the shape classes (such as sphere) and thought I > could make NURBS as one more shape derived class, but the > shapedrawable class is closed (in the sense it is using > ComputeBoundShapeVisitor that is "fixed" for few known types) and not > sure if we can extend it (without modifying it). Also the comments in > the code say that shape is not a peformance oriented class. > > So how do we host these triangles that we generate from the surface? > If we use DrawElements classes to host these list of triangle, will > OSG be able to cull them ? Because all that we will be supplying to > DrawElements is a big vector of points and I am not sure if OSG will > be able to figure out the bounds that can be culled effectively from > that linear vector. (I am of the impression that to for an effective > elimination of nodes there should be some kind of parent-child > relationship and not just a linear triangle list. Is that correct?) > > Or is there a better class that we need to derive from implement its > methods? Would it do good to group a every 100 or 200 triangles into a > geode so that OSG can traverse quickly to eliminate any geodes that > fall out of view. > > Also I read in old posts here that shader support is good for > surfaces. If we supply the triangles to the OSG that would > automatically make them as shader compatible (since they will be > having vertices that can be processed) - or do we need to add any > extra explicit support? > > Looking for any guidelines on how to progress. > > Thank you for your time and effort. > _______________________________________________ > osg-users mailing list > [email protected] > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org > _______________________________________________ osg-users mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
