Re: [osg-users] LineSegmentIntersector::intersect + performance
Excellent. I tested it and everything seems to work as expected. Thanks for the quick response. BTW: I'm also investigating a way to somehow "cache" the last drawable that we intersected with (terrain only). If this works, it could prove to be a significant performance gain in situations where we simulate ground vehicles or lifeforms (for example), since their speed is relatively slow and the probably of intersecting the same geometry at the next frame is very high. My objective is to try to intersect with the cached drawable first, and there's no intersection then fallback to intersecting the entire terrain. -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=74198#74198 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] LineSegmentIntersector::intersect + performance
HI Guy, On Tue, 26 Jun 2018 at 20:10, Robert Osfield wrote: > As for the creation or the Settings object on the heap, as it's a > local new/delete and operation within a single thread it is probably > safe to replace with an object on the stack. I have implemented this and checked it into the 3.6 branch. Could you test this? https://github.com/openscenegraph/OpenSceneGraph/commit/cbcf7015bba30020c4a6427a9d5f926641dc4096 Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] LineSegmentIntersector::intersect + performance
Hi Guy, Just how many separate LineSegmentIntersection and Drawables are you trying to intersect with? As for the creation or the Settings object on the heap, as it's a local new/delete and operation within a single thread it is probably safe to replace with an object on the stack. Robert. On Tue, 26 Jun 2018 at 19:06, Volckaert, Guy (CA - MTS) wrote: > > Hi, > > I recently upgraded to the OSG v3.6.1 and I noticed that the new > LineSegmentIntersector has changed significantly compared to v3.4.0. As I was > reviewing the changes, I noticed that the LineSegmentIntersector now > allocates an instance of LineSegmentIntersectorUtils::Settings every time the > IntersectionVisitor intercepts a drawable. > > From a purely efficiency standpoint, I was wondering if we could do better. > Intersection were relatively slow in the past and now it seems that we made > even slower. That being said, I'm pretty sure there's a valid reason for why > it was done this way. Before I look at alternative solutions, I was wondering > if anyone could share for reasons. > > Below is a snip-it of the function: > > void LineSegmentIntersector::intersect(osgUtil::IntersectionVisitor& iv, > osg::Drawable* drawable, >const osg::Vec3d& s, const osg::Vec3d& > e) > { > if (reachedLimit()) return; > > osg::ref_ptr settings = new > LineSegmentIntersectorUtils::Settings; // << HERE > settings->_lineSegIntersector = this; > settings->_iv = > settings->_drawable = drawable; > settings->_limitOneIntersection = (_intersectionLimit == > LIMIT_ONE_PER_DRAWABLE || _intersectionLimit == LIMIT_ONE); > > osg::Geometry* geometry = drawable->asGeometry(); > if (geometry) > { > settings->_vertices = > dynamic_cast(geometry->getVertexArray()); > } > > osg::KdTree* kdTree = iv.getUseKdTreeWhenAvailable() ? > dynamic_cast(drawable->getShape()) : 0; > > if (getPrecisionHint()==USE_DOUBLE_CALCULATIONS) > { > > osg::TemplatePrimitiveFunctor double> > intersector; > intersector.set(s,e, settings.get()); > > if (kdTree) kdTree->intersect(intersector, kdTree->getNode(0)); > else drawable->accept(intersector); > } > else > { > > osg::TemplatePrimitiveFunctor float> > intersector; > intersector.set(s,e, settings.get()); > > if (kdTree) kdTree->intersect(intersector, kdTree->getNode(0)); > else drawable->accept(intersector); > } > } > > Regards, > > Guy Volckaert, ing. > Snr Software Engineer > > Meggitt Training Systems (Quebec) Inc. > Systèmes d'entraînement Meggitt (Québec) Inc. > 6140 Henri Bourassa West > Montreal, Quebec, H4R 3A6 > Canada > > Tel: 1 (514) 339 9938 Ext 617 > Fax: 1 (514) 339 2641 > Cell: 1 (514) 928-5641 > email: guy.volcka...@meggitt.com > url; www.meggitt.com > skype: guy.volckaert > > Svp. Considérez l'environnement avant d'imprimer > Please consider the environment before printing this e-mail. > > > > > > This e-mail may contain proprietary information and/or copyright material. > This e-mail is intended for the use of the addressee only. Any unauthorized > use may be unlawful. If you receive this e-mail by mistake, please advise the > sender immediately by using the reply facility in your e-mail software. > > Information contained in and/or attached to this document may be subject to > export control regulations of the European Community, USA, or other > countries. Each recipient of this document is responsible to ensure that > usage and/or transfer of any information contained in this document complies > with all relevant export control regulations. If you are in any doubt about > the export control restrictions that apply to this information, please > contact the sender immediately. > > Be aware that Meggitt may monitor incoming and outgoing e-mails to ensure > compliance with the Meggitt IT Use policy. > > ___ > osg-users mailing list > osg-users@lists.openscenegraph.org > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] LineSegmentIntersector::intersect + performance
Hi, I recently upgraded to the OSG v3.6.1 and I noticed that the new LineSegmentIntersector has changed significantly compared to v3.4.0. As I was reviewing the changes, I noticed that the LineSegmentIntersector now allocates an instance of LineSegmentIntersectorUtils::Settings every time the IntersectionVisitor intercepts a drawable. >From a purely efficiency standpoint, I was wondering if we could do better. >Intersection were relatively slow in the past and now it seems that we made >even slower. That being said, I'm pretty sure there's a valid reason for why >it was done this way. Before I look at alternative solutions, I was wondering >if anyone could share for reasons. Below is a snip-it of the function: void LineSegmentIntersector::intersect(osgUtil::IntersectionVisitor& iv, osg::Drawable* drawable, const osg::Vec3d& s, const osg::Vec3d& e) { if (reachedLimit()) return; osg::ref_ptr settings = new LineSegmentIntersectorUtils::Settings; // << HERE settings->_lineSegIntersector = this; settings->_iv = settings->_drawable = drawable; settings->_limitOneIntersection = (_intersectionLimit == LIMIT_ONE_PER_DRAWABLE || _intersectionLimit == LIMIT_ONE); osg::Geometry* geometry = drawable->asGeometry(); if (geometry) { settings->_vertices = dynamic_cast(geometry->getVertexArray()); } osg::KdTree* kdTree = iv.getUseKdTreeWhenAvailable() ? dynamic_cast(drawable->getShape()) : 0; if (getPrecisionHint()==USE_DOUBLE_CALCULATIONS) { osg::TemplatePrimitiveFunctor > intersector; intersector.set(s,e, settings.get()); if (kdTree) kdTree->intersect(intersector, kdTree->getNode(0)); else drawable->accept(intersector); } else { osg::TemplatePrimitiveFunctor > intersector; intersector.set(s,e, settings.get()); if (kdTree) kdTree->intersect(intersector, kdTree->getNode(0)); else drawable->accept(intersector); } } Regards, Guy Volckaert, ing. Snr Software Engineer Meggitt Training Systems (Quebec) Inc. Systèmes d'entraînement Meggitt (Québec) Inc. 6140 Henri Bourassa West Montreal, Quebec, H4R 3A6 Canada Tel: 1 (514) 339 9938 Ext 617 Fax: 1 (514) 339 2641 Cell: 1 (514) 928-5641 email: guy.volcka...@meggitt.com url; www.meggitt.com skype: guy.volckaert Svp. Considérez l'environnement avant d'imprimer Please consider the environment before printing this e-mail. This e-mail may contain proprietary information and/or copyright material. This e-mail is intended for the use of the addressee only. Any unauthorized use may be unlawful. If you receive this e-mail by mistake, please advise the sender immediately by using the reply facility in your e-mail software. Information contained in and/or attached to this document may be subject to export control regulations of the European Community, USA, or other countries. Each recipient of this document is responsible to ensure that usage and/or transfer of any information contained in this document complies with all relevant export control regulations. If you are in any doubt about the export control restrictions that apply to this information, please contact the sender immediately. Be aware that Meggitt may monitor incoming and outgoing e-mails to ensure compliance with the Meggitt IT Use policy. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org