Hi, > It is an app in OSG examples, named osgviewerMFC, that demonstrates almost > exactly what I need. > > The app doesn't use CompositeView class. And things are much simpler then.
Yep, there's no really problem replacing the Viewer by a CompositeViewer in the osgviewerMFC example, except for the StatsHandler that's messing the focus of the osgViewer::Views attached to the CompositeViewer, as you'll probably discover. But where things are really becoming funny is when trying to play efficiently with the osgViewer::Views attached to the CompositeViewer, when in a MFC context (read "context" here as "general application context", not as "graphics context"). Ideally, I would like not to have one Viewer per CView as in the cOSG class of the osgviewerMFC example, but one CompositeViewer shared by all the CViews of the active CChildFrame/opened CDocument. As an attempt, I thus put the CompositeViewer, OSG root node/group and render thread in the CChildFrame class, but couldn't get this to run smoothly (have a look at http://forum.openscenegraph.org/viewtopic.php?p=62278, most notably my two last comments about inserting a CSplitterWnd). Performance-wise, I don't know if this makes sense, but I also tried putting a unique CompositeViewer (and render thread) in the CWinApp, holding the osgViewer::Views of the various CViews of the various opened CChildFrames/CDocuments. I obviously kept the OSG root nodes/groups in the CChildFrames (keeping them in the the CDocuments may have been more appropriate). Not better: random crashes IIRC, potentially thread-related. If you have other MFC/OSG architectures in mind to share, welcome, as it seems we're only a few in this boat ;-) Émeric _______________________________________________ osg-users mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
