Thank you Trajce.
On Thu, Nov 7, 2013 at 10:59 AM, Trajce Nikolov NICK <trajce.nikolov.n...@gmail.com> wrote: > Hi Deniz, > > yes I read Jan has mentioned this. Have a look in the osgdb_txp loader in > TXPNode::traverse() for inspiration if helps a bit > > Nick > > > On Thu, Nov 7, 2013 at 9:40 AM, Deniz Koçak <lend...@gmail.com> wrote: >> >> Hi Trajce, >> >> I think Jan's answer [1] in the first mail mentions a similar >> solution. Setting a flag (by using userdata of the drawable may be) >> and updating the drawable in the osg::Drawable::UpdateCallback (of >> course by checking the flag) MAY solve the problem. It seems that, >> thrusting the Qt's Signal/Slot mechanism is not a good option as Jan >> pointed. >> >> Cheers, >> Deniz >> >> >> >> [1] One way to solve this is to use the slot to only modify a buffer/set a >> flag and then use e.g. an update callback on the affected OSG node to >> pick up the changes and implement them in the scene graph when it is >> safe (during update traversal). >> >> On Thu, Nov 7, 2013 at 10:35 AM, Trajce Nikolov NICK >> <trajce.nikolov.n...@gmail.com> wrote: >> > Hi Jan, >> > >> > You can modify the scenegraph in the update traversal as well. Like I >> > did in >> > the TerraPage (txp) loader. In the Cull traversall I collect info for >> > what >> > is to be modified and then in the update traversal I update the >> > scenegraph >> > safely. >> > >> > Just a note >> > >> > Nick >> > >> > >> > On Thu, Nov 7, 2013 at 9:33 AM, Trajce Nikolov NICK >> > <trajce.nikolov.n...@gmail.com> wrote: >> >> >> >> Hi Jan, >> >> >> >> > Your approach isn't safe. OSG is *not threadsafe*. Or, rather, it is >> >> not threadsafe from arbitrary modifications. If you want to be safe, >> >> the only time when modifications to the scene graph may happen is >> >> before or after the frame() is invoked, not while frame() is running. >> >> >> >> >> >> >> >> On Wed, Nov 6, 2013 at 9:19 PM, Jan Ciger <jan.ci...@gmail.com> wrote: >> >>> >> >>> -----BEGIN PGP SIGNED MESSAGE----- >> >>> Hash: SHA1 >> >>> >> >>> Hello Deniz, >> >>> >> >>> On 11/06/2013 07:07 PM, Deniz Koçak wrote: >> >>> > This is already a long mail, still I have more to say, many code to >> >>> > post, but I am not sure where should I begin. I can provide as >> >>> > much as possible. However, before ending my e-mail, I would like to >> >>> > ask if this approach is safe or not? I mean, I call frame() method >> >>> > within a Qt slot and again update related datas within another Qt >> >>> > slot. Qt has a main loop (GUI thread) of course, and is it possible >> >>> > to cause a race-condition with OSG, because it has its own >> >>> > threading model? Please ask if you need more information and of >> >>> > course you will, I would be glad to tell more. >> >>> >> >>> Your approach isn't safe. OSG is *not threadsafe*. Or, rather, it is >> >>> not threadsafe from arbitrary modifications. If you want to be safe, >> >>> the only time when modifications to the scene graph may happen is >> >>> before or after the frame() is invoked, not while frame() is running. >> >>> >> >>> If your GUI is modifying the vertex array from the Qt slot, that is, >> >>> by definition, asynchronous - you have no idea when the user presses >> >>> that button. Which may well be during the rendering when OSG is using >> >>> that data structure. If you are clearing the vertex array while the >> >>> size of the array is still set, it will go boom. >> >>> >> >>> One way to solve this is to use the slot to only modify a buffer/set a >> >>> flag and then use e.g. an update callback on the affected OSG node to >> >>> pick up the changes and implement them in the scene graph when it is >> >>> safe (during update traversal). >> >>> >> >>> Regards, >> >>> >> >>> J. >> >>> -----BEGIN PGP SIGNATURE----- >> >>> Version: GnuPG v1.4.14 (GNU/Linux) >> >>> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ >> >>> >> >>> iD8DBQFSeqRWn11XseNj94gRAuBdAKDuE2rxjaXltXEWg4g2Mka1ZBqVIgCfbKju >> >>> vGG9MllrwxlDZjkUd1HHg+8= >> >>> =S3At >> >>> -----END PGP SIGNATURE----- >> >>> _______________________________________________ >> >>> osg-users mailing list >> >>> osg-users@lists.openscenegraph.org >> >>> >> >>> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org >> >> >> >> >> >> >> >> >> >> -- >> >> trajce nikolov nick >> > >> > >> > >> > >> > -- >> > trajce nikolov nick >> > >> > _______________________________________________ >> > 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 > > > > > -- > trajce nikolov nick > > _______________________________________________ > 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
