Speaking of introductory guides... Are any of the other educational institutes that are making use of the OSG able to collaborate on and publish introductory material? Don and Robert, Would making this introductory material available interfere with training that you provide? Joe S.
________________________________ From: [EMAIL PROTECTED] on behalf of Robert Osfield Sent: Wed 9/20/2006 7:23 AM To: osg users Subject: Re: [osg-users] OSG -- near future So I've fleshed out a little why expanding the OSG users base is good for the OSG project, its developers, community, the software quallty and the wider industry, but I didn't touch on just how to go about it. Well fixing things in the OSG that turn people off the project is one thing we need to address. The big fat hairy one is obviously documentation. Not the lack of information, but the lack of introductory and advanced programming guides and in depth reference documentation. The book thread address this so I'll not go into this any further here. Next thing to fix is how easy it is to get the OSG compiled, installed and running. The sheer size of the project, and the numerous build options make it very powerful, but it does raise the barrier to entry. Could Cmake streamline it? Scripts for building? Next up is API size, its sheer breadth and depth of functionality is a lot to tackle for the newbee. OpenGL will eventaully become more streamlined, so perhaps too can the OSG. This is part of what I discuss in the Siggraph 2006 talk. Next up is the relatively sophisticated use of C++, this is a hurdle for some in terms of learning curve, partly because of the complexities of C++, and partly down to the fact that C++ no longer has developers sole attention. Then there are other languages Jave, Python, Lua, C# and all vying for attention of developers, we don't yet support these well. If we want to help these developers out then we need to embrace support for them much more emphatically. The C++ core here is a bit of hinderance when it comes to intergration with other languages, with C being the comon denominator. osgIntrospection can come to the resuce here, its a bit heavy weight, but dynamically typed langauges its a good match. Further to the integration story is that awkwardness of getting different types of viewers setup in the multitude of windowing libraries that exist today. Making it easier to build 3d viewers into your existing or new apps is something that I feel strongly about. This what the osgViewer library I've previously talked about is really about. So to recamp things to fix and get done: 1) Documentation and book(s) 2) Better viewer classes supporting multiple 3rd party windowing API's 3) Better 3rd party language support 4) Streamlining of builds 5) Streamlining of API No doubt there are other items that need to be added to the list, and priorities to be, so fire away. But remember that someone has to get on and do it, so if you add an item be prepared to roll your sleeves up and help get it done. And on that note, please step forward those who'd like to pitch into various aspect of this work. I'll create a few new pages on the wiki to help documentation the tasks and who's available to make progress on the various items. Robert.
<<winmail.dat>>
_______________________________________________ osg-users mailing list [email protected] http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
