Re: [Opensg-users] OpenSG2: IntersectAction and VisitSubTree

[Johannes <JBrunen@DataSolid.de>]

Hello Carsten,

On 09.10.2013 17:14, Carsten Neumann wrote:

thank you for instantly replying my mail.

 >
 > hmm, I'm a bit unclear on this part and the related problem c) below.
 > Which class do the enter/leave callbacks belong to, your
 > CustomIntersectAction? What kind of housekeeping do you propose?
 >

Let me first explain an extension of the given IntersectAction that 
perhaps might work:

1. Add to the class a linear container (list, vector, stack) for nodes 
(_trackContainer) with the following semantics:

On traversal of the scene graph the current VisitSubTree core carrying 
node hierarchy is tracked. So this container might contain zero or more 
nodes of the scene graph branch at any time.

2. Add a hit state of the very same container type to the 
IntersectAction class (_hitContainer). This state is updated on 
successful hit only, i.e. if the current hit replaces the last one. In 
that case the container node hierarchy of 1. is copied to the hit state 
container.

On finishing of the IntersectAction apply call _hitContainer does 
contain zero or more VisitSubTree carrying nodes of the scene graph 
branch which corresponds to the evaluated hit.

Of course one could track all visited nodes of the branch but I see no 
value in doing that.

2. The IntersectAction class should of course contain an interface for 
evaluating of _hitContainer.

3. It should provide an interface for push and pop to the _trackContainer.

4. Provide an additional intersectLeave method to the VisitSubTree core.

5. The VisitSubTree core intersectEnter and intersectLeave methods would 
work with the IntersectAction _trackContainer interface. So at any time 
of the traversal the container would reflect to current VisitSubTree 
carrying node hierarchy.

6. Now at evaluating of the intersection the user is able to work 
through the _hitContainer to transition into the correct scene graph 
branch.


Ok that is the grande scheme I have in mind.


In case that I can't modify the IntersectAction I would like to derive 
from it instead. Writing a standalone IntersectAction2 is IMHO not 
feasible because one would have to provide all of the intersectEnter 
like callbacks. I have actually written a specialized selection action 
which is doing right that. But I have had to write handlers for all of 
the interesting core classes which naturally does not scale well.

If I work by deriving I still would have to provide intersectEnter and 
intersectLeave callbacks for the VisitSubTree core. That is, because I 
have an extra task to do (see 5. above).
These two callback would be implemented in the derived class. Here is 
the first weak point of the current design: Since the current 
VisitSubTree intersectEnter method is protected I'm unable to delegate 
to this handler. I would have to reimplement the functionality of the 
core class handler. :-(
The second problem is that I would have additionally to reimplement the 
setHit method virtually. :-(
Delegation to the base class setHit would be possible if this method 
would provide status information about its evaluation, i.e if a 
replacement of the current hit has happened.

>
> Actions can have a callback that is called on enter/leave of a node
> (independent of the core), see how IntersectAction::onNodeEnter() is
> used in OSGIntersectAction.cpp
> This allows tracking which nodes are entered/left; on finding a hit you
> could copy this path which should be enough information to correctly
> identify the hit object?
>...
> How about simply tracking the chain of nodes that form this path?
>
I do not see how I could intercept 'on finding a hit'. The action must 
traverse the complete graph and I would not have any information about 
the winning branch? Do I overlook something?

I hope that I could comprehensibly explain what I have in mind and that 
is makes any sense at all.

Best,
Johannes