On 10/2/06, Don Burns <[EMAIL PROTECTED]> wrote:
SceneView is really just an implementation detail at present, and one that will be moved further into the background w.r.t viewers, then finally replaced entirely. Also in the case of SceneView it doesn't actually have its own projection and view matrices, since 1.0 it "has a" osg::CameraNode which stores the projection and view matrices as well other Camera specific data. SceneView's old interface for setting view and projection matrices are just maintained for backwards compatibility. Internally it just passes this info on the CullVisitor(s).
SimplerViewer just has a CameraNode, right now the internal SceneView is still publically accessible, but my intention is to hide it, as its itrs really just an implementation detail.
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.
Not at all. One of the very valuable things about OSG is its optional use. One can use it without having to use all of it (I'm talking about the core osg library here, of course). Currently there are at least four places I can think of within OSG where a Projection matrix is held. The projection matrix contains a great deal of valuable information that can be passed along to the rest of the scene graph and utilities that use the scene graph. The objection I have is that information is obtained/and set in these different classes. For example, the near-far clipping planes are copied in SceneView and CullVisitor. This is an attribute that belongs in a single class: Camera. It should be set and retrieved from a Camera interface.
SceneView is really just an implementation detail at present, and one that will be moved further into the background w.r.t viewers, then finally replaced entirely. Also in the case of SceneView it doesn't actually have its own projection and view matrices, since 1.0 it "has a" osg::CameraNode which stores the projection and view matrices as well other Camera specific data. SceneView's old interface for setting view and projection matrices are just maintained for backwards compatibility. Internally it just passes this info on the CullVisitor(s).
SimplerViewer just has a CameraNode, right now the internal SceneView is still publically accessible, but my intention is to hide it, as its itrs really just an implementation detail.
But you and I have been down this road and we know good and well where that conversation will end up. If I want a visualization system that uses Cameras as a precedent class, then I must write that and provide the pieces that support that functionality. My only alternative is to do it _your_ way. What I want is to be able to encapsulate those attributes that belong to a Camera in a Camera class and not have overlapping functionality of SceneViews, CameraNodes and even CullVisitors. As mistaken as I may be in my point of view, that, to me is a better design and one that is better understood. I may not be alone in my thinking. But if I am alone in this way of thinking, then no one will use Producer, but no one is hurt. It shouldn't ruffle your feathers.
I don't think we are neccessarily that far a part. I believe a view having a camera is the approapriate way forward, this is what Producer style app does, and this is what SimplerViewer does too. The only real difference I see between us is that I'm also happy with a Camera being a fully fledged member of the scene graph then can be embedded internally, and believe that we should have just one API for both types of Camera usage.
The other difference tends to be style of use of C++/OO concepts. You tend to prefer explictly setting up code at the application level or with objects relationship, while I tend to try an encapsulate more functionality and provide more implicit relationships/functionality by default.
For teaching purpose I certainly have to conceed setting things up explictly is more effective, so it is probably a flaw in some of my code that it makes it awkard to take this approach rather than facilitiating it. I will me mindful of this when coding up further viewer codes, osgProducer::Viewer over the years has streadily gone overboard with way too much implicit functionality/relationships.
Robert.
_______________________________________________ osg-users mailing list [email protected] http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
