You and your users would still be able to use the old loader with a simple environment variable. I think the visibility gained (and in turn more debugging and optimization) by making it the default is important if we ever want to get rid of the old loader. I think we really need to keep moving forward. Remember, you're not losing the old loader yet!
Corbin -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Gordon Tomlinson Sent: Tuesday, June 13, 2006 4:49 AM To: 'osg users' Subject: RE: [osg-users] New OpenFlight loader -- time to switch? I would rather see the new flight loader switched After the next tagged version of OSG as it's a really big change for many and for my folks I work with would mean we would not be able to adopt the next tag release What is the plan for the next version tagged release ? Best Regards Gordon __________________ "Self defence is not a function of learning tricks but is a function of how quickly and intensely one can arouse one's instinct for survival" - Master Tambo Tetsura -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Robert Osfield Sent: Tuesday, June 13, 2006 5:17 AM To: osg users Subject: Re: [osg-users] New OpenFlight loader -- time to switch? Hi Paul, I'm inclined to towards making the new loader the default too, to force along testing of it. Right now its significantly slower to load, and by default produces slower real-time performance. I'd like to see these addressed, and perhaps by making it the default will raise the number of eye balls on it to help speed things along. Getting additional contributors to it should be easier than with the previous OpenFlight loader as Brede's done a great job at creating a smaller, cleaner and yet more functional plugin ;-) Robert. On 6/13/06, Paul Martz <[EMAIL PROTECTED]> wrote: > I've had a couple offline discussions with Brede and also Corbin > Holtz, and based on those discussions, I'd like to suggest that we > switch the default OpenFlight loader to be the new loader, with the > old loader still accessible by setting the env var to "old". > > The reason is increased testing. If critical functionality is missing, > users current in CVS will find out about it and make it known, then I > or Brede (or any other developer) can add the required features. In > the meantime, current CVS users can set an env var to go back to the old loader. > > I'm aware of the following missing functionality: > * Overriding ext ref palettes. > * Parsing lat/long out of the header and returning it as UserData. > * Support for cube mapping. > > Based on my testing, I don't think it's premature to move to the new > loader, but I expect that doing so will reveal issues -- and really, > that's the point. > > Comments? > -Paul > > _______________________________________________ > osg-users mailing list > [email protected] > http://openscenegraph.net/mailman/listinfo/osg-users > http://www.openscenegraph.org/ > _______________________________________________ osg-users mailing list [email protected] http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/ _______________________________________________ osg-users mailing list [email protected] http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/ _______________________________________________ osg-users mailing list [email protected] http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
