Hi, could we get support for multiple render targets (MRT) integrated into 2.4? I know some people are using hacky patches for this. Some patches have been submitted, but they have to be reworked.
I can help with this if needed. regards jp Robert Osfield wrote: > 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 > osg-users@lists.openscenegraph.org > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org > -- This message is subject to the CSIR's copyright terms and conditions, e-mail legal notice, and implemented Open Document Format (ODF) standard. The full disclaimer details can be found at http://www.csir.co.za/disclaimer.html. This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. MailScanner thanks Transtec Computers for their support. _______________________________________________ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
