[osg-users] Development pathway

Robert Osfield robert.osfield at gmail.com
Thu Sep 4 08:14:29 PDT 2008

Hi Marmut,

Comments interspersed below.

On Tue, Sep 2, 2008 at 10:44 PM, Hartmut Seichter
<lists at technotecture.com> wrote:
> - documentation, there are numerous additions recently and in the past like
> osgWidgets or osgManipulators which are very interesting but not as
> interesting to reverse document the code - at least a "real" API
> documentation would be sufficient

By "real" API documentation do you mean better doxygen docs?

In case osgWidget, Jeremy has already come forward :-)

In case osgManipulator, this is more problematic as the original
author can gone very quiet since submitting the library, perhaps they
are still lurking and willing to come out and help document.
Otherwise we're all in the same boat in needing to learn the API from
the code and document this.

> - examples: I am also partly teaching computer graphics and an augmented
> reality class which heavily rely on OSG. One of the problems I see the
> students facing is that some of the examples are actually applications and
> seem to have started simple and went off to show the most convoluted
> brain-jogging way to achieve something simple - van der Rohe: Less is More

Different examples have had different lives.  Most start of simple,
but over time get extended either because underlying features grow in
capabilities, or that an example grows to test a particular feature
out thoroughly.   There may be cases where things could be simplified
without loosing there functionality, but it's a very much case of each
different example having to be treated on its own merits/failing.

If you know of particular examples that could do with a revamp then
please just enumerate them so that others can consider what might be
the right thing to do with them.

> On the deployment and integration side:
> - API additions which change ABI are not documented well: with osgSWIG I am
> basically poking in the dark, waiting for SWIG to cough up the changes
> - do I assume right/wrong that API change involves an increment in
> SOVERSION, it would make backwards compatibility easy

API revision lead to the SOVERSION being incremented, and even in most
dev releases you'll find the SOVERSION being bumped.

The svn repository itself is the also a very effective way of tracking
these changes.  In particular the online browsing of the svn repostory
can point to the last time different directories contents were


Another way that might be effective would be to for us to generate a
serialization out of the classes and methods that the wrappers
provide.  Perhaps this might even help with generating the interface
files for Swig.

Can I suggest striking up another thread to discuss language bindings
maintenance.  I would personally like to see more integral support for
other languages in the OSG.  My original hope was that
osgIntrospection would be the platform for a whole range of language
bindings that were easy to create and maintain, but alas this has
never caught on.   I'm not an expert in this direction so need others
to provide leadership and guidance with the implementation details.

> And now the more deep down things, which I think would be interesting to
> look at in a long term plan:
> - with the Mac OS X 10.4 - 10.5 disaster it should be clear that one can't
> assume a certain implementation of OpenGL available and relying on it on the
> front-end

Could you be more specific.  What parts constitute a "disaster" on
OSX.  Yesterday I was building and running OSG apps under OSX 10.5
without any serious issues - ATI support for shaders wasn't great, but
otherwise things worked well.

> - this leads unevitably to OpenGL 3.x and OpenGL ES 2.0 (what happened to
> the investigation of this?) on the horizon - which hints for hidden backends
> as with ES there is no certainty of the actual implementation of parts of
> the API - so you might need to roll your own depending on the hardware
> detected

The OSG has been ported to OpenGL ES 1.x now, and a initial submission
of this work is pending.  Once I've reviewed the changes I will know
better how easily we can integrate things in a maintainable way.

OpenGL ES 2.x and OpenGL 3.x are another leap that need lots of review
and thinking time.  Until we actually have working implementations on
our desktops it's hard to make much progress.

I'm also rather busy with other work, looking into this future
developments in something I have to squeeze into my non existent free
time...   Once VPB 1.0 is done and dusted I should have more breathing
room for this type of exploratory work.

> - bundling math includes in one header to be able to exchange some
> implementation (ie. floating point emulation)

I'm afraid this isn't clear what you mean here.  You'll need to
provide examples.

With float point emulation, it might be a leap too far in terms of
ease of support/maintenance.  Targeting floating point profiles of
OpenGL may well avoid a lot of headaches.

> Sorry for the lengthy email. Objective is to get some discussion in the OSG
> community - so please throw in you 2ct :)

A bit more than 2cts :-)

I think it would be best to tackle these topics as one topic per
thread, rather than pitching everything into on uber email, as it'll
make future discussion and searching/following of the discussion much


More information about the osg-users mailing list