Hello,
As an answer to Robert and Don, I may tell about my experience.
I more or less started 3D programming with Open Scene Graph. Just
before, I did some trials directly on OpenGL and found it very low
level. I was more than happy to find an higher level API in OSG.
At first (late 2004), most of the problems I had were linked to OSG
building and running on Mac, things improved since and I switched to Linux.
Then, given the examples and using Producer, I have been able to create
more and more complex features. However, as our application is maturing,
we also needed more and more understanding of the OSG internals:
- OSG Terrain working and internals.
- Management of multiple contexts
- Manipulators
- .... and toolkits to get a graphical interface (menus, dialogs,...).
We have decided to go for a QT based GUI as it seems one of the best
candidates to work out a portable GUI in C++.
From some email threads, I understood that Producer is not integrated
well with QT.
At that time (early 2006), there was no wrapper for OSG in QT4 but an
aging QT3 wrapper. Robert was talking about something with releasing.
Then someone posted a tentative wrapper but the trial has not been
confirmed. I took some time to improve it and posted the result, that is
what is available on the Wiki. It works more or less without equaling
Producer even for a single camera/render surface.
No, there seems to be some controverse about what to do next. I am
really puzzled, should I wait until dust settle? Should I learn and
develop on something that may get obsolete soon? Should I work out my
own solution? Should I go for an integrated solution like Robert's
proposal but to the risk of hitting a wall later?
From this status, here is what I think about OSG.
The pluses:
- It is a great tool: good features, excellent quality.
- Portability is good.
- Community is active.
- I learn a lot reading its internals.
- I am totally impressed by Robert's email/keyboard/coding bandwidth.
(Is it a challenge? ;-) )
The more critic:
- Integrated complex functionality is nice to get started but gets
annoying as soon as something more customized is needed. E.g.:
manipulator. The library layering is very important for custom solutions.
- Source luck is very good but hardly replacing documentation and
definition.
- OSG perimeter and architecture is difficult to catch. Is it possible
to use only a subset of the libraries? At least core functionality
should be well defined and located in 1 or 2 libraries.
- Concerning Producer, perimeter is clearer but it looks like a
monolithic library. Would it be possible to identify well separated
layers to make it easier to retarget.
- API statibility is not high enough. Lately, with OSG 1.2, I had to
choose between keeping resolved some bugs or updating my code to work
with latest changes to osgTerrain.
- This is also a question when it comes to support older hardware. It is
not enough to have an application running on the top 10% of the
hardware/drivers out there. E.g.: mip mapping bug on ATI makes
osgTerrain quite useless on many machines.
- Roadmap is totally dependent on Don and Robert's contracts. It is good
to have access to latest developments. However there is no visibility
about when and in which release.
Overall, I think OSG management is fragile. It relies heavily on a
couple of persons. Up to now, it has been a key to success because OSG
creators have been able to make sensefull decisions in a reactive
manner. But I cannot think this model is sustainable. GDAL is currently
doing the transition to a board managed system. Might be interesting to
watch.
Antoine
_______________________________________________
osg-users mailing list
[email protected]
http://openscenegraph.net/mailman/listinfo/osg-users
http://www.openscenegraph.org/
