From: Carsten N. <car...@gm...> - 2013-10-11 11:12:32
|
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 |