From: Carsten N. <car...@gm...> - 2013-10-09 15:14:40
|
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 |