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 ------------------------------------------------------------------------------ October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register > http://pubads.g.doubleclick.net/gampad/clk?id=60134071&iu=/4140/ostg.clktrk _______________________________________________ Opensg-users mailing list Opensg-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/opensg-users
