Up no change since last submission 2012/5/21 David Callu <[email protected]>
> 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
