Hi Robert Yes, I add an extra level of call but this is just to avoid code duplication so the most complexe function is call by the less complexe
PrimitiveSet::draw(State& state, bool useVertexBufferObjects, unsigned int numInstances) const is call by PrimitiveSet::draw(State& state, bool useVertexBufferObjects) const This part of code of OSG is there for a long time, and probably will never change so code duplication will probably not hurt futur maintainers. I work on SpeedTree integration, and I need to draw a forest in Multi-thread mode, with, for example, one view, two camera, two GraphicsContext, so with CullThreadPerCameraDrawThreadPerContext threading model. To do this, I need to call the same osg::PrimitiveSet::draw(...) function to draw a tree, in different thread. But camera 1 don't see the same number of tree that camera 2. So numInstance have to be adjusted by each camera. I could push a mutex in my drawable but this is always good to avoid mutex usage when we can. I could duplicate osg::PrimitiveSet but a simple forest with 20 differents trees have 30 Mo of indices. This is not a big deal for recent card but complexe forest can have 10 times more indices so 300Mo. I search a better approach to do this and I solve my probleme by extract numInstance from PrimitiveSet. I does some performance test and the extra level of call take less than 1 microsecond. David 2012/4/23 Robert Osfield <[email protected]> > Hi David, > > I've just reviewed your changes to PrimitiveSet and as things stand I > don't think it would be appropriate to merge them as it adds an extra > level of call nesting to all usage of PrimitiveSet when in normal > usage the number of instances will be 1 so not needed. Your approach > basically adds a call overhead for everyone to support a very niche > usage. > > I understand where you are coming from with this functionality and am > open to discussion about how you'd like to use the general feature of > primitive instancing. For instance if the number of instances > required is something that will vary independently from the primitive > data itself then decoupling the numInstances value complete from > osg::PrimitiveSet would be appropriate. This would add extra > complexity and breaking API's though so we'd want to really have to > justify this, avoiding data duplication is nice but it if it's only a > a few MB of data then it really is rather pointless. Could you > explain the actual usage model you have in mind that is problematic > with the existing code? Have you done benchmarking on it? > > Also any final solution if we do come up with one will have to be zero > cost for other users that don't have this niche need. > > Robert. > > On 17 April 2012 20:37, David Callu <[email protected]> wrote: > > Hi Robert, > > > > > > PrimitiveSet can use multiple instance but If I need to use the same > > PrimitiveSet with different number of instance, > > I have to duplicate the PrimitiveSet and potentially use many memory just > > for one integer. > > > > I submit a new function that allow user to specify how many instance to > draw > > on draw call. > > > > void osg::PrimitiveSet::draw(State& state, bool useVertexBufferObjects, > > unsigned int numInstances); > > > > > > Cheers > > David > > > > _______________________________________________ > > osg-submissions mailing list > > [email protected] > > > http://lists.openscenegraph.org/listinfo.cgi/osg-submissions-openscenegraph.org > > > _______________________________________________ > osg-submissions mailing list > [email protected] > > http://lists.openscenegraph.org/listinfo.cgi/osg-submissions-openscenegraph.org >
_______________________________________________ osg-submissions mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-submissions-openscenegraph.org
