It is one Node, OcclusionQueryNode, derived from Group. This node has a few supporting classes that aren't exported. It also has a handful of small NodeVisitors for utility purposes.
If we put this Node in a NodeKit rather than the osg library, how would it delete the query IDs? In our previous discussion on this subject, you outlined a new design for deleting OpenGL objects; I don't have the cycles to contribute to this development. -Paul > Hi Paul, > > How big is osgOQ? I am wondering if its small enough it > could be integrated into another NodeKit. Thoughts? > > Robert. > > On Dec 8, 2007 4:19 PM, Paul Martz <[EMAIL PROTECTED]> wrote: > > Hi Robert -- I'm happy to help with integrating osgOQ into the core > > distribution. At this point, .ive support needs to be > added, but this > > should be trivial. Then it'd be nice to have a solution for > cleaning > > up query IDs (discussed recently); I can easily use the existing > > framework if the OcclusionQueryNode is added to the osg library. > > > > I'm getting some testing from ISU (who funded the project), but > > nothing other than "run the demo" testing from others. It'd > be nice to > > see more testing. > > > > I am investigating one bug at this time, but it is only in > > non-osgViewer usage, so this shouldn't be a showstopper for > 2.4 integration. > > -Paul > > > > > > > > > -----Original Message----- > > > From: [EMAIL PROTECTED] > > > [mailto:[EMAIL PROTECTED] On Behalf Of > > > Robert Osfield > > > Sent: Saturday, December 08, 2007 7:08 AM > > > To: OpenSceneGraph Users > > > Subject: [osg-users] Looking towards 2.4, and what might > go into it. > > > > > > Hi All, > > > > > > After a two month break I'm now doing a purge of the submissions > > > backlog. I doubt I'll get all the way through before > Monday, but on > > > Monday I'll tag the first dev release since 2.2 stable was made. > > > This dev release will be 2.3.0 and be the first concrete step > > > towards the final 2.4. This leads me on to asking the question - > > > what features should we aim to integrate with 2.4? > > > > > > My own short list for contenders for integration are: > > > > > > osgOQ - Occlusion Querry support > > > osgCal - Cal3D integration > > > osgAL - OpenAL integration > > > > > > I'm not personally familiar with these libraries, but do > know that > > > they are known to work with the latest OSG so should be > relatively > > > straight forward to integrate. Thoughts for the authors, > > > maintainers? > > > What extra work would be appropriate before integration? > > > Would you be happy with integration? > > > > > > My own inclination towards integration is to make it a bit easier > > > for OSG users to assemble their application without chasing down > > > lots of different nodekits all of which are maintained in > different > > > places with different build system and different release > schedules. > > > The downside for me is there is more work involved at my end at > > > least initially while we get the build systems working > well across > > > the range of platforms that the OSG supports. Long term I'd hope > > > that this will diminish and it'll be less support work associated > > > with helping end users get things working at there end. > It should > > > also be possible to make the overall OSG dev experience for end > > > users slicker as we should be able properly test and get > areas like > > > multiple window/multi-threaded usage properly excercised. > > > > > > I would also like to see the core OSG have support for > scripting out > > > of the bag, as well as integration with the main > browsers. One has > > > to gauage what is doable in what time frame so should be > considered > > > in terms of 2.4 or 2.6 etc versions. > > > > > > I'd like to see scripting supported out of the box to > enable us to > > > develop applications purely from scripting languages, so > developers > > > in this realm would just need the binaries to the OSG > installed, and > > > no need for C++ dev environment. > > > There are limits to how much functionality you can expose in this > > > direction, but my guess is it should be possible to write > reasonable > > > useful apps, and especially > > > good for prototyping and cross platform portability. > One has to ask > > > which scripting languages to go for - Lua and/or Python? > Lua would > > > be the easiest to integrate in terms of being very self contained > > > i.e. > > > which could stick the whole of the lua interpreter into > the core OSG > > > distribution and one would hardly notice as its so tiny. > > > > > > Thoughts? > > > Robert. > > > > > > ps. I'm still very busy with other on going work so please don't > > > expect me to be able to dive into this stuff right away. > Come 2008 > > > I should start become a bit more available and able to > start looking > > > at progressing some of the above, so opening this stuff off for > > > discussion now will help us mesh gears better when the time comes. > > > _______________________________________________ > > > osg-users mailing list > > > [email protected] > > > http://lists.openscenegraph.org/listinfo.cgi/osg-users-opensce > > negraph.org > > > > _______________________________________________ > > 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-opensce negraph.org _______________________________________________ osg-users mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
