Hi all, Just a quick note of which just occurred to me while implementing the stuff mentioned below ...
So as apply(iterator,iterator) is not templated on the iterator type, the input iterators always have to be vector iterators. So a list wouldn't do in this case, for example. However, as the child list in a node is not derived from a vector nor any STL class, you can not even use that function to iterate over the children of a node, which seems to be its use at least for the IntersectAction as you describe below. Of course you can always copy the children to a vector and iterate over that. I just would like to understand what that function is for, I see no usage scenario right now. Btw, the implementation of ActionBase::apply(Node*) does look a bit weird to me, performance-wise. Especially if you consider it might be used much more often than the iterator version. Aloha, Andi > -----Original Message----- > From: Andreas Halm [mailto:andreas.h...@fraunhofer.at] > Sent: Friday, September 23, 2011 10:33 AM > To: opensg-users@lists.sourceforge.net > Subject: Re: [Opensg-users] IntersectAction::apply > > Hi Dirk, > > > From: Dirk Reiners [mailto:dirk.rein...@gmail.com] > > > I have seen that Action::apply(iterator,iterator) is virtual, but > > > not overwritten in IntersectAction. However, without the overwrite > > > using that function does not seem to make much sense - or maybe I'm > > completely wrong here? > > > If you have a vector/list/. of Nodes, you have to apply the world > > > matrix of each of the nodes before descending recursively. Otherwise > > > the > > result would be wrong. > > > However, you cannot do that outside of the function because it is > > > not guarantueed that the nodes have the same parent. > > > > The idea is that all nodes passed into that method are in the same > coordinate > > system, i.e. they all come from the same parent node, and the ray is > > in > the > > same coordinate system, too. > > > > So if you just have a list of Nodes from anywhere in the tree there is > > no direct way to intersect only against those. I would recommend using > > a traversal mask to the Nodes you want to intersect and just intersect > against > > the root. The only problem here is that you need to mark all Nodes > > between yours and the root, or to just mark all Group nodes and just > > not the Geometry nodes you want to skip. > > > > I see. That is really unfortunate, although I currently know that the nodes > have the same parent, the code is part of a library and I don't want to make > any such assumptions. The list I am going through is a list of results of an > earlier computation. > I guess I will just iterate by hand over the list, for each of them applying the > toWorld matrix first. Not the fastest solution, but should not be performance > critical at that point. > > Thanks for your answer! > Aloha, Andi > > > ---------------------------------------------------------------------------- -- > All of the data generated in your IT infrastructure is seriously valuable. > Why? It contains a definitive record of application performance, security > threats, fraudulent activity, and more. Splunk takes this data and makes > sense of it. IT sense. And common sense. > http://p.sf.net/sfu/splunk-d2dcopy2 > _______________________________________________ > Opensg-users mailing list > Opensg-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/opensg-users ------------------------------------------------------------------------------ All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2dcopy2 _______________________________________________ Opensg-users mailing list Opensg-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/opensg-users
