On Thu, Jul 15, 2010 at 8:54 AM, J.P. Delport <[email protected]> wrote:
> Hi,
>
> have you tried different threading models to see if it makes any
> difference?
>
> jp
>
>
> To pursue further where J.P. is going with this, what you're doing is not
going to work in any of the multi-threaded modes and is a bad idea in
general. What you might be missing is that mt->getOrCreateStateSet() is, for
each matrix transform, returning the same state set after the initial frame.
You're mutating a StateSet object that might be in use in a draw thread. At
the very least you should call setDataVariance(osg::Object::DYNAMIC) on
those state sets. That implies creating the state sets at startup and using
getStateSet() in the callback instead of getOrCreateStateSet().
A slightly better approach is to allocate the state sets and materials ahead
of time and put an update callback on the material itself, remembering to
set the data variance on the material. You need to be careful not to share
state sets within the scene graph, otherwise it's not predictable which
material attribute setting will actually take effect. Even better would be
to track yourself the state sets / materials that need updating and set them
outside of a scene graph traversal.
Tim
> On 15/07/10 08:09, Tom Pearce wrote:
>
>> Hi,
>>
>> Let me preface this by saying that I know how to make my code do what I
>> want it to, so this question is of low importance and arises from doing
>> something that could(should?) be considered silly- dynamic allocation
>> within a callback operator method when the callback can have a class member
>> instead. However, I'm still curious about the behavior, and/or if others
>> see this in a different way than I do.
>>
>> What I'm seeing (code below produces this on my two setups): The second
>> sphere (which should always be green) flickers red. Uncommenting the
>> traverse line in the operator method makes the flickering noticably worse.
>> The flicker color being red is not a coincidence, it flickers whatever
>> color the first sphere is.
>>
>> Making 'mat' a class member of the derived callback instead of creating a
>> 'new' version of it eliminates this problem. As I said, this fixes my
>> problem... but even if dynamically allocating a new Material each time is
>> inefficient, I was still surprised at the flickering behavior. In my quest
>> to learn more about all of this, I thought I'd see if anyone could enlighten
>> me as to what's going on.
>> Two questions:
>> 1) Why is one sphere flickering when a new Material (ref_ptr or plain
>> non-smart pointer) is created in the callback?
>> 2) Why does calling traverse within the operator method (as the Quick
>> Start Guide indicates) make the flickering worse?
>>
>> I'm using XP/VisStudio2008Express on one machine, and Windows7/VisStudio9
>> on another, osg 2.8.2 on both, just in case it matters.
>>
>> Thoughts?
>>
>> ,
>>
>
>
> Code:
>> class MyCallback : public osg::NodeCallback
>> {
>> public:
>> MyCallback(osg::Vec4 c){color=c;}
>> virtual void operator()(osg::Node* n, osg::NodeVisitor* nv)
>> {
>> osg::ref_ptr<osg::MatrixTransform> mt =
>> dynamic_cast<osg::MatrixTransform*>(n);
>> osg::ref_ptr<osg::Material> mat = new osg::Material();
>> mat->setDiffuse(osg::Material::FRONT, color);
>> mt->getOrCreateStateSet()->setAttribute(mat);
>> //traverse(n, nv);
>> }
>> protected:
>> osg::Vec4 color;
>> };
>>
>> int _tmain(int argc, char * argv[])
>> {
>> osg::ref_ptr<osg::Group> root = new osg::Group();
>> osg::ref_ptr<osg::Geode> sphere = new osg::Geode();
>> sphere->addDrawable(new osg::ShapeDrawable(new osg::Sphere(osg::Vec3(0.,
>> 0., 0.), 0.1)));
>> osg::Vec4 color1, color2;
>> color1.set(1., 0., 0., 0.);
>> color2.set(0., 1., 0., 0.);
>> {
>> osg::ref_ptr<osg::MatrixTransform> mt = new osg::MatrixTransform();
>> root->addChild(mt);
>> mt->addChild(sphere);
>> mt->setMatrix(osg::Matrix::translate(-.1, 0., 0.));
>> mt->setUpdateCallback(new MyCallback(color1));
>> }
>> {
>> osg::ref_ptr<osg::MatrixTransform> mt = new osg::MatrixTransform();
>> root->addChild(mt);
>> mt->addChild(sphere);
>> mt->setMatrix(osg::Matrix::translate(0.1, 0., 0.));
>> mt->setUpdateCallback(new MyCallback(color2));
>> }
>> osgViewer::Viewer v;
>> v.setSceneData(root);
>> v.getCamera()->setViewMatrixAsLookAt(osg::Vec3(0., -.500, 0.),
>> osg::Vec3(0., 0., 0.), osg::Vec3(0., 0., 1.));
>> v.setUpViewInWindow(750, 550, 600, 400, 0);
>> while(!v.done())
>> {
>> v.frame();
>> }
>>
>> return 0;
>> }
>>
>>
>>
>>
>>
>> Cheers,
>> Tom
>>
>> ------------------
>> Read this topic online here:
>> http://forum.openscenegraph.org/viewtopic.php?p=30012#30012
>>
>>
>>
>>
>>
>> _______________________________________________
>> osg-users mailing list
>> [email protected]
>> 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
> [email protected]
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>
_______________________________________________
osg-users mailing list
[email protected]
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
