opensg-users

[Opensg-users] OpenSG2: IntersectAction and VisitSubTree

[Johannes B. <jb...@da...>]

Hello,

 

For reason of complex model parts I have started to replace my NodeCore
sharing strategy by usage of the VisitSubTree core. Unfortunately, now I
have problems with the intersection action code. On applying my scene to
a IntersectAction instance I get a hit for my visited geometry. That is
fine. However, on evaluation of the intersection hit I do not know in
which one of the VisitSubTree branches the intersection actually
occurred (provided that I have multiple VisitSubTrees for the same
geometry).

 

What I would like to do, is the following:

 

1. Derive a new IntersectAction class from IntersectAction.

2. virtually override the setHit function.

3. provide enter and leave callbacks for the VisitSubTree core which
basically delegate to the VisitSubTree implementation but perform a
little housekeeping with respect to the VisitSubTree carrying node.

4. On an actual winning hit event,  remember the current VisitSubTree
carrying node if any.

 

In case that this scheme does work in theory the following principle
show stoppers exists:

 

a) the setHit function is not virtual declared in IntersectAction.

b) a derived class from IntersectAction does not have access to the
_hit* state.

c) providing extra enter and leave callbacks does not allow delegation
inside their implementation since the intersectEnter methods of the
NodeCores are declared in the protected section.

 

So basically, I have the following questions:

 

- Are there any other known ideas for intersection with VisitSubTree
shared sub scenes, i.e. for finding the actual VisitSubTree carrying
node for the winning intersection?

- Is there any support for designing the IntersectAction more
customizable?

- How can this best be done?

- Does my approach have apparent flaws which I do not see, but you? :-)

 

Any help is very appreciated.

 

Best,

Johannes

 

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

[Carsten N. <car...@gm...>]

	Hello Johannes,

On 10/09/2013 09:52 AM, Johannes Brunen wrote:
> What I would like to do, is the following:
> 1. Derive a new IntersectAction class from IntersectAction.
>
> 2. virtually override the setHit function.
>
> 3. provide enter and leave callbacks for the VisitSubTree core which
> basically delegate to the VisitSubTree implementation but perform a
> little housekeeping with respect to the VisitSubTree carrying node.

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?

> 4. On an actual winning hit event,  remember the current VisitSubTree
> carrying node if any.
>
> In case that this scheme does work in theory the following principle
> show stoppers exists:
>
> a) the setHit function is not virtual declared in IntersectAction.
>
> b) a derived class from IntersectAction does not have access to the
> _hit* state.
>
> c) providing extra enter and leave callbacks does not allow delegation
> inside their implementation since the intersectEnter methods of the
> NodeCores are declared in the protected section.
>
> So basically, I have the following questions:
>
> - Are there any other known ideas for intersection with VisitSubTree
> shared sub scenes, i.e. for finding the actual VisitSubTree carrying
> node for the winning intersection?
>
> - Is there any support for designing the IntersectAction more
> customizable?

Possibly no, but the IntersectAction is not cast in stone either ;) If 
it needs to be modified to accommodate a new feature that's fine, just 
breaking existing code should be avoided. In the worst case a new 
IntersectAction2 (better name would be nice :) ) could be added, that 
mostly reuses the existing node core callbacks.

> - How can this best be done?

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?

> - Does my approach have apparent flaws which I do not see, but you? :-)

I'm wondering if your solution will support multiple VisitSubTree nodes 
in the path from the root to the hit object?
How about simply tracking the chain of nodes that form this path?

	Cheers,
		Carsten

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

[Carsten N. <car...@gm...>]

	Hello Johannes,

On 10/10/2013 04:23 AM, Johannes wrote:
> On 09.10.2013 17:14, Carsten Neumann wrote:
>   > 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.

oh, it just seemed simpler to do and avoid having to worry about it 
again if something similar comes up in the future ;)

> 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.

hmm, VisitSubTree just registers a callback with the IntersectAction 
when the it is being left, no?

> 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.

ok, sounds good to me, it's pretty close to what I was thinking of.

> 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. :-(

ok, that is inelegant, on the other hand it is a six line callback.

> 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.

well, that should not break any existing code, so we could make that change.

Anyway, I'm attaching a quick attempt at a patch that tracks the whole 
path from root to hit object and makes it available as IA::getHitPath().

	Cheers,
		Carsten

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

[Johannes <JB...@Da...>]

Hello Carsten,

On 11.10.2013 13:12, Carsten Neumann wrote:

>>
>> Of course one could track all visited nodes of the branch but I see no
>> value in doing that.
>
> oh, it just seemed simpler to do and avoid having to worry about it
> again if something similar comes up in the future ;)
>
you are probably right :-)

>
> hmm, VisitSubTree just registers a callback with the IntersectAction
> when the it is being left, no?
>
only on entering but not on leaving.

>
> ok, sounds good to me, it's pretty close to what I was thinking of.
>
:-)

>
> ok, that is inelegant, on the other hand it is a six line callback.
>
yes, but who knows what changes...

>
> Anyway, I'm attaching a quick attempt at a patch that tracks the whole
> path from root to hit object and makes it available as IA::getHitPath().
>
excellent!


Best,
Johannes

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

[Johannes <JB...@Da...>]

Hello Carsten,

I did finally tested your patch in my setup and it worked as expected.

Could you please merge the patch into the code base?

Best,
Johannes

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

[Carsten N. <car...@gm...>]

	Hello Johannes,

On 11/12/2013 06:30 AM, Johannes wrote:
> I did finally tested your patch in my setup and it worked as expected.

thanks a lot for testing it!

> Could you please merge the patch into the code base?

Yup, just pushed it, thanks again!

	Cheers,
		Carsten

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

[Johannes <JB...@Da...>]

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