Hi Jeremy, The OSG uses a compile traversal that is called on the first frame of rendering (Renderer.cpp's Renderer::compile() method) and this will call your Drawable::compileGLObjects(), this can then set the dirty bound so that on the next cull traversal it'll update bounding box automatically for you. The other thing to do would be to estimate the bounding box based on the input parameters to your Drawable, or let the use define this or leave it up to the compile method.
Robert. On 27 August 2012 16:22, Jeremy Moles <cubic...@gmail.com> wrote: > Hello all! > > I'm working on a NodeKit (that is coming along nicely, btw) for using > the NVidia NV_path_rendering extension with OSG. This new extension has > an interesting--and, AFAIK, hitherto unseen--rendering model. > > When using NV_path_rendering (which I will call NVPR), one must feed > path coordinate data into the OpenGL driver and it will "compile" this > data for you into resources the graphics context identifies by number. > This work fairly well in OSG using the Drawable override of > compileGLObjects(), since I am given a valid and active graphics context > which I can use to build the renderable objects. > > (As a side node, for the uninitiated, a "path" in this context is a > N-order series of 2D coordinates that you use to draw vectors graphics; > for example, fonts. NVPR is an extension that uses your Cuda cores to > drastically speed this process up and create incredibly fast and > high-quality 2D graphics.) > > I mentioned earlier that compiling these objects and making them > available to OSG (even as displayLists) is straightforward. HOWEVER, > there is an issue with regards to properly informing OSG of the bounding > boxes of these objects, a kind of "chicken-and-egg" problem. :) > > Up until now, Drawable objects in OSG have had some kind of 3D geometric > data associated with them. This lets the object calculate the bounding > box on the CPU as the object is created, and inform the scenegraph > almost immediately what to expect with regards to its bounds. In NVPR, > we need the GPU to compute these bounds, but it cannot do so until AFTER > it has compiled the objects internally. This means it needs a valid > graphics context an should ideally do so towards the end of the > compileGLObjects method. As before, this is straightforward to execute, > but the order of operations here makes things tricky with OSG. > > Consider the following: > > osg::Geode* g = new osg::Geode(); > osgNVPR::Path* p = new osg::PathCommands(); > > p->doStuff(); > > g->addDrawable(p); > // DOH! OSG wants to do bounding calculations here, but we > // haven't yet compiled or calculated the path internally > // until compileGLObjects is called! > > I've come up with some workarounds, such as calling: > > viewer.realize(); > viewer.frame(); > > ...and then manually calling dirtyBound(), but these feels very wrong to > me. > > I wanted to quickly as the OSG community if they had any advice on how I > should best approach this problem. Drawble::dirtyBound() isn't a const > method, and so can't be easily called from compileGLObjects. > > Perhaps there may be some way to "pre-compile" these paths with a valid > rendering context shortly after creating the Viewer? > > At any rate, hope everyone has a great week! LABOR DAY EXTENDED WEEKEND! > > _______________________________________________ > 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
