On 5/18/07, Paul Martz <[EMAIL PROTECTED]> wrote:
Just to clarify, Robert sent me an offline email stating that he wanted to get 2.0 out the door, and wanted to know what my schedule was for the next revision of the Quick Start Guide. I suggested June 7 as an availability date. So, although Robert's post that started this thread seems to imply that OSG is going out to match the QSG release, I honestly got the impression in our offline discussion that Robert felt OSG was ready for 2.0, and he just wanted to know my schedule so we could sync up.
I feel the bulk of the OSG is ready for 2.0, and the opportunity of getting it out in time for the QSG to go out to something worth going for as its simplify the lives of those coming to the OSG for the first time. Consider what like is like for new users of the OSG, them come across 1.2, then download it, they have to get their head around a triple set that couples the OSG with two tightly bound dependencies, and a bunch of normal dependencies. If this extra complexity doesn't put them off them off then they join the commmunity and start trying to write apps, and soon find out that actually they might be better server by things in the dev releases, and that things they learnt about 1.2 like osgProducer no longer map to the latest dev release, so they have to go off an learn new stuff and discard some of what they have already worked hard to get their head around. The upshot is we have new users wasting precious time and brain power on stuff they needn't. So from a new users perspective I have absolutely no qualms about make 2.0 sooner rather than later, and done so in conjunction with a book that talks specifically about it.
From an existing users perspective, the core OSG libraries - osg,
osgUtil, osgDB, osgText, osgSim, osgFX, osgParticle are all in the best state they have ever been in, they are better than 1.2, your apps will be more robust by moving to what we have in SVN right now. The same goes for the plugins they are all ready, save for the possibility of an update from Terrex which in theory is in the works, but hasn't turned up yet. osgProducer, while now a separate project, is also pretty stable (very few changes have been required since 1.2) and ready for its 2.0 in conjunction with OSG-1.2, the same goes for the VirtualPlanetBuilder. This leaves osgViewer, osgShadow, osgTerrain and the build system as the main areas of concern w.r.t readiness for 2.0. osgShadow and osgTerrain are still in development, and while usable in parts are where I want them to be, and won't be stablised in the time frame for 2.0. While this isn't ideal, if we wait for these then it'll be several months before 2.0 can go out. Since these are new libraries them not being perfect won't affect existing users, as long as they build and keep themselves to themselves I can't see a big issue. osgViewer for the most part is pretty near to state ready for 2.0, there are a couple of missing features relative to osgProducer/Producer - Pbuffers and config file support, for the majority of new and existing users this won't be a show stopper. For those its a show stopper there is still osgProducer working happily in the background. There are a few loose ends in osgViewer like the close problem under Windows, but things like this should be solvable with a bit of debugging. Overall I find osgViewer to be far more functional, scalable and stable than osgProducer - when I used to run my standard tests of the OSG examples (using the runexamples.bat) the osgProducer based examples occassionally used to crash, such that I was lucky if I got through all examples without a crash on exit. I spent many many hours/days trying to fix this Producer bug, but never was able to resolve it. Whereas osgViewer based examples run and exit cleanly all the time, not getting to the end of the tests is never an issue now (at least under Linux where I test ;-) To me osgViewer is ready to be used by the majority of OSG end users. Finally this brings us to the build system, mostly the feedback of the CMake build system is positive, in particular on the two biggest platforms Windows and Linux things work pretty cleanly, as they do on rest of the unices. There are some unresolved issues under IRIX w.r.t. n32 + n64, it'd be great to resolve these, but I'm a CMake or IRIX guru to be able to help - so we need members of the community to get stuck in. There is also OpenGL header issues under Cygwin. The next question are these build problems under minor platforms show stoppers? Personally I'd say no, as if you are on one of these niche platforms there is a good chance that you have skills to cope with using SVN or dev releases. We can always follow up with 2.0.1 once such issues are resolved - if they aren't resolved before 2.0. In a ideal world everything will be perfected, all functionality complete and in its final form, and throughly tested and working on all platforms, but... being a perfectionist can cause the project more harm than good. For me the critical indicator is the current SVN/dev releases of higher quality and easier to build and use than 1.2 for the vast majority of users, if its is, then we are better off make 2.0 soon, and for the sake of new an old users alike. What I'm interested in specific issues that "MUST" be resolved before a 2.0 can go out, what are the absolute show stoppers. Secondly what else "Should" be completed to make 2.0 a good and well rounded release. Finally what "could" be done in the time frame if users have completed all the MUST and Should's, and still have time on their hands, and that won't adversely risk the quality of the final release. If you can think of any them add them to the below page, or post them on this thread, DevelopmentWork TODO list for 2.0 http://www.openscenegraph.com/osgwiki/pmwiki.php/Tasks/DevelopmentWork Robert. _______________________________________________ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
