[osg-users] CompositeViewer context cleanup and missing textures

J.P. Delport jpdelport at csir.co.za
Tue Nov 24 07:17:19 PST 2009


Hi Frederic,

Drolet, Frederic wrote:
> Hello J.P.,
> 
> I see it's a good thing this thread got my attention! I have similar
> missing texture issues in another application that creates and
> deletes window contexts applied to viewer slaves (also created and
> deleted dynamically). Here's the way we create our textures:
> 
> osg::ref_ptr<osg::Texture2D> lTex = new osg::Texture2D; 
> lTex->setDataVariance(osg::Object::DYNAMIC);
> 
> // load an image by reading a file: CString lIconFileName =
> (...)TextureFilename + ".png"; osg::Image* lIconImage =
> osgDB::readImageFile(lIconFileName.GetBuffer());
> 
> // Assign the texture to the image we read from file: 
> lTex->setImage(lIconImage);
> 
> // Make sure the texture is not unreferenced in memory after it's
> applied in GL states lTex->setUnRefImageDataAfterApply(false);
> 
> Unfortunately, my understanding of OpenGL is relatively limited but I
> know this last line of code is crucial for dynamical views handling
> to maintain the texture in user memory for later access. However,
> even with this, it happens sometimes that the texture disappear after
> a few create and delete views operations (sometimes, the textures is
> on a view but not on another!). It happens most of the time with
> objects loaded from file. Since we don't have direct access to the
> textures, we can't make the call to setUnRefImageDataAfterApply().
> Would there be another way?

I'm not sure, but I think only the DB pager, optimiser and some plugins 
switch automatically to auto unref. Maybe try disabling the optimiser.

> 
> Now, as for the modified CompositeViewer example, I tried it on
> Windows Vista and it simply crashes the first time I hit ESC or the X
> button. In fact, the problem occurs during the second call to
> viewer.run(). First, I simply tried to add a sleep before the
> viewer's deletion to wait for potential asynchronous cleanup stuff
> after the call to the viewer's run() method but it didn't work.

What version of OSG?

> 
> Then, I did a little debug job to find out that the second time the
> viewer is created, the application crashes during the rendering
> traversal of the first call to frame() in the run thread loop. More
> precisely the application crashes in osgUtil::ScreneView::init() the
> first time the cull_draw operation is launched. Here's the call
> stack:
> 
> ntdll.dll!778f9a94() [Frames below may be incorrect and/or missing,
> no symbols loaded for ntdll.dll] ntdll.dll!778f92c4() 
> kernel32.dll!76a5e87b() nvoglv32.dll!69638b8f() 
> nvoglv32.dll!695a15d0()
>> osg55-osgd.dll!osg::getGLVersionNumber()  Line 48 + 0xd bytes	C++
> osg55-osgd.dll!osg::isGLExtensionOrVersionSupported(unsigned int
> contextID=0, const char * extension=0x5ac7a277, float
> requiredGLVersion=3.4028235e+038)  Line 82 + 0x5 bytes	C++ 
> osg55-osgd.dll!osg::isGLExtensionSupported(unsigned int contextID=0,
> const char * extension=0x5ac7a277)  Line 73 + 0x17 bytes	C++ 
> osg55-osgUtild.dll!osgUtil::SceneView::init()  Line 312 + 0x2d bytes
> C++ osg55-osgUtild.dll!osgUtil::SceneView::draw()  Line 1026 + 0x1d
> bytes	C++ osg55-osgViewerd.dll!osgViewer::Renderer::cull_draw()  Line
> 588 + 0xf bytes	C++ 
> osg55-osgViewerd.dll!osgViewer::Renderer::operator()(osg::GraphicsContext
> * context=0x023591b0)  Line 689 + 0xf bytes	C++ 
> osg55-osgd.dll!osg::GraphicsContext::runOperations()  Line 688 + 0x33
> bytes	C++ 
> osg55-osgViewerd.dll!osgViewer::ViewerBase::renderingTraversals()
> Line 772 + 0x15 bytes	C++ 
> osg55-osgViewerd.dll!osgViewer::ViewerBase::frame(double
> simulationTime=1.7976931348623157e+308)  Line 609 + 0xf bytes	C++ 
> osg55-osgViewerd.dll!osgViewer::ViewerBase::run()  Line 581 + 0x1b
> bytes	C++ osg55-osgViewerd.dll!osgViewer::CompositeViewer::run()
> Line 233	C++ osgcompositeviewerd.exe!main(int argc=3, char * *
> argv=0x02330ed8)  Line 311 + 0xf bytes	C++ 
> osgcompositeviewerd.exe!__tmainCRTStartup()  Line 582 + 0x19 bytes	C 
> osgcompositeviewerd.exe!mainCRTStartup()  Line 399	C 
> kernel32.dll!76a94911() ntdll.dll!778de4b6() ntdll.dll!778de489()
> 
> I forced the single thread mode (the only thing on the command line
> was the filename of my 3D model).
> 
> By the way, is there a better solution to wait for the viewer
> completion after the run() method?

When run completes I would hope it's done, I don't know of other ways.

> 
> What OS are you using? Maybe I should try on XP to see if it does the
> same thing.

J-S tried on Vista and it worked with latest OSG svn. I'm on Debian Sid 
32-bit.

jp

> 
> Hope we can help each other!
> 
> Cheers,
> 
> Frederic Drolet, M. Sc. Computing Solutions and Experimentations |
> Solutions informatiques et expérimentations Systems of Systems |
> Systèmes de systèmes DRDC Valcartier | RDDC Valcartier 2459, boul.
> Pie-XI North Quebec, Quebec G3J 1X5 CANADA Phone | Téléphone: (418)
> 844-4000 ext : 4820 Fax | Télécopieur: (418) 844-4538 E-mail |
> Courriel: frederic.drolet at drdc-rddc.gc.ca Web :
> www.valcartier.drdc-rddc.gc.ca
> 
> -----Original Message----- From:
> osg-users-bounces at lists.openscenegraph.org
> [mailto:osg-users-bounces at lists.openscenegraph.org] On Behalf Of J.P.
> Delport Sent: November-24-09 8:53 AM To: OpenSceneGraph Users 
> Subject: Re: [osg-users] CompositeViewer context cleanup and missing
> textures
> 
> Hi,
> 
> Robert Osfield wrote:
>> Hi J.P.
>> 
>> I'm still knee deep in merging submissions so can't yet go off 
>> reviewing user code.  In principle it is possible to mange open and
>>  closing viewers.  I can point you in the right direction but have
>> to let you get on with it otherwise.
> 
> I understand, I'll try search for cleanup code, just not sure where
> to start.
> 
> Anyone else?
> 
> jp
> 
>> Robert.
>> 
>> On Tue, Nov 24, 2009 at 12:32 PM, J.P. Delport
>> <jpdelport at csir.co.za> wrote:
>>> Hi Robert,
>>> 
>>> Robert Osfield wrote:
>>>> Hi J.P,
>>>> 
>>>> The typical problem is that the scene graph has been set up to
>>>> unref texture images after apply so when it comes to reloading
>>>> the texture images there aren't the to download.
>>> should this still happen when I'm completely reloading a scene
>>> after the viewer and scene have been deleted completely?
>>> 
>>> It seems that OSG thinks there is still a valid texture it can
>>> use after I've deleted the scene and CompositeViewer.
>>> 
>>> Running the attached e.g.: ./test cow.osg
>>> 
>>> Constructing PixelBufferObject for image=0x9547928 
>>> _maxTexturePoolSize=0 _maxBufferObjectPoolSize=0 Created new
>>> TextureObject, _numOfTextureObjects 1 Created new TextureObject,
>>> _numOfTextureObjects 1
>>> 
>>> now I click the X on the window and the app deletes the scene and
>>> viewer and creates them anew:
>>> 
>>> _maxTexturePoolSize=0 _maxBufferObjectPoolSize=0 Reusing
>>> orhpahned TextureObject, _numOfTextureObjects=1 Warning: detected
>>> OpenGL error 'invalid value' after RenderBin::draw(,) Reusing
>>> orhpahned TextureObject, _numOfTextureObjects=1 Warning: detected
>>> OpenGL error 'invalid value' after RenderBin::draw(,)
>>> 
>>> So it tries to reuse something that's not there? How can I
>>> convince OSG to drop all caches/buffers/GL objects?
>>> 
>>> jp
>>> 
>>> 
>>>> Robert.
>>>> 
>>>> On Tue, Nov 24, 2009 at 9:17 AM, J.P. Delport
>>>> <jpdelport at csir.co.za> wrote:
>>>>> Hi all,
>>>>> 
>>>>> I've run into the classic "missing textures" problem when
>>>>> stopping and restarting a compositeviewer multiple times in
>>>>> the same app. From previous threads on this problem it seems
>>>>> to be context cleanup/GL object cleanup that does not get
>>>>> done properly, but I'm just using the normal CompositeViewer
>>>>> and not messing with contexts/windows/sceneviews myself, so I
>>>>> thought the cleanup would be handled correctly.
>>>>> 
>>>>> Attached a very slightly modified compositeviewer example.
>>>>> All it does is create/destruct the compositeviewer 5 times.
>>>>> When the viewer is created for the second time, all my
>>>>> textures are gone (just run without any arguments).
>>>>> 
>>>>> Can anyone confirm the missing textures? Any hints as to what
>>>>> else needs to be done to make sure everything is
>>>>> cleared/flushed correctly?
>>>>> 
>>>>> thanks jp
>>>>> 
>>>>> -- This message is subject to the CSIR's copyright terms and
>>>>> conditions, e-mail legal notice, and implemented Open
>>>>> Document Format (ODF) standard. The full disclaimer details
>>>>> can be found at http://www.csir.co.za/disclaimer.html.
>>>>> 
>>>>> This message has been scanned for viruses and dangerous
>>>>> content by MailScanner, and is believed to be clean.
>>>>> MailScanner thanks Transtec Computers for their support.
>>>>> 
>>>>> 
>>>>> _______________________________________________ osg-users
>>>>> mailing list osg-users at lists.openscenegraph.org 
>>>>> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>>>>> 
>>>>> 
>>>>> 
>>>> _______________________________________________ osg-users
>>>> mailing list osg-users at lists.openscenegraph.org 
>>>> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>>>> 
>>>> 
>>> -- This message is subject to the CSIR's copyright terms and
>>> conditions, e-mail legal notice, and implemented Open Document
>>> Format (ODF) standard. The full disclaimer details can be found
>>> at http://www.csir.co.za/disclaimer.html.
>>> 
>>> This message has been scanned for viruses and dangerous content
>>> by MailScanner, and is believed to be clean.  MailScanner thanks
>>> Transtec Computers for their support.
>>> 
>>> 
>>> _______________________________________________ osg-users mailing
>>> list osg-users at lists.openscenegraph.org 
>>> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>>> 
>>> 
>>> 
>> _______________________________________________ osg-users mailing
>> list osg-users at lists.openscenegraph.org 
>> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>> 
> 

-- 
This message is subject to the CSIR's copyright terms and conditions, e-mail legal notice, and implemented Open Document Format (ODF) standard. 
The full disclaimer details can be found at http://www.csir.co.za/disclaimer.html.

This message has been scanned for viruses and dangerous content by MailScanner, 
and is believed to be clean.  MailScanner thanks Transtec Computers for their support.



More information about the osg-users mailing list