Eric, 'Working with the art path' sounds of definite interest to us - I'd have a hard time imagining it would be of interest to others. Just curious, have you ever used Moodle for course development? I have no experience with it, but it seems like it might be good way to collaborate remotely on course development. Is it me or does wiki seem to be the wrong tool for this? Anyone with any experience, other recommendations? Thanks Joe
-----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Eric Maslowski Sent: Thursday, September 21, 2006 6:46 AM To: 'osg users' Subject: RE: [osg-users] OSG -- near future I would be happy to contribute to any guides that are written. Currently, my strongest points in OSG are: working with the art path, animation paths, developing for multi-screen displays, and integration with VRJuggler. If any of this sounds appealing, just let me know and we can work out the specifics. E. --- Eric Maslowski Research Computer Specialist University of Michigan 3D Lab Autodesk 3D Studio Max Certified Trainer email: [EMAIL PROTECTED] office: 734-615-9699 > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:osg-users- > [EMAIL PROTECTED] On Behalf Of Sullivan, Joseph (CDR) > Sent: Thursday, September 21, 2006 09:14 > To: osg users > Subject: RE: [osg-users] OSG -- near future > > 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. > _______________________________________________ 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/
