Hi Murray, I would not expect any performance hit beyond that of having to draw the scene twice. What scale of performance hit are you seeing?
While CompositeViewer doesn't present have support for stats, some changes to osgViewer I've just checked in should make support easier to add stats support as there is now much more common code between Viewer and CompositeViewer thanks to a new osgViewer::Renderer class now used by both - this class has support for camera stats. StatsHandler and CompositeViewer need some further mods before stats can be enabled, but this should only be a couple of hours work. W.r.t optimizing, using of a viewport for the insert View should not be expensive, its just adds an extra clear, the part that is probably adding the expense is simply the two cull and draw traversals, the only way to way to reduce this would be to using a move aggressive LODScale for the rear view mirror, this would allow objects to be represented at a lower level of detail cutting cull and draw costs. Another possible optimization would be to use DrawThreadPerContext or CullThreadPerCameraDrawThreadPerContext threading models, but, and this is a big but, only osgViewer::Viewer supports these threading models so far, CompositeViewer doesn't yet support them. The changes to use the new osgViewer::Renderer will also make it easier to add these threading models to CompositeViewer, but again CompositeViewer needs more work itself to support it. In the future it will be fully supported. For the timing being one could use osgViewer::Viewer in your case by making the rear-view mirror a slave Camera, or a nested Camera being placed in the scene graph. The osghud example should provide some inspiration as it has support for doing HUD as part of the scene graph, as part of osgViewer::Viewer as a slave Camera, or as a separate View in CompositeViewer. Robert. On 8/2/07, Murray Curtis <[EMAIL PROTECTED]> wrote: > I'm trying to include a rear view mirror view in my driving simulator > scene but and having trouble getting reasonable performance. > > I've recently converted from Producer to osgViewer and have set up two > views on a common graphics context, one full screen, the other smaller, > windowed over the other. Both share the same scene data but have > different (opposite facing) view matrices. It works just fine except > the performance cost. > > Its seems that CompositeViewer dosn't provide the useful statistic bar > graphs that viewer has so I'm uncertain where the hit is but I'm > guessing its the same cull/draw/gpu numbers again plus a little extra to > manage the two overlapping viewports. > > My first thought was I'd need to provide alternate scene data of a much > lower resolution. I made a utility based on osgSimplifier but even with > textures at 10% the original and geometry reduced by > 50% (by file > size) I get little if any improvement. I'm now exploring going further > back up the art path and producing lower res scene data there instead. > > Typically the scenes I have take around the same time for draw and GPU > and around 1/4 that for cull. > > Am I going about this in the right way? Any suggestions on a better > approach? Could the viewports be the expense? Would a pre-render > textured onto a quad be better? > > Many thanks > Murray Curtis > Tag Systems > www.tagsystems.com.au > > _______________________________________________ > osg-users mailing list > osg-users@lists.openscenegraph.org > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org > _______________________________________________ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
