Hi Robert, On Fri, Mar 11, 2011 at 10:05 AM, Robert Osfield <[email protected]>wrote: > > One optimization one could do with the LIMIT_NEAREST would traverse > the children of a group so that the children are traversed in a > intersection depth order. I would expect such an approach on a well > balanced scene graph to result in earlier termination of the > traversal.
Do you mean traversing the children by bounding sphere depth order? This sounds like a good optimization. I'll look into it. On a side note, I noticed some of the camera manipulators in osgGA use the line segment intersector to find the first intersection point. They would probably benefit from the new LIMIT_NEAREST optimization. Cheers, Farshid > > Robert. > > On Thu, Mar 10, 2011 at 11:09 PM, Farshid Lashkari <[email protected]> > wrote: > > Hi Robert, > > Another update. I added a LIMIT_NEAREST enum which implements your > previous > > suggestion of rejecting bounding volumes further from the nearest > existing > > intersection. I only implemented this for LineSegmentIntersector. I'd > > appreciate it if you could double check the math I added > > to LineSegmentIntersector::intersects() for checking if the bounding > sphere > > is further away. The results of this are promising. I'm getting > noticeable > > performance increase for line intersections with scenes containing many > > drawables. > > Cheers, > > Farshid > > > > On Thu, Mar 10, 2011 at 12:14 PM, Farshid Lashkari <[email protected]> > wrote: > >> > >> Hi Robert, > >> I've attached an implementation of the intersection limit feature. This > >> patch does not implement the limit for kd tree intersections. Hopefully > I > >> can get around to that soon. > >> Cheers, > >> Farshid > >> > >> On Thu, Mar 10, 2011 at 10:10 AM, Robert Osfield > >> <[email protected]> wrote: > >>> > >>> Hi Farshid, > >>> > >>> On Thu, Mar 10, 2011 at 5:59 PM, Farshid Lashkari <[email protected]> > >>> wrote: > >>> > On second thought, I think this option should be an enum. I can also > >>> > think > >>> > of a scenario where a user just wants to know whether the line or > >>> > polytope > >>> > has any intersections, regardless of which drawable it is. So maybe > the > >>> > option should be something like this: > >>> > typedef enum IntersectionLimit {NoLimit, LimitOnePerDrawable, > >>> > LimitOne}; > >>> > void setIntersectionLimit(IntersectionLimit limit); > >>> > IntersectionLimit getIntersectionLimit(); > >>> > What do you think? > >>> > >>> Yes, an enum might be the best route. Another variation would be > >>> NearestIntersection, which would just return one intersection per > >>> Drawable, but would search for the nearest one. This could allow code > >>> to reject inersections with bounding volumes that are further away > >>> than the nearest intersection so far found. > >>> > >>> All these options will add complexity though... > >>> > >>> Robert. > >>> _______________________________________________ > >>> osg-submissions mailing list > >>> [email protected] > >>> > >>> > http://lists.openscenegraph.org/listinfo.cgi/osg-submissions-openscenegraph.org > >> > > > > > > _______________________________________________ > > osg-submissions mailing list > > [email protected] > > > http://lists.openscenegraph.org/listinfo.cgi/osg-submissions-openscenegraph.org > > > > > _______________________________________________ > osg-submissions mailing list > [email protected] > > http://lists.openscenegraph.org/listinfo.cgi/osg-submissions-openscenegraph.org >
_______________________________________________ osg-submissions mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-submissions-openscenegraph.org
