Thanks for your answer Robert. The images I want to render are not bigger than normal images captured with a single camera. But in my special case I use several cameras (beginning from 16 up to 90) that render each only a small vertical strip of the scene. The width of each strip depends on the quantity of cameras and differs between 15 and 1 pixel. Finnally each frame is a combination of all the small vertical strips.
I think the number of calculations by rendering a lot of thin strips of a scene with several cameras is not so much higher than to render a normal-width image just with on camera. An Example: Rendering 90 strips with 1x700 pixel = 90x700 and Rendering 1 strip with 90x700 pixel = 90x700. I know that in reality it won't work so easy. But can you explain what exactly is the problem for the performance loss of the viewer. Is the CPU load to render each of the small strips compareable to the CPU load on rendering one big strip? So the CPU load increases with each camera assigned to the viewer no matter how wide the rendered stripe is? Anyway, if its not possible to get a large number of cameras work with OSG, I have to design a new concept of creating multiperspective images. Best regards, Tobias On 8/24/07, Robert Osfield <[EMAIL PROTECTED]> wrote: > > Hi Tobias, > > If you are generating 90 views all within on frame then you have 90 > cull traversals and 90 draw traversals, unless you scene is very > simple I would expect performance to be poor and will be particularly > CPU limited. > > What CompositeViewer provides is not so much performance improvement > across the board, but rather far better granularity of design. > Thrashing one camera 90 times in one frame just isn't good and will > preclude some attempts at optimization. > > On extra detail you added in your recent reply was the > "multiperspective" images, this suggest to me that actually you don't > necessarily want 90 logical views, and perhaps want you are after is > one logical view with a single master camera, and the actual rendering > composed of 90 slave cameras that provide the "multiperspectives". Is > this right? Then osgViewer::Viewer is probably more appropriate. > > One advantage of osgViewer::Viewer is that at present its further > ahead on the multi-threading curve than CompositeViewer in that it > supports CullThreadPerCameraDrawThreadPerContext, in your case this > would map to 90 threads for each camera cull, and one draw thread. It > would be rather overkill, but the Viewer class could easily be adapted > to also do the culls via a OperationQueue that is shared by a set of > thread - such as as having 3 threads handling 90 camera culls, and one > thread handling the draw. > > One further reflection perhaps the biggest bottleneck will be CPU > cache... Anyway not mentioning 90 views is a big thing... what you > are expecting gunning for is rather a tall order for a single CPU and > GPU. > > Robert. > > On 8/24/07, Tobias Münch <[EMAIL PROTECTED]> wrote: > > Hello Robert, hello at all > > > > This is a topic posted a few weeks ago. I want to render several views > (up > > to 90 views) within one frame and combine the results in a single > > RenderSurface or OSG window for instance. (the purpose is to generate > > multiperspective images) > > > > Robert recommended me to use OSG 2.0 CompositeViewer instead of > > osgProducer::Viewer because of better performance on dealing with > multiple > > views. After realizing prototypes for both viewers I cannot notice any > > performance improvement with CompositeViewer. > > > > To set up my CompositeViewer I created a lot of independet > osgViewer::Views. > > The master camera of each view renders its content to the dedicated area > in > > the viewer window. An Example: Using 45 different views there are 45 > master > > cameras and 45 different areas in the viewer window. > > > > Is there a possibilty to get better performance with OSG 2.0CompositeViewer > > when using such a large quantity of views and cameras? > > Maybe I do something wrong because I got no performance improvment with > > CompositeViewer. > > > > Best regards, Tobias > > > > > > On 8/2/07, Robert Osfield <[EMAIL PROTECTED]> wrote: > > > Hi Tobias, > > > > > > One shouldn't attempt to using a single camera between multiple views > > > within one frame. > > > > > > If you want an application with multiple views then the best place to > > > look for an example and classes supporting it 2.0. There is a new > > > osgViewer library that has a CompositeViewer class dedicated to role > > > of managing multiple views, its performance is excellent - there is no > > > additional performance hit with going with multiple views, and the > > > class itself provide the ability to share scene between different > > > views, or have different scenes in each view. There is also an > > > osgcompositeviewer example that illustrates how one manage the > > > different Views. > > > > > > Try to do multiple independent views 1.2/osgProducer/Producer is > > > technically possible for certain constrained usage models, but its > > > awkward and not well supported. > > > > > > Please go and try out 2.x and the osgcompositeviewer, it should just > > > solve your multiple view problems and do so in clean and logical way. > > > > > > Robert. > > > > > > On 8/2/07, Tobias Münch <[EMAIL PROTECTED]> wrote: > > > > Hello osg users > > > > > > > > I have a single camera that should render different views of a > scene > > within > > > > ONE FRAME. As result every frame should contain all rendered views > side > > by > > > > side. Therefor I set different projection rectangles and render > views > > > > (setViewByMatrix) to the camera while processing a frame. > > > > > > > > The problem is, that the function viewer.frame() or camera.frame() > > always > > > > render only for the last adjusted camera setting. > > > > > > > > Is there a solution to render the scene with one camera several > times > > > > within one frame? For instance by using the FrameBuffer...? > > > > > > > > > > > > > > > > I allready tried to solve the problem by using a couple of cameras > to > > > > render different views within one frame, but with very poor > performance > > and > > > > framerate. > > > > > > > > Thanks to all... > > > > Regards, Tobias > > > > > > > > _______________________________________________ > > > > 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 > > > > > > > > > _______________________________________________ > > 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 >
_______________________________________________ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
