Hello Carsten, did you have the chance to investigate this issue in detail?
Beside this we have a problem with the rendering time of the current "double window" solution as both windows are rendered after each other. May you can give me a hint what might be a more suitable solution? I'll try to describe what this is used for. We have a VR system that builds on OpenSG. At the moment we use a PassiveWindow to render on desktop systems and a MultiDisplayWindow to render in VE's like CAVE. We have the requirement to add a second orthographic view on a seperate machine. As you know we're using MultiDisplayWindow to render this view beside the above named main application window. Rendering is called successive for the two windows. I thought about adding an additional viewport with an ortho camera to our main window. This could be straight forward if we are rendering for a multidisplay configuration but means in case of a desktop application that have to switch from PassiveWindow to MultiDisplayWindow, too. Does this have any disadvantages or performance effects? Thanks for help, Michael -------- Original-Nachricht -------- > Datum: Tue, 09 Mar 2010 21:14:01 -0600 > Von: Carsten Neumann <carsten_neum...@gmx.net> > An: opensg-users@lists.sourceforge.net > Betreff: Re: [Opensg-users] MultiDisplayWindow Problem (1.8) > Hello Michael, > > Michael Raab wrote: > > the 8 light sources form a chain. Unfortunately I don't have a debug > version of OpenSG here. For your information I have exported my whole test > scene to an osb file, which is attached to this mail. Hope this helps to find > the problem. The test scene looks like this: > > > [SNIP - scene graph] > > > - The first node is our root > > - Followed by all 8 light sources > > - Below the light source comes our test object, a simple cube > > - The last 8 transform nodes are used as light source beacons > > > > If you wish I can try to copy the relevant source code parts from our > application. > > hm, I've loaded the .osb with the two of the test programs > (testStatisticsRender and testVRMLRender - which is not really VRML > specific...). Both already add a light to scene so there were complaints > from OpenGL about unknown enums, when GL_LIGHT0 + 8 was passed to > glEnable for the last (9th total) light in your scene - which is ok and > expected. > A bit strange was that only one of the two programs actually complained > from the RenderAction, which normally already detects if there are more > lights than OpenGL can handle in a scene. So it seems that there is > possibly something wrong with the way lights are counted, but I've not > had a chance to investigate it yet, sorry. > > Cheers, > Carsten > > ------------------------------------------------------------------------------ > Download Intel® Parallel Studio Eval > Try the new software tools for yourself. Speed compiling, find bugs > proactively, and fine-tune applications for parallel performance. > See why Intel Parallel Studio got high marks during beta. > http://p.sf.net/sfu/intel-sw-dev > _______________________________________________ > Opensg-users mailing list > Opensg-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/opensg-users -- GMX DSL: Internet, Telefon und Entertainment für nur 19,99 EUR/mtl.! http://portal.gmx.net/de/go/dsl02 ------------------------------------------------------------------------------ Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev _______________________________________________ Opensg-users mailing list Opensg-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/opensg-users
