Hi Dirk, yes that kind of issue has cost some efforts. Sorry for that.
Recreating the entire window should be in principle the easiest solution. Unfortunately our main window is used both for local and for cluster rendering. So in the case that there is an immersive environment or some other external display connected, a simple destruction and recreation will also kill the network and remote stuff. What I tried today was to destroy/recreate all ShadowViewports after the new GL context was created and window->reinitializeAllGLObjects() was called. That method produces just no rendered image. Using gDEBugger I was able to capture that there are 3 textures assigned to the GL context but all of them have a size of 0x0. I thought that a new ShadowViewport should create the necessary texture and FBO resources from scratch... May be the old ShadowViewport's resources were deleted/freed to late and may have damaged the new ones. Just a guess... Do you think this approach should work in general or do I miss something? Have a nice weekend! Thanks, Michael -------- Original-Nachricht -------- > Datum: Thu, 02 Feb 2012 10:21:54 -0600 > Von: Dirk Reiners <dirk.rein...@gmail.com> > An: opensg-users@lists.sourceforge.net > CC: dirk.rein...@gmail.com > Betreff: Re: [Opensg-users] OpenSG1.8 - Problem with ShadowViewport > > Hi Michael, > > On 02/02/2012 09:24 AM, Michael Raab wrote: > > Hello Carsten, > > > > thanks for the patch, but that seems not to help very much... > > I did the following test: > > - Render scene with Dither Shadow and 1 shadow light -> example 1 > > - Destroy GL context and create new GL context > > - Call reinitializeAllGLObjects() for my window > > - Render scene with Dither Shadow and 1 shadow light -> example 2 > > - Move the camera a bit around > > - Render scene with Dither Shadow and 1 shadow light -> example 3 > > > > In example 1, the DitherShadowMap seems to use two textures, 1 for the > scene (unit 0) and 1 for the shadow map information (unit 1). > > After creating a new GL context there seems to be no shadow map bound > anymore and the map used for the scene seems to be somehow random... > > > > Regarding its size, I'll send you the example data off the list. > > Hope it helps... > > I see a lot of effort spent on trying to handle a case that was not really > in > our minds when we designed OpenSG, and that is destroying and recreating > OpenGL > contexts behind the scenes. > > If you're doing these expensive operations anyway, is there a reason > you're not > just destroying and recreating the OpenSG windows and viewports, too? That > way > OpenSG is aware that everything has changed, and can do the > initializations > necessary. That should be more robust than trying to shoehorn the > reinitialization into the system somehow... > > Just my $.02 > > Dirk > > ------------------------------------------------------------------------------ > Keep Your Developer Skills Current with LearnDevNow! > The most comprehensive online learning library for Microsoft developers > is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, > Metro Style Apps, more. Free future releases when you subscribe now! > http://p.sf.net/sfu/learndevnow-d2d > _______________________________________________ > Opensg-users mailing list > Opensg-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/opensg-users -- Empfehlen Sie GMX DSL Ihren Freunden und Bekannten und wir belohnen Sie mit bis zu 50,- Euro! https://freundschaftswerbung.gmx.de ------------------------------------------------------------------------------ Try before you buy = See our experts in action! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-dev2 _______________________________________________ Opensg-users mailing list Opensg-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/opensg-users
