On 10/2/06, Robert Osfield <[EMAIL PROTECTED]> wrote:
Hi Don,On 10/2/06, Don Burns < [EMAIL PROTECTED]> wrote:I also believe passionately the we have to integrate much more seamlessly with other 3rd party windowing toolkits, so any viewer code really needs to be agnostic of windowing toolkits.I'd like to put in my $.02 here as I did post a challenge to "simplicity" with my recent posting of the Producer OsgViewer example.
It would seem that recent threads on the list have indicated that one of the biggest challenges OSG has to reaching more participants is that it is difficult to learn. Having developed a class to teach the internals of OSG I know the types of challenges that new users come up against. Having attempted to write a book on OSG, I know that its changing shape is an indication of a lack of scope limiting, top-down design, making it difficult to nail down a proper overall view.Problem areas in the OpenSceneGraph distribution are principally osgGA and osgProducer, osgGA and osgProducer have evolved in a bit of hotch potch way and are surely in need of refactoring which is much of the topic of my thoughts on the need for an osgViewer library.
Sorry Don but this is rant on design is *pish*
The OSG is actually generally pretty well designed. The core scene graph is has been carefully designed, each iteration of its design made with care and deliberation. I'd go out on a limb and say its one of the cleanest scene graphs *ever* developed.
Perhaps you can point to a cleaner scene graph out there? Perhaps you can point out a more extensible scene graph out there?
The core scene graph didn't happen accidentally, its happened due to hours of design work, and reflection of how people need to use scene graphs.In fact, the contents of a book can only be a written as a set of examples on how to do specific tasks in OSG because of this fact. It is difficult to apply an overall abstract concept in order to solve a problem. One must learn from examples (Gems type approach).
A while back, Robert and I began to fork in our agreement on where OSG should go. When I first wrote the original SG, my intention was that it be only a scene graph. Now, even the basic definition of what a Scene Graph is is not something we can agree upon conclusively. The addition of items like graphics threads and multiple views all generated from within the scene graph is certainly a violation of scope in my thinking. My approach would have been (has) placed this functionality outside the scene graph itself.
Well all of water has travelled under the bridge the days when I took over work on sg. When I took over project leadership it didn't have any culling, transparency depth sorting, no concept state sorting, no LOD's, its was just a was basically sgGroup, sgDCS, sgGeode, sgGeoSet and a sgGeoState, and a lex-yacc custom ascii loader for the cow, cessna, truck and the hang glider. While very basic it provided the concept that PC's were powerful enough to start getting serious about doing vis-sim. The whole scene graph has evolved from this humble beginnings.
The OpenSceneGraph as it is now reaches far beyond even the scope of where Producer or Inventor were pushed to, the OpenSceneGraph community uses the scene graph is far wider range of apps, it has to cope with far wider range of graphical extensions and techniques, multi-pass, multi-state rendering is common place with the OpenSceneGraph, yet still rare to find such support in any other scene graph. The scope of the OpenSceneGraph is far far beyond what I ever expected or intended it to encompass. This expansion of scope has happened because end users have pushed it boundaries, and kept on pushing.
With the expansion of scope one has to work hard to keep the design coherent and as straightforward as you can, and sometime this means discarding some previous held convictions if they turn out to be road blocks. For instance not having camera's support native to the scene graph was a very serious road block, not having the ability to track multiple camera views turned to be another. There have been dozens of such little road blocks along the way, each time you hit one you have to show good taste in design to provide a better solution.
While the core scene graph is fundamentally my design, its design is heavily influenced by your teachings on how to get the best graphics performance from a computer graphics systems. Its my OO background that has pushed the extensibility and flexibility side of the scene graph.Without making a qualitative judgement on which approach is "better", I believe there are two camps of thought here (perhaps three). It is obvious that there is a good part of the OSG community that prefers Roberts approach. I also think there is a good part of the community that might prefer a different approach. (The third is those who are simply trying to learn one way or another).
I believe most users will just want to get their job done as simply, efficiently and reliably as they can.
Perhaps w.r.t to viewers one can talk about divergence of approaches, as I presume you are thinking about make Producer a scene graph and dropping CameraNode etc.
Interestingly, Robert and I have offerred up constructive criticism on each other's concept of a "Simple" viewer off-line over this weekend. What I see as complex, he sees as simple and vice versa. The goal of the Producer OsgViewer example was to expose in the main body of the program, capturing and processing events, camera control through a Camera class, where views are set directly from the main program and manipulators that don't depend on preprocessed windowing system events to function. If I understand Roberts osgviewer*** examples correctly, these hide much of this functionality. Camera control, and event processing occur behind the scenes, not in the body of the main example.
One man's "hiding" is another man's "encapsulation" in a OO programming.
Now osgProducer/osgGA are great examples of class hierarchies that are loosely couple yet highly cohesive, but then Producer is actually much a improvement on these.
For the types of apps that some end users of the OSG are trying to write none of osgProducer/osgGA/Producer are up to the job, they all be replaced to make their lives easier.If this direction is forthcoming (and I think it is) would like to begin developing Producer as an alternative. Producer has been limited in usage until this point, to taking the role of providing multi-pipe functionality. While this will continue, I expect to be adding a great deal more functionality to Producer in a modular fashion. It will be a different approach, and hopefully one that some of the OSG community will find easier to use.
I hate to say it, but this will lead to more API duplication, its bad enough already with duplicated Matrices, ref_ptr<>, Timers, Cameras, keyboard mouse handling... All this *isn't* good for teaching people about the OSG.
If we are genuine about wanting to make it easier for people to learn the OSG then we are best served by a windowing library that uses OSG native classes, and in a style that is consistent with the rest of the OSG.
We also need to make it simpler for people to build the OSG, this means simplifying the dependency tree - the current OSG_OP_OT triple set requirement is a stumbling block that all users have to climb over, considering that I've done the releases for OP and OT to keep things in sync with the OSG 1.0,1.1 and 1.2 releases, for all intents and purposes its one set of software, the users base for OP and OT is almost entirely OSG based, the seperation for most users I would guess is somewhat artificial.
I am however, not about to embark on writing osgViewer library right now, SimpleViewer is not a significant step towards it, its simply a stop gap to try and help out the poor users stuck trying to integrate with other 3rd party windowing libraries.
Robert.
_______________________________________________
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/
