Hi John,
On Mon, Mar 17, 2008 at 8:53 PM, Argentieri, John-P63223
<[EMAIL PROTECTED]> wrote:
> I don't disagree with you, BUT we have certain requirements that we
> would need from osgViewer in that case.
>
> 1) The window it runs in has already been created by us before calling
> run().
The osgViewer library creates the windows at realize, unless they have
already been created.
FYI, run() is just the frame loop wrapped up in a single convinience
call(), you can break it out and manage realize(), and the frame loop
all yourself. There are examples of this in the OSG example set.
> 2) Do we really have to extend GraphicsWindowEmbedded if we want to
> support [1] for X11 and Win32?
GraphicsWindowX11, GraphicsWindowWin32 and GraphicsWindowCarbon all
support window inheritance i.e. they all can inherit their window from
an externally created window, adding the OpenGL support to this
window.
The osgviewerMFC and osgviewerQT both had code paths that illustrate
this window inheritance route.
> 3) Multiple views (windows) attached to one scene graph.
This is one of the main points of the development of osgViewer, it now
elegantly handles multiple views attached to one scene graph. The
class for doing this is osgViewer::CompositeViewer, this manages a
list of osgViewer::View(s). A few key points about it:
Each View has one scene graph, and can share its scene graph between
other instances of View.
The View can also share the same GraphicsWindow, or have its own
GraphicsWindow.
The View also has a master Camera, and an optional list of slave
Camera so you can scale from simple
views up to complete distortion correction or multiple display
output setups.
Each View has its own event handlers and cameras handlers.
Its extremely flexible and configurable.
> 4) The ability to scrap all osg handlers for events, or to leave out
> osgGA completely.
Yep, osgViewer supports this too. By default osgViewer doesn't
register any camera manipualators or event handles, you add the ones
you need. See applications/osgviewer/osgviewer.cpp.
he only except is that a TrackballManipulator is added by default by
Viewer::run() if no other camera manipulator has been added, but run()
is just a conveince method, you are free to roll you own frame loop
and control each View's master Camera view within the main loop
according to your own needs. I'd recommend this approach, run() is
only used in the examples to keep the examples simple and just focused
on the examples main task and not demonstrating viewer code n times
over.
> 5) We need to dynamically modify the scene graph. If [3] is
> multi-threaded that could be trouble.
osgViewer supports a range of threading options, all controllable by
you. You can set single threaded if you wish, but there is also
support for managing modification of the scene graph whilst
multi-threading.
viewer.setThreadingModel(osgViewer::Viewer::SingleThreaded);
Also see other threads about the various threading models.
> Will osgViewer support these requirements? Is is possible to create a
> single instance of osgViewer and add osg::Camera subtrees per each new
> window during runtime?
Yes and yes. You can even stop and start threading for when you do
these reorganizations of the viewer.
osgViewer is meant to be flexible in almost all ways, its intended to
solve the full range users viewer needs, and in doing so consolidate
the usage in a way that makes it easier to document, learn, usage and
for us at the other end to support.
osgViewer is just viewer nirvana yet though, if there are things that
can't be done then we can discuss these and look to resolve then to
make it closer to the ideal of a perfect viewer library. I suspect
for your own needs osgViewer is already along way along this route and
can do everything you need right out of the bag.
> P.S. Our network has problems with lists.openscenegraph.org, and I am
> sending to [EMAIL PROTECTED] instead. Has this changed again?
list.openscenegraph.org is the correct address.
Robert.
_______________________________________________
osg-users mailing list
[email protected]
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
