Hi Robert,
thanks, i have to use my own databasepager implementation for our
application. So i need to insure that the may databasepager will be used for
each scene.
May i need just a possiblity to set the database pager object and management
with a factory object.
i need just to use my own databasepager at the moment.
/adegli
2007/6/19, Robert Osfield <[EMAIL PROTECTED]>:
Hi Adrain,
It would seem to be that your ViewManager proposal is just
CompositeViewer with a different name... It handles multiple views
and on one or more scenes on one or more graphics windows all
syncronized.
It is my intention that Scene will be shared automatically when you do
a setSceneData with the same scene graph on multiple views. This
isn't wired up yet but that's the intention of the design. This
approach will ensure that each scene graph has just one database
pager.
W.r.t hiding SceneView this is actually something I have tried to do
as a design goal, as SceneView is just an implementation detail, in
future I plan to do away with SceneView usage in osgViewer completely,
moving all the stereo support etc. directly into osgViewer where it
can be better managed. If the current implementation can be hidden
then transition across to not using SceneView will be simply be a
case of recompile rather than a refactor end user code.
But... end users want a bit more control that is currently afford by
grappling directly with SceneView, so we need to enumerate what
controls this is and then provide this in the public interface of
osg::Camera, osg::View or osgViewer::View/Viewer/CompositeViewer.
For me the question is not about major refactoring of osgViewer, I'm
pretty confident that its overall design is sound, its about what
tweaking of the interface we need to do to expose the control that
users might need.
So what exactly is the control you are currently missing? Just
listing what you do to SceneView previously would be enough for me to
understand.
Robert.
On 6/19/07, Adrian Egli <[EMAIL PROTECTED]> wrote:
> hi robert,
>
> i guess that you remember my questions about the SceneView access. I did
a
> review of the Scene and Viewer design also with the implementation
part. i
> wonder why you
> create for each setSceneData a new Scene. I understand that you like to
have
> multiple scenes in the OSG Viewer with multiple Windows. And then you
call
> assign to camers.
> I am not sure that this is a good desicions. If i would like to have
more
> than one scene in many windows, i would like to have one scene and multi
> windows and also
> scene S in n windows and scene K in m windows (cameras). But the
actual
> design doesn't not yet support this, i am right? (have a look at the
code
> snip)
>
>
> Scene::Scene():
> _firstFrame(true)
> {
> _frameStamp = new osg::FrameStamp;
> _frameStamp->setFrameNumber(0);
> _frameStamp->setReferenceTime(0);
>
> _updateVisitor = new osgUtil::UpdateVisitor;
> _updateVisitor->setFrameStamp(_frameStamp.get());
>
> setDatabasePager(new osgDB::DatabasePager);
> }
>
>
>
>
> void Viewer::setSceneData(osg::Node* node)
> {
> _scene = new osgViewer::Scene;
> _scene->setSceneData(node);
> _scene->setFrameStamp(_frameStamp.get());
>
> computeActiveCoordinateSystemNodePath();
>
> setReferenceTime(0.0);
>
> assignSceneDataToCameras();
> setUpRenderingSupport();
> }
>
> Better would be to have a Viewer with multi window / camera support,
each of
> them are synchronised, only if we have shared memory or shared resource.
the
> easiest way is to
> have syn. technique for each configuration. We can render (draw) in
> parallel, update the scene protected as you much better know than me.
> I propose for design to have
>
> + ViewerManager
> - Viewer (A)
> * Scene
> o SceneView
> o Camera
> - Viewer (B)
> * Scene
> o Camera
> o SceneView
>
> I feel like to have the maximun of flexiblity for our new generation of
> viewer. Or what did you still have for design?
> What think others about this really important topic for the future of
our
> application.
>
> regards
> adegli
>
>
>
> _______________________________________________
> 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/
_______________________________________________
osg-users mailing list
[email protected]
http://openscenegraph.net/mailman/listinfo/osg-users
http://www.openscenegraph.org/
