I apologize for following up on my own follow-up, but I made some progress with this. The gist of it is that I am now merging the change list from each of the externally spawned threads into the main application change list. This appears to have solved the problems I was seeing, though I cannot say for sure that my approach is optimal. See below for details about what I did.
Patrick Hartling wrote:
> 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);
First, I have extended the above to register each OSG::ExternalThread
pointer with my application core.
> 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.
With regarding to "anything more that I need to be doing," I have added the
following code that is executed in my main application loop just prior to
the custom remote aspect syncing:
std::vector<OSG::ThreadCommonBase*>::iterator t;
for ( t = mExtThreads.begin(); t != mExtThreads.end(); ++t )
{
OSG::ChangeList* cl = (*t)->getChangeList();
OSG::Thread::getCurrentChangeList()->merge(*cl);
cl->clearAll();
}
Does this look reasonable? It gives me the desired visual result, and I hope
that it manages the change lists properly.
-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
