Something just occurred to me after thinking about Terry Welsh's question regarding multiple aspects. In my first message, I described two cases in which OSG::Node::setActive() is invoked. What I failed to mention is that the case that works occurs in the application loop whereas the case that fails occurs in a separate thread.
The separate thread is known to OpenSG, though OpenSG did not spawn the
thread. Every time an external thread is spawned, I use the following to
register the thread with OpenSG:
OSG::ExternalThread* ext_thread = OSG::ExternalThread::get(NULL);
ext_thread->initialize(gMainAspectId);
gMainAspectId is a global initialized in the application loop as follows:
gMainAspectId = OSG::Thread::getAspect();
I also should have stated that my code has its own use of OpenSG remote
aspects and does not use multi-display windows. The code for syncing the
aspects has worked fine thus far in a few different applications, though my
use of externally spawned threads is something that may be exposing bugs in
the custom aspect management.
Is there anything more that I need to be doing to allow scene graph
changes--properly wrapped in begin/endEditCP() calls--in the externally
spawned threads to be distributed to the remote aspects? My assumption had
been that OpenSG was doing everything necessary on its own to handle the
changes from the externally spawned threads since everything worked like a
charm in the single-machine case.
-Patrick
Patrick Hartling wrote:
> The behavior is the same with and without the field mask.
>
> -Patrick
>
> Andreas Zieringer wrote:
>> Hi Patrick,
>>
>> can you try it without a specific field mask.
>>
>> ....
>> OSG::beginEditCP(mNode);
>> mNode->setActive(active);
>> OSG::endEditCP(mNode);
>>
>> Andreas
>>
>>> I am running into an unexpected problem changing the traversal mask on
>>> OSG::Node instances when using OpenSG clustering. Consider the
>>> following graph:
>>>
>>> Root
>>> / | \
>>> / | \
>>> / | \
>>> / | \
>>> / | \
>>> Child0 Child1 Child2
>>>
>>> The code I am using to change the active state of nodes is (basically) as
>>> follows:
>>>
>>> class MyClass
>>> {
>>> public:
>>> void setActive(const bool active)
>>> {
>>> OSG::beginEditCP(mNode, OSG::Node::TravMaskFieldMask);
>>> mNode->setActive(active);
>>> OSG::endEditCP(mNode, OSG::Node::TravMaskFieldMask);
>>> }
>>>
>>> private:
>>> OSG::NodeRefPtr mNode;
>>> };
>>>
>>> If Root is inactive and the children of Root are active, calling
>>> Root->setActive(true) works fine. However, if Root is active and its
>>> children are inactive, calling ChildN->setActive(true) has no effect
>>> on the
>>> server nodes. Only the client node where the scene graph manipulations
>>> are
>>> performed directly shows the change.
>>>
>>> I am using the CVS HEAD version of OpenSG built from yesterday's
>>> sources. I
>>> see the problem with the client and server on Windows or with the
>>> client on
>>> Windows and the server on Mac OS X (I expect that reversing the roles in
>>> this case would exhibit this behavior, too). I have not tried Linux.
>>>
>>> My code works fine in the single-machine case, and I don't see any
>>> obvious
>>> place where I have forgotten begin/endEditCP() calls. I cannot rule that
>>> out, but the scene graph looks correct on all nodes so far. The traversal
>>> mask change just doesn't seem to propagate.
>>>
>>> Have I made any bogus assumptions about how changing the traversal mask
>>> should work? Or am I misunderstanding how to use OSG::Node::setActive()?
>>>
>>> -Patrick
>
>
--
Patrick L. Hartling | VP Engineering, Infiscape Corp.
PGP: http://tinyurl.com/2msw3 | http://www.infiscape.com/
signature.asc
Description: OpenPGP digital signature
