Hi Francesco, > Dirk Reiners ha scritto: >> Hi Marco, >> >> Marco Spoerl wrote: >>> In my application (based on OpenSG 1.8), I use a single FBOViewport with >>> changing TextureChunks. Which should be pretty much like a solution >>> mentioned here: >>> >>> http://www.mail-archive.com/[email protected]/msg08847.html >>> >>> My FBOViewport is created as follows: >>> >>> // ----- >>> m_pViewportPass2 = OSG::FBOViewport::create(); >>> OSG::beginEditCP(m_pViewportPass2); >>> m_pViewportPass2->setParent(pWindow); >>> m_pViewportPass2->setRoot(pRootNode); >>> m_pViewportPass2->setBackground(pBackground); >>> m_pViewportPass2->setCamera(pCamera); >>> m_pViewportPass2->setSize(0, 0, m_width - 1, m_height - 1); >>> m_pViewportPass2->setStorageWidth(m_width); >>> m_pViewportPass2->setStorageHeight(m_height); >>> m_pViewportPass2->setGenCubemaps(false); >>> m_pViewportPass2->setGenDepthmaps(false); >>> m_pViewportPass2->setFboOn(true); >>> m_pViewportPass2->setDirty(true); >>> OSG::endEditCP(m_pViewportPass2); >>> // ----- >>> >>> Each time I use that viewport to grab something, the following code is >>> executed: >>> >>> // ----- >>> OSG::beginEditCP(m_pViewportPass2); >>> m_pViewportPass2->getTextures().push_back(pTexture); >>> OSG::endEditCP(m_pViewportPass2); >>> >>> m_pViewportPass2->render(pAction); >>> >>> OSG::beginEditCP(m_pViewportPass2); >>> m_pViewportPass2->getTextures().clear(); >>> OSG::endEditCP(m_pViewportPass2); >>> // ----- >>> >>> This leads to a massive memory leak. Each call to "render" allocates a >>> block roughly the size of the image attached to "pTexture", which is >>> never freed again. >>> >>> After narrowing down the problem to the changing textures, I tried to >>> attach only one single fixed texture chunk, which eliminates the memory >>> issue. But then I have the problem that I don't get any of the image >>> data I need (to save to a file), i.e. I only get black textures. To get >>> the rendered image out of the FBO and into the "pTexture", I tried both >>> solutions from >>> >>> http://www.mail-archive.com/[email protected]/msg08846.html >>> >>> with and without setFboOn and setReadBuffer. >>> >>> Any hints how to get the data I need without the leaks? >>> >> Hm. Can you try to explicitly delete the textures (i.e. loop over the >> getTextures() array and subRef each of them)? That shouldn't be >> necessary, but it's the only thing I can think of. >> >> Yours >> >> Dirk > > yes... it is the same thing that happens with chunks in chunkmaterials, > as described in the "memleak tutorial", now accessible from google cache: > > http://209.85.135.104/search?q=cache:EDGd29vUxVcJ:opensg.vrsource.org/trac/wiki/Tutorial/OpenSG1/Memleak+opensg+memleak+tutorial&hl=it&ct=clnk&cd=1&gl=it
well not really a bug if you mess around with chunks in a ChunkMaterial you should call mat->clearChunks() and not mat->getChunks().clear() Andreas > cheers > > francesco > > ------------------------------------------------------------------------- > This SF.Net email is sponsored by the Moblin Your Move Developer's challenge > Build the coolest Linux based applications with Moblin SDK & win great prizes > Grand prize is a trip for two to an Open Source event anywhere in the world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > _______________________________________________ > Opensg-users mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/opensg-users > -- VREC Robert-Bosch-Straße 7 D-64293 Darmstadt Tel. 06151-4921035 ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ Opensg-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/opensg-users
