Re: [osg-users] Chicken Egg Problem: BoundingBoxes
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
Re: [osg-users] Chicken Egg Problem: BoundingBoxes
On Mon, 2012-08-27 at 16:50 +0100, Robert Osfield wrote: 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 This isn't currently possible because of the dirtyBound() prototypes on Drawable and Node (they are not const). However, if this is an API change you'd be agreeable to, I'd be happy to submit it. :) 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 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Chicken Egg Problem: BoundingBoxes
Hi Jeremy, On 27 August 2012 17:21, Jeremy Moles cubic...@gmail.com wrote: This isn't currently possible because of the dirtyBound() prototypes on Drawable and Node (they are not const). However, if this is an API change you'd be agreeable to, I'd be happy to submit it. :) As you have a subclass from Drawable you should be able to set the dirty flag directly. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Chicken Egg Problem: BoundingBoxes
On Mon, 2012-08-27 at 17:30 +0100, Robert Osfield wrote: Hi Jeremy, On 27 August 2012 17:21, Jeremy Moles cubic...@gmail.com wrote: This isn't currently possible because of the dirtyBound() prototypes on Drawable and Node (they are not const). However, if this is an API change you'd be agreeable to, I'd be happy to submit it. :) As you have a subclass from Drawable you should be able to set the dirty flag directly. You can (and in fact you have to!), but it won't set the dirty flags of the parent Geode, so you're forced to call dirtyBound() on it as well. This can be tough to do because you need to be sure it has already compiled the Paths, which is why I made the initial post. Robert. ___ 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
Re: [osg-users] Chicken Egg Problem: BoundingBoxes
Hi Jeremy, On 27 August 2012 17:34, Jeremy Moles cubic...@gmail.com wrote: You can (and in fact you have to!), but it won't set the dirty flags of the parent Geode, so you're forced to call dirtyBound() on it as well. This can be tough to do because you need to be sure it has already compiled the Paths, which is why I made the initial post. Interesting issue... The thing to be careful about allow a const dirtyBound() is that it opens the door to multi-threading issues where multiple threads could call dirty at one time - for instance from multiple cull traversals all running at the same time. There is also the problem that calling dirtyBound() would force a computeBound() on the next getBound() call which again could present a multi-threading issue where multiple threads could potentially be reading and writing from the data structures. Now... if the drawable can only be managed from a single context or from a single cull thread at one time then this multi-threading issue wouldn't be an issue, but it's a restriction that is very domain specific. Rather than relax the core OSG for a niche case might the better solution just to cast away constness from your subclass with a note that it should just be used on single thread cull. There might be a better solution down the line but for now this is route I'd prefer to take. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Chicken Egg Problem: BoundingBoxes
On Mon, 2012-08-27 at 21:04 +0100, Robert Osfield wrote: Hi Jeremy, On 27 August 2012 17:34, Jeremy Moles cubic...@gmail.com wrote: You can (and in fact you have to!), but it won't set the dirty flags of the parent Geode, so you're forced to call dirtyBound() on it as well. This can be tough to do because you need to be sure it has already compiled the Paths, which is why I made the initial post. Interesting issue... The thing to be careful about allow a const dirtyBound() is that it opens the door to multi-threading issues where multiple threads could call dirty at one time - for instance from multiple cull traversals all running at the same time. There is also the problem that calling dirtyBound() would force a computeBound() on the next getBound() call which again could present a multi-threading issue where multiple threads could potentially be reading and writing from the data structures. Now... if the drawable can only be managed from a single context or from a single cull thread at one time then this multi-threading issue wouldn't be an issue, but it's a restriction that is very domain specific. Rather than relax the core OSG for a niche case might the better solution just to cast away constness from your subclass with a note that it should just be used on single thread cull. There might be a better solution down the line but for now this is route I'd prefer to take. I find myself 100% in agreement and shall proceed thusly! :) Robert. ___ 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
