Thanks for these very useful remarks.
SOme comments and answers to questions:
On 10/2/06, Antoine Hue <[EMAIL PROTECTED]> wrote:
The more complex solutions should not change, at least in API. Our first take here is that we are attempting to provide a simple approach to remove the difficulty barrier for new candidates. I don't believe what Robert is proposing will break your current approach either.
I can give you a ittle of what Producer's philosophy has been, and will be going forward. Producer has been mistakenly categorized as a windowing toolkit. This stems from its replacement of GLUT in the early days, which caused the addition of the KeyboardMouse class. It is, currently, a library of camera management. This also means graphics context management and parallelism. In Producer the terms Camera and Viewer will always be synonymous. Producer provides a means of approaching the problem of visualizing a scene by starting with a Camera and working downward. This won't change.
A contract about to begin will have direct affect in improving Producer's graphics context management and will add to functionality already in place.
If you prefer the approach of using a Camera as the precedent class to the scene graph, then I would continue with this. I will release soon a Producer::RenderSurface_QT, which you can experiment and see if this does the trick for you. Otherwise, Robert's examples might be a good solution.
Yes! absolutely. The only reason it has been a single library until now is due to its size. The abstractual boundaries are fairly clear and need to be separated into diverse modules. That is where Producer is going. A goal for Producer has always been to provide stand-alone units. For example, the manipulator (the Trackball being the only one now) is written to depend on nothing at peer inheritance level. Its interface is generic. It belongs, however, as you suggest, in a manipulator library.
This is the trade-off to free opensource projects. We must feed our kids, so often the commercial work will take precedence. However, I can say that the having contracts that directly support the development of even a component of our projects will have an effect to maintaining all of it.
Robert and I have discussed this direction as well. Currently, the model we are using is pretty good, a fact that can be sustained by observing Robert's dedication to keeping things moving forward (and the fact that he descends from woodpeckers, a quality easily observable by his typing). I am also entering into a couple of projects over the next couple of years that will insure activity on the Producer front. However, we do recognize that there is a life to that and at some point it may make sense to have a committee take over. Before that can happen, however, good top-down definition will need to be put in place.
-don
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?
The more complex solutions should not change, at least in API. Our first take here is that we are attempting to provide a simple approach to remove the difficulty barrier for new candidates. I don't believe what Robert is proposing will break your current approach either.
I can give you a ittle of what Producer's philosophy has been, and will be going forward. Producer has been mistakenly categorized as a windowing toolkit. This stems from its replacement of GLUT in the early days, which caused the addition of the KeyboardMouse class. It is, currently, a library of camera management. This also means graphics context management and parallelism. In Producer the terms Camera and Viewer will always be synonymous. Producer provides a means of approaching the problem of visualizing a scene by starting with a Camera and working downward. This won't change.
A contract about to begin will have direct affect in improving Producer's graphics context management and will add to functionality already in place.
If you prefer the approach of using a Camera as the precedent class to the scene graph, then I would continue with this. I will release soon a Producer::RenderSurface_QT, which you can experiment and see if this does the trick for you. Otherwise, Robert's examples might be a good solution.
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.
Yes! absolutely. The only reason it has been a single library until now is due to its size. The abstractual boundaries are fairly clear and need to be separated into diverse modules. That is where Producer is going. A goal for Producer has always been to provide stand-alone units. For example, the manipulator (the Trackball being the only one now) is written to depend on nothing at peer inheritance level. Its interface is generic. It belongs, however, as you suggest, in a manipulator library.
- 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.
This is the trade-off to free opensource projects. We must feed our kids, so often the commercial work will take precedence. However, I can say that the having contracts that directly support the development of even a component of our projects will have an effect to maintaining all of it.
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.
Robert and I have discussed this direction as well. Currently, the model we are using is pretty good, a fact that can be sustained by observing Robert's dedication to keeping things moving forward (and the fact that he descends from woodpeckers, a quality easily observable by his typing). I am also entering into a couple of projects over the next couple of years that will insure activity on the Producer front. However, we do recognize that there is a life to that and at some point it may make sense to have a committee take over. Before that can happen, however, good top-down definition will need to be put in place.
-don
Antoine
_______________________________________________
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/
