Hi Steve,
There is a chance that is a threading issue - osgViewer threads even
for single camera/window apps, whereas osgProducer would run single
threaded in this case. The new DrawThreadPerContext will be picked
now by default if you have a multi-core machine, and provides better
performance virtue of allowing the main frame loops thread to overlap
with the graphics thread doing the rendering.
This threading model does bring in the problem of the main thread
modifying the scene whilest the scene is still being rendered, and the
way osgViewer tackles this issue is by using StateSet's and Drawable's
DataVariance field to know if an object being rendering might be
modified or not, i.e. is it DYNAMIC and STATIC, if its declared as
STATIC that it deems it safe to allow to run it in the rendering in a
parallel with the main thread as no-one will be modifiying it, the
draw thread ensures that no DYNAMIC objects are draw in parallel with
the main thread by keeping a count of objects that are DYNAMIC and
only releasing the main thread till all the DYNAMIC objects have been
rendered.
So... what does this mean for you? Easy, first select SingleThreading
by doing viewer.setThreadingModel(osgViewer::Viewer::SingleThreaded);
to make sure that it is indeed a threading issue, then if it is set
the DataVariance on the text object you are modifying to DYNAMIC, then
if things are working fine let the threading model go back to the
automatic selection which wil pick multi-threading if appropriate.
Robert.
On Jan 26, 2008 8:58 PM, Steve Schneider <[EMAIL PROTECTED]> wrote:
> Environment:
> Windows Vista Express C++ 2008
>
> Short History:
> CMAKE and built my own binaries.
> osgText sample didn't work - Rebuilt FreeType => Happy days.
>
> Take my project from 1.2 => pretty involved (for this 'bear with a little
> brain') => databasePager, geospecific terrain, HUD, Picking, etc
> Wouldn't compile -> Update my mouse handler via current osgPick
> specifically: use 'new'
> osgUtil::LineSegmentIntersector::Intersections::iterator
> Happy Days.
>
> Except it looks like on the first mouse-over that should send text to the
> screen I get:
> ----------------------------------------------------------------------------------
> Popup:
>
> Debug Assertion Failed!
> Program: c:\Source\ProjectOne\debug\ProjectOne.exe
> File: C:\Program Files\Microsoft Visual Studio 9.0\VC\include\xtree
> Line: 384
> Expression: map/set iterator not incrementable
> For information on how your program can cause an assertion
> failue, see the Visual C++ documentation on asserts.
> (Press Retry to debug the application)
> ---------------------------------------------------------------------------------------
> Call Stack:
>
> msvcp90d.dll!6bffc1b3()
> [Frames below may be incorrect and/or missing, no symbols loaded for
> msvcp90d.dll]
> >
> osg25-osgTextd.dll!std::_Tree<std::_Tmap_traits<osg::ref_ptr<osgText::Font::GlyphTexture>,osgText::Text::GlyphQuads,std::less<osg::ref_ptr<osgText::Font::GlyphTexture>
> >,std::allocator<std::pair<osg::ref_ptr<osgText::Font::GlyphTexture> const
> ,osgText::Text::GlyphQuads> >,0> >::const_iterator::_Inc() Line 384 + 0x17
> bytes C++
>
> osg25-osgTextd.dll!std::_Tree<std::_Tmap_traits<osg::ref_ptr<osgText::Font::GlyphTexture>,osgText::Text::GlyphQuads,std::less<osg::ref_ptr<osgText::Font::GlyphTexture>
> >,std::allocator<std::pair<osg::ref_ptr<osgText::Font::GlyphTexture> const
> ,osgText::Text::GlyphQuads> >,0> >::const_iterator::operator++() Line 275
> C++
>
> osg25-osgTextd.dll!std::_Tree<std::_Tmap_traits<osg::ref_ptr<osgText::Font::GlyphTexture>,osgText::Text::GlyphQuads,std::less<osg::ref_ptr<osgText::Font::GlyphTexture>
> >,std::allocator<std::pair<osg::ref_ptr<osgText::Font::GlyphTexture> const
> ,osgText::Text::GlyphQuads> >,0> >::iterator::operator++() Line 476 C++
> osg25-osgTextd.dll!osgText::Text::renderOnlyForegroundText(osg::State &
> state={...}, const osg::Vec4f & colorMultiplier={...}) Line 1974 + 0x8
> bytes C++
> osg25-osgTextd.dll!osgText::Text::drawImplementation(osg::State &
> state={...}, const osg::Vec4f & colorMultiplier={...}) Line 1593 C++
> osg25-osgTextd.dll!osgText::Text::drawImplementation(osg::RenderInfo &
> renderInfo={...}) Line 1477 C++
> osg25-osgd.dll!osg::Drawable::draw(osg::RenderInfo & renderInfo={...})
> Line 868 + 0x13 bytes C++
> osg25-osgUtild.dll!osgUtil::RenderLeaf::render(osg::RenderInfo &
> renderInfo={...}, osgUtil::RenderLeaf * previous=0x047a1118) Line 60 + 0x19
> bytes C++
> osg25-osgUtild.dll!osgUtil::RenderBin::drawImplementation(osg::RenderInfo
> & renderInfo={...}, osgUtil::RenderLeaf * & previous=0x047a1118) Line 408 +
> 0x19 bytes C++
> osg25-osgUtild.dll!osgUtil::RenderBin::draw(osg::RenderInfo &
> renderInfo={...}, osgUtil::RenderLeaf * & previous=0x047a1118) Line 373 +
> 0x17 bytes C++
> osg25-osgUtild.dll!osgUtil::RenderBin::drawImplementation(osg::RenderInfo
> & renderInfo={...}, osgUtil::RenderLeaf * & previous=0x047a1118) Line 458 +
> 0x35 bytes C++
>
> osg25-osgUtild.dll!osgUtil::RenderStage::drawImplementation(osg::RenderInfo
> & renderInfo={...}, osgUtil::RenderLeaf * & previous=0x047a1118) Line 1053
> C++
> osg25-osgUtild.dll!osgUtil::RenderBin::draw(osg::RenderInfo &
> renderInfo={...}, osgUtil::RenderLeaf * & previous=0x047a1118) Line 373 +
> 0x17 bytes C++
> osg25-osgUtild.dll!osgUtil::RenderStage::drawInner(osg::RenderInfo &
> renderInfo={...}, osgUtil::RenderLeaf * & previous=0x047a1118, bool &
> doCopyTexture=false) Line 722 C++
> osg25-osgUtild.dll!osgUtil::RenderStage::draw(osg::RenderInfo &
> renderInfo={...}, osgUtil::RenderLeaf * & previous=0x047a1118) Line 913 +
> 0x1b bytes C++
>
> osg25-osgUtild.dll!osgUtil::RenderStage::drawPostRenderStages(osg::RenderInfo
> & renderInfo={...}, osgUtil::RenderLeaf * & previous=0x047a1118) Line 1069
> + 0x2c bytes C++
> osg25-osgUtild.dll!osgUtil::RenderStage::draw(osg::RenderInfo &
> renderInfo={...}, osgUtil::RenderLeaf * & previous=0x047a1118) Line 979 +
> 0x17 bytes C++
> osg25-osgUtild.dll!osgUtil::SceneView::draw() Line 1454 + 0x34 bytes C++
> osg25-osgViewerd.dll!osgViewer::Renderer::draw() Line 382 + 0xf bytes C++
> osg25-osgViewerd.dll!osgViewer::Renderer::operator()(osg::GraphicsContext
> * context=0x04730228) Line 573 C++
> osg25-osgd.dll!osg::GraphicsContext::runOperations() Line 671 + 0x33
> bytes C++
> osg25-osgd.dll!osg::RunOperations::operator()(osg::GraphicsContext *
> context=0x04730228) Line 134 C++
> osg25-osgd.dll!osg::GraphicsOperation::operator()(osg::Object *
> object=0x04730228) Line 50 + 0x19 bytes C++
> osg25-osgd.dll!osg::OperationThread::run() Line 413 + 0x26 bytes C++
> osg25-osgd.dll!osg::GraphicsThread::run() Line 40 C++
> ot9-OpenThreadsd.dll!OpenThreads::ThreadPrivateActions::StartThread(void *
> data=0x04737c18) Line 112 + 0xf bytes C++
> msvcr90d.dll!6af5dfd3()
> msvcr90d.dll!6af5df69()
> kernel32.dll!76d93833()
> ntdll.dll!77aaa9bd()
> ------------------------------------------------------------------------------------------------------
>
> Sorry if the above is word-wrapped into mess :(
>
> So I basically cut and pasted code from the 1.2 examples into my own project
> and tailored them to fit. So the mouse-over code - the rubber hits the road
> with a call to 'SetLabel' which in the current osgPick is simply:
> if (_updateText.get()) _updateText->setText(name);
>
> Well my version is currently:
> dynamic_cast<osgText::Text*>(dynamic_cast<osg::Geode*>(_MainDisplay->asGroup()->getChild(0))->getDrawable(0))->setText(name);
>
> I have two HUD's - one to be a popup and the other remains visible at all
> times. The mouse-over text is to show in the always visible or
> '_MainDisplay' HUD. So this is my (perhaps insane) way to show the contents
> of 'name' on the screen in a mouse-over sort of fashion.
>
> It seems the first call fails consistantly.
> I have found that if I set a breakpoint on my dynamic_cast ...... line, then
> remove it and run - that it'll work for awhile.
> If I break everytime is seems to work.
>
> So any help on work arounds etc? Fixes? Pointers? I would be happy to
> send my current code, but I doubt that anyone would want to put in the
> investment in wrapping their minds around my insane code. It may be related
> to the aforementioned threading problem.
> http://article.gmane.org/gmane.comp.graphics.openscenegraph.user/23380/match=xtree
>
> If so - please let me know and I'll stop pulling my hair out.
>
> Thanks.
>
> -Steve Schneider
>
> ________________________________
> Never miss a thing. Make Yahoo your homepage.
> _______________________________________________
> 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
