Hi,

On 9/21/06, Gordon Tomlinson <[EMAIL PROTECTED]> wrote:
As a guide I think the 'Performer getting start Guide' and  "Performer
Programmers Guide" might be a good template to perhaps build of

http://www.sgi.com/products/software/performer/manuals.html

Have you seen this:
http://www.stackedboxes.org/~lmb/OSG/ASIttBPoOSG--02005-10-23.pdf ?

I started to write this some time ago, in my spare time, as I learned
OSG. I still intend to eork on it, but my spare time has been quite
short lately. Anyway, for complete beginners, I believe it is useful
as is.

It gets about 300 downloads per month, but I never got any feedback
about it (apart from a couple emails when I announced it here on the
list).

Cheers,

LMB

I think even as they stand for the most part you could just change pf to
OSG, I know its not the simple ;), but you get the gist of what I mean ;)


When I'm teaching programming Performer/Vega/VegaPrime I still point
students to these docs as they are very good IMO.... and you can down load
as PDF etc...







Best Regards



Gordon

__________________________________________________________

Gordon Tomlinson
Email         : gordon.tomlinson @ overwatch.com
YIM/AIM       : Gordon3dBrit
MSN IM        : Gordon3dBrit @ 3dscenegraph.com

__________________________________________________________

Telephone (Cell): (+1) 214-477-8914
Telephone (Work): (+1) 703-437-7651
"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: Sullivan, Joseph (CDR)
[mailto:[EMAIL PROTECTED] Behalf Of
Sullivan, Joseph (CDR)
Sent: Thursday, September 21, 2006 9:14 AM
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
osg-users@openscenegraph.net
http://openscenegraph.net/mailman/listinfo/osg-users
http://www.openscenegraph.org/


_______________________________________________
osg-users mailing list
osg-users@openscenegraph.net
http://openscenegraph.net/mailman/listinfo/osg-users
http://www.openscenegraph.org/

Reply via email to