On 10/2/06, Antoine Hue <[EMAIL PROTECTED]> wrote:
Alas this is something does occur. To fix bits of code sometimes the API itself has be changed. Or when trying to solve new problems more elegantly one has to refactor existing code to make them work better.
This leaves is between a rock and hard place, we either keep 100% API compatibility and don't fix problems the right way, or force workarounds on 3rd party apps to get around these problems or limitations, or we accept the consequences change.
Now ideally we'd be able to come up with a 100% perfect API and implement the first time its written, then we wouldn't have any of these quandaries, but alas we all live the in the real world and you have to try and manage things with good taste and understanding of the consequences both changing, and not changing things.
This isn't really the fault of the OSG, its an OpenGL bug, and one that can be fixed with a driver update. This particular problems isn't about older vs new hardware, its purely about dodgy OpenGL drivers.
More generally there is the question about backwards compatibility, as time goes on we'll need to keep evaluating it. For instance the precipitation effects I implemented in the spring are GLSL only, you could possibly try to havea path for older hardware but you have to give totally up on the performance and quality of the effect. There are other effects that will come along that require up to date drivers and hardware.
However, its down to the end user applications what types of scene graphs they want to deploy, as this entirely determines the hardware requirements. The OSG will still happily run on OpenGL 1.1 hardware/drivers.
My thoughts on a OpenSceneGraph 2.x is a radical departure though, one that is relies solely of shaders. This would allow one to simplify the scene graph state handling tremendously. OpenGL itself has such an approach on the horizon too. Direct10 is already there. All these not be friendly to older hardware though, so its a development that needs to be thought through carefully. In five years time though I doubt we'll have to many qualms contemplating such pure shader approaches.
The Roadmap is a bit effected by Don and my professional services work, but its also massively effected by developments out in the community, I can't control these developments, I can't plan them, the best I can do is choose when and how to integrate the contributions when they roll up to my door.
With open source projects one has to accept that the any road map will need to be torn up in short order. These is often the case with close source projects too, features get dropped, its get delivered late - one only needs to look at Vista as a good case in point.
- 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.
Alas this is something does occur. To fix bits of code sometimes the API itself has be changed. Or when trying to solve new problems more elegantly one has to refactor existing code to make them work better.
This leaves is between a rock and hard place, we either keep 100% API compatibility and don't fix problems the right way, or force workarounds on 3rd party apps to get around these problems or limitations, or we accept the consequences change.
Now ideally we'd be able to come up with a 100% perfect API and implement the first time its written, then we wouldn't have any of these quandaries, but alas we all live the in the real world and you have to try and manage things with good taste and understanding of the consequences both changing, and not changing things.
- 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.
This isn't really the fault of the OSG, its an OpenGL bug, and one that can be fixed with a driver update. This particular problems isn't about older vs new hardware, its purely about dodgy OpenGL drivers.
More generally there is the question about backwards compatibility, as time goes on we'll need to keep evaluating it. For instance the precipitation effects I implemented in the spring are GLSL only, you could possibly try to havea path for older hardware but you have to give totally up on the performance and quality of the effect. There are other effects that will come along that require up to date drivers and hardware.
However, its down to the end user applications what types of scene graphs they want to deploy, as this entirely determines the hardware requirements. The OSG will still happily run on OpenGL 1.1 hardware/drivers.
My thoughts on a OpenSceneGraph 2.x is a radical departure though, one that is relies solely of shaders. This would allow one to simplify the scene graph state handling tremendously. OpenGL itself has such an approach on the horizon too. Direct10 is already there. All these not be friendly to older hardware though, so its a development that needs to be thought through carefully. In five years time though I doubt we'll have to many qualms contemplating such pure shader approaches.
- 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.
The Roadmap is a bit effected by Don and my professional services work, but its also massively effected by developments out in the community, I can't control these developments, I can't plan them, the best I can do is choose when and how to integrate the contributions when they roll up to my door.
With open source projects one has to accept that the any road map will need to be torn up in short order. These is often the case with close source projects too, features get dropped, its get delivered late - one only needs to look at Vista as a good case in point.
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.
Well the OSG has actually been around for quite some while, the lightweight management structure has worked effectively throughout the growth of the project from 2 people in 1998/9 to nearly 1500 hundred today. If the management was fragile it would have broken long long ago. I might not be too public about the management approach I take, its deliberately low key, but there are systems in place that I rely upon.
Now one could argue about what would happen if I were run over a bus, and that management by committee would provide insurance against this, but there are also problems that brings with it unless you get the systems in place that keep things well oiled. This topic is one of the items I want to thrash out at the gathering here in a fortnight.
Also for a bit of perspective I think it's worthwhile looking at competing scene graphs, Fahrenheight? Performer? Cosmo3D/Optimizer? All had classic management behind them, but all of them are no more, the OpenSceneGraph with its "fragile" management and no real roadmaps has out lived them all.
Robert.
_______________________________________________ osg-users mailing list [email protected] http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
