OpenSceneGraph/examples/osgkeyboardmouse/osgkeyboardmouse.cpp

382 lines
13 KiB
C++
Raw Normal View History

// C++ source file - (C) 2003 Robert Osfield, released under the OSGPL.
//
// Simple example of use of osgViewer::GraphicsWindow + Viewer
// example that provides the user with control over view position with basic picking.
#include <osg/Timer>
2005-04-08 17:45:06 +08:00
#include <osg/io_utils>
2006-06-12 22:04:40 +08:00
#include <osg/observer_ptr>
#include <osgUtil/IntersectionVisitor>
#include <osgUtil/PolytopeIntersector>
#include <osgUtil/LineSegmentIntersector>
#include <osgDB/ReadFile>
#include <osgDB/WriteFile>
#include <osgGA/TrackballManipulator>
#include <osgGA/StateSetManipulator>
#include <osgViewer/Viewer>
#include <osgFX/Scribe>
#include <iostream>
2006-06-12 22:04:40 +08:00
class CreateModelToSaveVisitor : public osg::NodeVisitor
{
public:
CreateModelToSaveVisitor():
osg::NodeVisitor(osg::NodeVisitor::TRAVERSE_ALL_CHILDREN)
{
_group = new osg::Group;
_addToModel = false;
}
virtual void apply(osg::Node& node)
{
osgFX::Scribe* scribe = dynamic_cast<osgFX::Scribe*>(&node);
if (scribe)
{
for(unsigned int i=0; i<scribe->getNumChildren(); ++i)
{
_group->addChild(scribe->getChild(i));
}
}
else
{
traverse(node);
}
}
osg::ref_ptr<osg::Group> _group;
bool _addToModel;
};
class DeleteSelectedNodesVisitor : public osg::NodeVisitor
{
public:
DeleteSelectedNodesVisitor():
osg::NodeVisitor(osg::NodeVisitor::TRAVERSE_ALL_CHILDREN)
{
}
virtual void apply(osg::Node& node)
{
osgFX::Scribe* scribe = dynamic_cast<osgFX::Scribe*>(&node);
if (scribe)
{
_selectedNodes.push_back(scribe);
}
else
{
traverse(node);
}
}
void pruneSelectedNodes()
{
for(SelectedNodes::iterator itr = _selectedNodes.begin();
itr != _selectedNodes.end();
++itr)
{
osg::Node* node = itr->get();
osg::Node::ParentList parents = node->getParents();
for(osg::Node::ParentList::iterator pitr = parents.begin();
pitr != parents.end();
++pitr)
{
osg::Group* parent = *pitr;
parent->removeChild(node);
}
}
}
typedef std::vector< osg::ref_ptr<osgFX::Scribe> > SelectedNodes;
SelectedNodes _selectedNodes;
};
2006-06-12 22:04:40 +08:00
// class to handle events with a pick
class PickHandler : public osgGA::GUIEventHandler
{
2006-06-12 22:04:40 +08:00
public:
PickHandler():
From Peter Hrenka, (note from Robert Osfield, renamed GenericPrimitiveFunctor mention below to TemplatePrimitiveFunctor). "Since we desperately needed a means for picking Lines and Points I implemented (hopefully!) proper geometrical tests for the PolytopeIntersector. First of all I implemented a new "GenericPrimiteFunctor" which is basically an extended copy TriangleFunctor which also handles Points, Lines and Quads through suitable overloads of operator(). I would have liked to call it "PrimitiveFunctor" but that name was already used... I used a template method to remove redundancy in the drawElements method overloads. If you know of platforms where this will not work I can change it to the style used in TriangleFunctor. In PolytopeIntersector.cpp I implemented a "PolytopePrimitiveIntersector" which provides the needed overloads for Points, Lines, Triangles and Quads to the GenericPrimitiveFunctor. This is then used in the intersect method of PolytopeIntersector. Implementation summary: - Points: Check distance to all planes - Lines: Check distance of both ends against each plane. If both are outside -> line is out If both are in -> continue checking One is in, one is out -> compute intersection point (candidate) Then check all candidates against all other polytope planes. The remaining candidates are the proper intersection points of the line with the polytope. - Triangles: Perform Line-Checks for all edges of the triangle as above. If there is an proper intersection -> done. In the case where there are more than 2 polytope plane to check against we have to check for the case where the triangle encloses the polytope. In that case the intersection lines of the polytope planes are computed and checked against the triangle. - Quads: handled as two triangles. This is implementation is certainly not the fastest. There are certainly ways and strategies to improve it. I also enabled the code for PolytopeIntersector in osgkeyboardmouse and added keybindings to switch the type of intersector ('p') and the picking coordinate system ('c') on the fly. Since the PolytopeIntersector does not have a canonical ordering for its intersections (as opposed to the LineSegementIntersector) I chaged the implementation to toggle all hit geometries. I tested the functionality with osgkeyboardmouse and several models and it seems to work for polygonal models. Special nodes such as billboards do not work. The next thing on my todo-list is to implement a an improved Intersection-Structure for the PolytopeIntersector. We need to know which primitives where hit (and where). "
2007-05-23 19:05:59 +08:00
_mx(0.0),_my(0.0),
_usePolytopeIntersector(false),
_useWindowCoordinates(false) {}
2006-06-12 22:04:40 +08:00
~PickHandler() {}
bool handle(const osgGA::GUIEventAdapter& ea, osgGA::GUIActionAdapter& aa)
2006-06-12 22:04:40 +08:00
{
osgViewer::Viewer* viewer = dynamic_cast<osgViewer::Viewer*>(&aa);
if (!viewer) return false;
2006-06-12 22:04:40 +08:00
switch(ea.getEventType())
{
case(osgGA::GUIEventAdapter::KEYUP):
{
if (ea.getKey()=='s')
2006-06-12 22:04:40 +08:00
{
saveSelectedModel(viewer->getSceneData());
}
else if (ea.getKey()=='o')
{
osg::notify(osg::NOTICE)<<"Saved model to file 'saved_model.osg'"<<std::endl;
osgDB::writeNodeFile(*(viewer->getSceneData()), "saved_model.osg");
}
From Peter Hrenka, (note from Robert Osfield, renamed GenericPrimitiveFunctor mention below to TemplatePrimitiveFunctor). "Since we desperately needed a means for picking Lines and Points I implemented (hopefully!) proper geometrical tests for the PolytopeIntersector. First of all I implemented a new "GenericPrimiteFunctor" which is basically an extended copy TriangleFunctor which also handles Points, Lines and Quads through suitable overloads of operator(). I would have liked to call it "PrimitiveFunctor" but that name was already used... I used a template method to remove redundancy in the drawElements method overloads. If you know of platforms where this will not work I can change it to the style used in TriangleFunctor. In PolytopeIntersector.cpp I implemented a "PolytopePrimitiveIntersector" which provides the needed overloads for Points, Lines, Triangles and Quads to the GenericPrimitiveFunctor. This is then used in the intersect method of PolytopeIntersector. Implementation summary: - Points: Check distance to all planes - Lines: Check distance of both ends against each plane. If both are outside -> line is out If both are in -> continue checking One is in, one is out -> compute intersection point (candidate) Then check all candidates against all other polytope planes. The remaining candidates are the proper intersection points of the line with the polytope. - Triangles: Perform Line-Checks for all edges of the triangle as above. If there is an proper intersection -> done. In the case where there are more than 2 polytope plane to check against we have to check for the case where the triangle encloses the polytope. In that case the intersection lines of the polytope planes are computed and checked against the triangle. - Quads: handled as two triangles. This is implementation is certainly not the fastest. There are certainly ways and strategies to improve it. I also enabled the code for PolytopeIntersector in osgkeyboardmouse and added keybindings to switch the type of intersector ('p') and the picking coordinate system ('c') on the fly. Since the PolytopeIntersector does not have a canonical ordering for its intersections (as opposed to the LineSegementIntersector) I chaged the implementation to toggle all hit geometries. I tested the functionality with osgkeyboardmouse and several models and it seems to work for polygonal models. Special nodes such as billboards do not work. The next thing on my todo-list is to implement a an improved Intersection-Structure for the PolytopeIntersector. We need to know which primitives where hit (and where). "
2007-05-23 19:05:59 +08:00
else if (ea.getKey()=='p')
{
_usePolytopeIntersector = !_usePolytopeIntersector;
if (_usePolytopeIntersector)
{
osg::notify(osg::NOTICE)<<"Using PolytopeIntersector"<<std::endl;
} else {
osg::notify(osg::NOTICE)<<"Using LineSegmentIntersector"<<std::endl;
}
}
else if (ea.getKey()=='c')
{
_useWindowCoordinates = !_useWindowCoordinates;
if (_useWindowCoordinates)
{
osg::notify(osg::NOTICE)<<"Using window coordinates for picking"<<std::endl;
} else {
osg::notify(osg::NOTICE)<<"Using projection coordiates for picking"<<std::endl;
}
}
else if (ea.getKey()==osgGA::GUIEventAdapter::KEY_Delete || ea.getKey()==osgGA::GUIEventAdapter::KEY_BackSpace)
{
osg::notify(osg::NOTICE)<<"Delete"<<std::endl;
DeleteSelectedNodesVisitor dsnv;
viewer->getSceneData()->accept(dsnv);
dsnv.pruneSelectedNodes();
2006-06-12 22:04:40 +08:00
}
return false;
}
case(osgGA::GUIEventAdapter::PUSH):
case(osgGA::GUIEventAdapter::MOVE):
{
_mx = ea.getX();
_my = ea.getY();
return false;
}
case(osgGA::GUIEventAdapter::RELEASE):
{
if (_mx == ea.getX() && _my == ea.getY())
{
// only do a pick if the mouse hasn't moved
pick(ea,viewer);
2006-06-12 22:04:40 +08:00
}
return true;
}
default:
return false;
}
}
void pick(const osgGA::GUIEventAdapter& ea, osgViewer::Viewer* viewer)
2006-06-12 22:04:40 +08:00
{
osg::Node* scene = viewer->getSceneData();
2006-06-12 22:04:40 +08:00
if (!scene) return;
osg::notify(osg::NOTICE)<<std::endl;
osg::Node* node = 0;
osg::Group* parent = 0;
From Peter Hrenka, (note from Robert Osfield, renamed GenericPrimitiveFunctor mention below to TemplatePrimitiveFunctor). "Since we desperately needed a means for picking Lines and Points I implemented (hopefully!) proper geometrical tests for the PolytopeIntersector. First of all I implemented a new "GenericPrimiteFunctor" which is basically an extended copy TriangleFunctor which also handles Points, Lines and Quads through suitable overloads of operator(). I would have liked to call it "PrimitiveFunctor" but that name was already used... I used a template method to remove redundancy in the drawElements method overloads. If you know of platforms where this will not work I can change it to the style used in TriangleFunctor. In PolytopeIntersector.cpp I implemented a "PolytopePrimitiveIntersector" which provides the needed overloads for Points, Lines, Triangles and Quads to the GenericPrimitiveFunctor. This is then used in the intersect method of PolytopeIntersector. Implementation summary: - Points: Check distance to all planes - Lines: Check distance of both ends against each plane. If both are outside -> line is out If both are in -> continue checking One is in, one is out -> compute intersection point (candidate) Then check all candidates against all other polytope planes. The remaining candidates are the proper intersection points of the line with the polytope. - Triangles: Perform Line-Checks for all edges of the triangle as above. If there is an proper intersection -> done. In the case where there are more than 2 polytope plane to check against we have to check for the case where the triangle encloses the polytope. In that case the intersection lines of the polytope planes are computed and checked against the triangle. - Quads: handled as two triangles. This is implementation is certainly not the fastest. There are certainly ways and strategies to improve it. I also enabled the code for PolytopeIntersector in osgkeyboardmouse and added keybindings to switch the type of intersector ('p') and the picking coordinate system ('c') on the fly. Since the PolytopeIntersector does not have a canonical ordering for its intersections (as opposed to the LineSegementIntersector) I chaged the implementation to toggle all hit geometries. I tested the functionality with osgkeyboardmouse and several models and it seems to work for polygonal models. Special nodes such as billboards do not work. The next thing on my todo-list is to implement a an improved Intersection-Structure for the PolytopeIntersector. We need to know which primitives where hit (and where). "
2007-05-23 19:05:59 +08:00
if (_usePolytopeIntersector)
{
From Peter Hrenka, (note from Robert Osfield, renamed GenericPrimitiveFunctor mention below to TemplatePrimitiveFunctor). "Since we desperately needed a means for picking Lines and Points I implemented (hopefully!) proper geometrical tests for the PolytopeIntersector. First of all I implemented a new "GenericPrimiteFunctor" which is basically an extended copy TriangleFunctor which also handles Points, Lines and Quads through suitable overloads of operator(). I would have liked to call it "PrimitiveFunctor" but that name was already used... I used a template method to remove redundancy in the drawElements method overloads. If you know of platforms where this will not work I can change it to the style used in TriangleFunctor. In PolytopeIntersector.cpp I implemented a "PolytopePrimitiveIntersector" which provides the needed overloads for Points, Lines, Triangles and Quads to the GenericPrimitiveFunctor. This is then used in the intersect method of PolytopeIntersector. Implementation summary: - Points: Check distance to all planes - Lines: Check distance of both ends against each plane. If both are outside -> line is out If both are in -> continue checking One is in, one is out -> compute intersection point (candidate) Then check all candidates against all other polytope planes. The remaining candidates are the proper intersection points of the line with the polytope. - Triangles: Perform Line-Checks for all edges of the triangle as above. If there is an proper intersection -> done. In the case where there are more than 2 polytope plane to check against we have to check for the case where the triangle encloses the polytope. In that case the intersection lines of the polytope planes are computed and checked against the triangle. - Quads: handled as two triangles. This is implementation is certainly not the fastest. There are certainly ways and strategies to improve it. I also enabled the code for PolytopeIntersector in osgkeyboardmouse and added keybindings to switch the type of intersector ('p') and the picking coordinate system ('c') on the fly. Since the PolytopeIntersector does not have a canonical ordering for its intersections (as opposed to the LineSegementIntersector) I chaged the implementation to toggle all hit geometries. I tested the functionality with osgkeyboardmouse and several models and it seems to work for polygonal models. Special nodes such as billboards do not work. The next thing on my todo-list is to implement a an improved Intersection-Structure for the PolytopeIntersector. We need to know which primitives where hit (and where). "
2007-05-23 19:05:59 +08:00
osgUtil::PolytopeIntersector* picker;
if (_useWindowCoordinates)
{
// use window coordinates
// remap the mouse x,y into viewport coordinates.
osg::Viewport* viewport = viewer->getCamera()->getViewport();
double mx = viewport->x() + (int)((double )viewport->width()*(ea.getXnormalized()*0.5+0.5));
double my = viewport->y() + (int)((double )viewport->height()*(ea.getYnormalized()*0.5+0.5));
// half width, height.
double w = 5.0f;
double h = 5.0f;
picker = new osgUtil::PolytopeIntersector( osgUtil::Intersector::WINDOW, mx-w, my-h, mx+w, my+h );
} else {
double mx = ea.getXnormalized();
double my = ea.getYnormalized();
double w = 0.05;
double h = 0.05;
picker = new osgUtil::PolytopeIntersector( osgUtil::Intersector::PROJECTION, mx-w, my-h, mx+w, my+h );
}
osgUtil::IntersectionVisitor iv(picker);
viewer->getCamera()->accept(iv);
if (picker->containsIntersections())
{
From Peter Hrenka, (note from Robert Osfield, renamed GenericPrimitiveFunctor mention below to TemplatePrimitiveFunctor). "Since we desperately needed a means for picking Lines and Points I implemented (hopefully!) proper geometrical tests for the PolytopeIntersector. First of all I implemented a new "GenericPrimiteFunctor" which is basically an extended copy TriangleFunctor which also handles Points, Lines and Quads through suitable overloads of operator(). I would have liked to call it "PrimitiveFunctor" but that name was already used... I used a template method to remove redundancy in the drawElements method overloads. If you know of platforms where this will not work I can change it to the style used in TriangleFunctor. In PolytopeIntersector.cpp I implemented a "PolytopePrimitiveIntersector" which provides the needed overloads for Points, Lines, Triangles and Quads to the GenericPrimitiveFunctor. This is then used in the intersect method of PolytopeIntersector. Implementation summary: - Points: Check distance to all planes - Lines: Check distance of both ends against each plane. If both are outside -> line is out If both are in -> continue checking One is in, one is out -> compute intersection point (candidate) Then check all candidates against all other polytope planes. The remaining candidates are the proper intersection points of the line with the polytope. - Triangles: Perform Line-Checks for all edges of the triangle as above. If there is an proper intersection -> done. In the case where there are more than 2 polytope plane to check against we have to check for the case where the triangle encloses the polytope. In that case the intersection lines of the polytope planes are computed and checked against the triangle. - Quads: handled as two triangles. This is implementation is certainly not the fastest. There are certainly ways and strategies to improve it. I also enabled the code for PolytopeIntersector in osgkeyboardmouse and added keybindings to switch the type of intersector ('p') and the picking coordinate system ('c') on the fly. Since the PolytopeIntersector does not have a canonical ordering for its intersections (as opposed to the LineSegementIntersector) I chaged the implementation to toggle all hit geometries. I tested the functionality with osgkeyboardmouse and several models and it seems to work for polygonal models. Special nodes such as billboards do not work. The next thing on my todo-list is to implement a an improved Intersection-Structure for the PolytopeIntersector. We need to know which primitives where hit (and where). "
2007-05-23 19:05:59 +08:00
osgUtil::PolytopeIntersector::Intersections& intersections = picker->getIntersections();
From Peter Hrenka, (note from Robert Osfield, renamed GenericPrimitiveFunctor mention below to TemplatePrimitiveFunctor). "Since we desperately needed a means for picking Lines and Points I implemented (hopefully!) proper geometrical tests for the PolytopeIntersector. First of all I implemented a new "GenericPrimiteFunctor" which is basically an extended copy TriangleFunctor which also handles Points, Lines and Quads through suitable overloads of operator(). I would have liked to call it "PrimitiveFunctor" but that name was already used... I used a template method to remove redundancy in the drawElements method overloads. If you know of platforms where this will not work I can change it to the style used in TriangleFunctor. In PolytopeIntersector.cpp I implemented a "PolytopePrimitiveIntersector" which provides the needed overloads for Points, Lines, Triangles and Quads to the GenericPrimitiveFunctor. This is then used in the intersect method of PolytopeIntersector. Implementation summary: - Points: Check distance to all planes - Lines: Check distance of both ends against each plane. If both are outside -> line is out If both are in -> continue checking One is in, one is out -> compute intersection point (candidate) Then check all candidates against all other polytope planes. The remaining candidates are the proper intersection points of the line with the polytope. - Triangles: Perform Line-Checks for all edges of the triangle as above. If there is an proper intersection -> done. In the case where there are more than 2 polytope plane to check against we have to check for the case where the triangle encloses the polytope. In that case the intersection lines of the polytope planes are computed and checked against the triangle. - Quads: handled as two triangles. This is implementation is certainly not the fastest. There are certainly ways and strategies to improve it. I also enabled the code for PolytopeIntersector in osgkeyboardmouse and added keybindings to switch the type of intersector ('p') and the picking coordinate system ('c') on the fly. Since the PolytopeIntersector does not have a canonical ordering for its intersections (as opposed to the LineSegementIntersector) I chaged the implementation to toggle all hit geometries. I tested the functionality with osgkeyboardmouse and several models and it seems to work for polygonal models. Special nodes such as billboards do not work. The next thing on my todo-list is to implement a an improved Intersection-Structure for the PolytopeIntersector. We need to know which primitives where hit (and where). "
2007-05-23 19:05:59 +08:00
for (osgUtil::PolytopeIntersector::Intersections::iterator it=intersections.begin();
it!=intersections.end(); ++it) {
osgUtil::PolytopeIntersector::Intersection intersection=*it;
From Peter Hrenka, (note from Robert Osfield, renamed GenericPrimitiveFunctor mention below to TemplatePrimitiveFunctor). "Since we desperately needed a means for picking Lines and Points I implemented (hopefully!) proper geometrical tests for the PolytopeIntersector. First of all I implemented a new "GenericPrimiteFunctor" which is basically an extended copy TriangleFunctor which also handles Points, Lines and Quads through suitable overloads of operator(). I would have liked to call it "PrimitiveFunctor" but that name was already used... I used a template method to remove redundancy in the drawElements method overloads. If you know of platforms where this will not work I can change it to the style used in TriangleFunctor. In PolytopeIntersector.cpp I implemented a "PolytopePrimitiveIntersector" which provides the needed overloads for Points, Lines, Triangles and Quads to the GenericPrimitiveFunctor. This is then used in the intersect method of PolytopeIntersector. Implementation summary: - Points: Check distance to all planes - Lines: Check distance of both ends against each plane. If both are outside -> line is out If both are in -> continue checking One is in, one is out -> compute intersection point (candidate) Then check all candidates against all other polytope planes. The remaining candidates are the proper intersection points of the line with the polytope. - Triangles: Perform Line-Checks for all edges of the triangle as above. If there is an proper intersection -> done. In the case where there are more than 2 polytope plane to check against we have to check for the case where the triangle encloses the polytope. In that case the intersection lines of the polytope planes are computed and checked against the triangle. - Quads: handled as two triangles. This is implementation is certainly not the fastest. There are certainly ways and strategies to improve it. I also enabled the code for PolytopeIntersector in osgkeyboardmouse and added keybindings to switch the type of intersector ('p') and the picking coordinate system ('c') on the fly. Since the PolytopeIntersector does not have a canonical ordering for its intersections (as opposed to the LineSegementIntersector) I chaged the implementation to toggle all hit geometries. I tested the functionality with osgkeyboardmouse and several models and it seems to work for polygonal models. Special nodes such as billboards do not work. The next thing on my todo-list is to implement a an improved Intersection-Structure for the PolytopeIntersector. We need to know which primitives where hit (and where). "
2007-05-23 19:05:59 +08:00
osg::NodePath& nodePath = intersection.nodePath;
node = (nodePath.size()>=1)?nodePath[nodePath.size()-1]:0;
parent = (nodePath.size()>=2)?dynamic_cast<osg::Group*>(nodePath[nodePath.size()-2]):0;
if (node) std::cout<<" Hits "<<node->className()<<" nodePath size"<<nodePath.size()<<std::endl;
toggleScribe(parent, node);
}
}
}
else
{
From Peter Hrenka, (note from Robert Osfield, renamed GenericPrimitiveFunctor mention below to TemplatePrimitiveFunctor). "Since we desperately needed a means for picking Lines and Points I implemented (hopefully!) proper geometrical tests for the PolytopeIntersector. First of all I implemented a new "GenericPrimiteFunctor" which is basically an extended copy TriangleFunctor which also handles Points, Lines and Quads through suitable overloads of operator(). I would have liked to call it "PrimitiveFunctor" but that name was already used... I used a template method to remove redundancy in the drawElements method overloads. If you know of platforms where this will not work I can change it to the style used in TriangleFunctor. In PolytopeIntersector.cpp I implemented a "PolytopePrimitiveIntersector" which provides the needed overloads for Points, Lines, Triangles and Quads to the GenericPrimitiveFunctor. This is then used in the intersect method of PolytopeIntersector. Implementation summary: - Points: Check distance to all planes - Lines: Check distance of both ends against each plane. If both are outside -> line is out If both are in -> continue checking One is in, one is out -> compute intersection point (candidate) Then check all candidates against all other polytope planes. The remaining candidates are the proper intersection points of the line with the polytope. - Triangles: Perform Line-Checks for all edges of the triangle as above. If there is an proper intersection -> done. In the case where there are more than 2 polytope plane to check against we have to check for the case where the triangle encloses the polytope. In that case the intersection lines of the polytope planes are computed and checked against the triangle. - Quads: handled as two triangles. This is implementation is certainly not the fastest. There are certainly ways and strategies to improve it. I also enabled the code for PolytopeIntersector in osgkeyboardmouse and added keybindings to switch the type of intersector ('p') and the picking coordinate system ('c') on the fly. Since the PolytopeIntersector does not have a canonical ordering for its intersections (as opposed to the LineSegementIntersector) I chaged the implementation to toggle all hit geometries. I tested the functionality with osgkeyboardmouse and several models and it seems to work for polygonal models. Special nodes such as billboards do not work. The next thing on my todo-list is to implement a an improved Intersection-Structure for the PolytopeIntersector. We need to know which primitives where hit (and where). "
2007-05-23 19:05:59 +08:00
osgUtil::LineSegmentIntersector* picker;
if (!_useWindowCoordinates)
{
// use non dimensional coordinates - in projection/clip space
picker = new osgUtil::LineSegmentIntersector( osgUtil::Intersector::PROJECTION, ea.getXnormalized(),ea.getYnormalized() );
} else {
// use window coordinates
// remap the mouse x,y into viewport coordinates.
osg::Viewport* viewport = viewer->getCamera()->getViewport();
float mx = viewport->x() + (int)((float)viewport->width()*(ea.getXnormalized()*0.5f+0.5f));
float my = viewport->y() + (int)((float)viewport->height()*(ea.getYnormalized()*0.5f+0.5f));
picker = new osgUtil::LineSegmentIntersector( osgUtil::Intersector::WINDOW, mx, my );
}
osgUtil::IntersectionVisitor iv(picker);
viewer->getCamera()->accept(iv);
if (picker->containsIntersections())
{
osgUtil::LineSegmentIntersector::Intersection intersection = picker->getFirstIntersection();
osg::notify(osg::NOTICE)<<"Picked "<<intersection.localIntersectionPoint<<std::endl;
osg::NodePath& nodePath = intersection.nodePath;
node = (nodePath.size()>=1)?nodePath[nodePath.size()-1]:0;
parent = (nodePath.size()>=2)?dynamic_cast<osg::Group*>(nodePath[nodePath.size()-2]):0;
if (node) std::cout<<" Hits "<<node->className()<<" nodePath size"<<nodePath.size()<<std::endl;
From Peter Hrenka, (note from Robert Osfield, renamed GenericPrimitiveFunctor mention below to TemplatePrimitiveFunctor). "Since we desperately needed a means for picking Lines and Points I implemented (hopefully!) proper geometrical tests for the PolytopeIntersector. First of all I implemented a new "GenericPrimiteFunctor" which is basically an extended copy TriangleFunctor which also handles Points, Lines and Quads through suitable overloads of operator(). I would have liked to call it "PrimitiveFunctor" but that name was already used... I used a template method to remove redundancy in the drawElements method overloads. If you know of platforms where this will not work I can change it to the style used in TriangleFunctor. In PolytopeIntersector.cpp I implemented a "PolytopePrimitiveIntersector" which provides the needed overloads for Points, Lines, Triangles and Quads to the GenericPrimitiveFunctor. This is then used in the intersect method of PolytopeIntersector. Implementation summary: - Points: Check distance to all planes - Lines: Check distance of both ends against each plane. If both are outside -> line is out If both are in -> continue checking One is in, one is out -> compute intersection point (candidate) Then check all candidates against all other polytope planes. The remaining candidates are the proper intersection points of the line with the polytope. - Triangles: Perform Line-Checks for all edges of the triangle as above. If there is an proper intersection -> done. In the case where there are more than 2 polytope plane to check against we have to check for the case where the triangle encloses the polytope. In that case the intersection lines of the polytope planes are computed and checked against the triangle. - Quads: handled as two triangles. This is implementation is certainly not the fastest. There are certainly ways and strategies to improve it. I also enabled the code for PolytopeIntersector in osgkeyboardmouse and added keybindings to switch the type of intersector ('p') and the picking coordinate system ('c') on the fly. Since the PolytopeIntersector does not have a canonical ordering for its intersections (as opposed to the LineSegementIntersector) I chaged the implementation to toggle all hit geometries. I tested the functionality with osgkeyboardmouse and several models and it seems to work for polygonal models. Special nodes such as billboards do not work. The next thing on my todo-list is to implement a an improved Intersection-Structure for the PolytopeIntersector. We need to know which primitives where hit (and where). "
2007-05-23 19:05:59 +08:00
toggleScribe(parent, node);
}
}
// now we try to decorate the hit node by the osgFX::Scribe to show that its been "picked"
From Peter Hrenka, (note from Robert Osfield, renamed GenericPrimitiveFunctor mention below to TemplatePrimitiveFunctor). "Since we desperately needed a means for picking Lines and Points I implemented (hopefully!) proper geometrical tests for the PolytopeIntersector. First of all I implemented a new "GenericPrimiteFunctor" which is basically an extended copy TriangleFunctor which also handles Points, Lines and Quads through suitable overloads of operator(). I would have liked to call it "PrimitiveFunctor" but that name was already used... I used a template method to remove redundancy in the drawElements method overloads. If you know of platforms where this will not work I can change it to the style used in TriangleFunctor. In PolytopeIntersector.cpp I implemented a "PolytopePrimitiveIntersector" which provides the needed overloads for Points, Lines, Triangles and Quads to the GenericPrimitiveFunctor. This is then used in the intersect method of PolytopeIntersector. Implementation summary: - Points: Check distance to all planes - Lines: Check distance of both ends against each plane. If both are outside -> line is out If both are in -> continue checking One is in, one is out -> compute intersection point (candidate) Then check all candidates against all other polytope planes. The remaining candidates are the proper intersection points of the line with the polytope. - Triangles: Perform Line-Checks for all edges of the triangle as above. If there is an proper intersection -> done. In the case where there are more than 2 polytope plane to check against we have to check for the case where the triangle encloses the polytope. In that case the intersection lines of the polytope planes are computed and checked against the triangle. - Quads: handled as two triangles. This is implementation is certainly not the fastest. There are certainly ways and strategies to improve it. I also enabled the code for PolytopeIntersector in osgkeyboardmouse and added keybindings to switch the type of intersector ('p') and the picking coordinate system ('c') on the fly. Since the PolytopeIntersector does not have a canonical ordering for its intersections (as opposed to the LineSegementIntersector) I chaged the implementation to toggle all hit geometries. I tested the functionality with osgkeyboardmouse and several models and it seems to work for polygonal models. Special nodes such as billboards do not work. The next thing on my todo-list is to implement a an improved Intersection-Structure for the PolytopeIntersector. We need to know which primitives where hit (and where). "
2007-05-23 19:05:59 +08:00
}
From Peter Hrenka, (note from Robert Osfield, renamed GenericPrimitiveFunctor mention below to TemplatePrimitiveFunctor). "Since we desperately needed a means for picking Lines and Points I implemented (hopefully!) proper geometrical tests for the PolytopeIntersector. First of all I implemented a new "GenericPrimiteFunctor" which is basically an extended copy TriangleFunctor which also handles Points, Lines and Quads through suitable overloads of operator(). I would have liked to call it "PrimitiveFunctor" but that name was already used... I used a template method to remove redundancy in the drawElements method overloads. If you know of platforms where this will not work I can change it to the style used in TriangleFunctor. In PolytopeIntersector.cpp I implemented a "PolytopePrimitiveIntersector" which provides the needed overloads for Points, Lines, Triangles and Quads to the GenericPrimitiveFunctor. This is then used in the intersect method of PolytopeIntersector. Implementation summary: - Points: Check distance to all planes - Lines: Check distance of both ends against each plane. If both are outside -> line is out If both are in -> continue checking One is in, one is out -> compute intersection point (candidate) Then check all candidates against all other polytope planes. The remaining candidates are the proper intersection points of the line with the polytope. - Triangles: Perform Line-Checks for all edges of the triangle as above. If there is an proper intersection -> done. In the case where there are more than 2 polytope plane to check against we have to check for the case where the triangle encloses the polytope. In that case the intersection lines of the polytope planes are computed and checked against the triangle. - Quads: handled as two triangles. This is implementation is certainly not the fastest. There are certainly ways and strategies to improve it. I also enabled the code for PolytopeIntersector in osgkeyboardmouse and added keybindings to switch the type of intersector ('p') and the picking coordinate system ('c') on the fly. Since the PolytopeIntersector does not have a canonical ordering for its intersections (as opposed to the LineSegementIntersector) I chaged the implementation to toggle all hit geometries. I tested the functionality with osgkeyboardmouse and several models and it seems to work for polygonal models. Special nodes such as billboards do not work. The next thing on my todo-list is to implement a an improved Intersection-Structure for the PolytopeIntersector. We need to know which primitives where hit (and where). "
2007-05-23 19:05:59 +08:00
void toggleScribe(osg::Group* parent, osg::Node* node) {
if (!parent || !node) return;
From Peter Hrenka, (note from Robert Osfield, renamed GenericPrimitiveFunctor mention below to TemplatePrimitiveFunctor). "Since we desperately needed a means for picking Lines and Points I implemented (hopefully!) proper geometrical tests for the PolytopeIntersector. First of all I implemented a new "GenericPrimiteFunctor" which is basically an extended copy TriangleFunctor which also handles Points, Lines and Quads through suitable overloads of operator(). I would have liked to call it "PrimitiveFunctor" but that name was already used... I used a template method to remove redundancy in the drawElements method overloads. If you know of platforms where this will not work I can change it to the style used in TriangleFunctor. In PolytopeIntersector.cpp I implemented a "PolytopePrimitiveIntersector" which provides the needed overloads for Points, Lines, Triangles and Quads to the GenericPrimitiveFunctor. This is then used in the intersect method of PolytopeIntersector. Implementation summary: - Points: Check distance to all planes - Lines: Check distance of both ends against each plane. If both are outside -> line is out If both are in -> continue checking One is in, one is out -> compute intersection point (candidate) Then check all candidates against all other polytope planes. The remaining candidates are the proper intersection points of the line with the polytope. - Triangles: Perform Line-Checks for all edges of the triangle as above. If there is an proper intersection -> done. In the case where there are more than 2 polytope plane to check against we have to check for the case where the triangle encloses the polytope. In that case the intersection lines of the polytope planes are computed and checked against the triangle. - Quads: handled as two triangles. This is implementation is certainly not the fastest. There are certainly ways and strategies to improve it. I also enabled the code for PolytopeIntersector in osgkeyboardmouse and added keybindings to switch the type of intersector ('p') and the picking coordinate system ('c') on the fly. Since the PolytopeIntersector does not have a canonical ordering for its intersections (as opposed to the LineSegementIntersector) I chaged the implementation to toggle all hit geometries. I tested the functionality with osgkeyboardmouse and several models and it seems to work for polygonal models. Special nodes such as billboards do not work. The next thing on my todo-list is to implement a an improved Intersection-Structure for the PolytopeIntersector. We need to know which primitives where hit (and where). "
2007-05-23 19:05:59 +08:00
std::cout<<" parent "<<parent->className()<<std::endl;
osgFX::Scribe* parentAsScribe = dynamic_cast<osgFX::Scribe*>(parent);
if (!parentAsScribe)
{
// node not already picked, so highlight it with an osgFX::Scribe
osgFX::Scribe* scribe = new osgFX::Scribe();
scribe->addChild(node);
parent->replaceChild(node,scribe);
}
else
{
// node already picked so we want to remove scribe to unpick it.
osg::Node::ParentList parentList = parentAsScribe->getParents();
for(osg::Node::ParentList::iterator itr=parentList.begin();
itr!=parentList.end();
++itr)
{
From Peter Hrenka, (note from Robert Osfield, renamed GenericPrimitiveFunctor mention below to TemplatePrimitiveFunctor). "Since we desperately needed a means for picking Lines and Points I implemented (hopefully!) proper geometrical tests for the PolytopeIntersector. First of all I implemented a new "GenericPrimiteFunctor" which is basically an extended copy TriangleFunctor which also handles Points, Lines and Quads through suitable overloads of operator(). I would have liked to call it "PrimitiveFunctor" but that name was already used... I used a template method to remove redundancy in the drawElements method overloads. If you know of platforms where this will not work I can change it to the style used in TriangleFunctor. In PolytopeIntersector.cpp I implemented a "PolytopePrimitiveIntersector" which provides the needed overloads for Points, Lines, Triangles and Quads to the GenericPrimitiveFunctor. This is then used in the intersect method of PolytopeIntersector. Implementation summary: - Points: Check distance to all planes - Lines: Check distance of both ends against each plane. If both are outside -> line is out If both are in -> continue checking One is in, one is out -> compute intersection point (candidate) Then check all candidates against all other polytope planes. The remaining candidates are the proper intersection points of the line with the polytope. - Triangles: Perform Line-Checks for all edges of the triangle as above. If there is an proper intersection -> done. In the case where there are more than 2 polytope plane to check against we have to check for the case where the triangle encloses the polytope. In that case the intersection lines of the polytope planes are computed and checked against the triangle. - Quads: handled as two triangles. This is implementation is certainly not the fastest. There are certainly ways and strategies to improve it. I also enabled the code for PolytopeIntersector in osgkeyboardmouse and added keybindings to switch the type of intersector ('p') and the picking coordinate system ('c') on the fly. Since the PolytopeIntersector does not have a canonical ordering for its intersections (as opposed to the LineSegementIntersector) I chaged the implementation to toggle all hit geometries. I tested the functionality with osgkeyboardmouse and several models and it seems to work for polygonal models. Special nodes such as billboards do not work. The next thing on my todo-list is to implement a an improved Intersection-Structure for the PolytopeIntersector. We need to know which primitives where hit (and where). "
2007-05-23 19:05:59 +08:00
(*itr)->replaceChild(parentAsScribe,node);
}
}
From Peter Hrenka, (note from Robert Osfield, renamed GenericPrimitiveFunctor mention below to TemplatePrimitiveFunctor). "Since we desperately needed a means for picking Lines and Points I implemented (hopefully!) proper geometrical tests for the PolytopeIntersector. First of all I implemented a new "GenericPrimiteFunctor" which is basically an extended copy TriangleFunctor which also handles Points, Lines and Quads through suitable overloads of operator(). I would have liked to call it "PrimitiveFunctor" but that name was already used... I used a template method to remove redundancy in the drawElements method overloads. If you know of platforms where this will not work I can change it to the style used in TriangleFunctor. In PolytopeIntersector.cpp I implemented a "PolytopePrimitiveIntersector" which provides the needed overloads for Points, Lines, Triangles and Quads to the GenericPrimitiveFunctor. This is then used in the intersect method of PolytopeIntersector. Implementation summary: - Points: Check distance to all planes - Lines: Check distance of both ends against each plane. If both are outside -> line is out If both are in -> continue checking One is in, one is out -> compute intersection point (candidate) Then check all candidates against all other polytope planes. The remaining candidates are the proper intersection points of the line with the polytope. - Triangles: Perform Line-Checks for all edges of the triangle as above. If there is an proper intersection -> done. In the case where there are more than 2 polytope plane to check against we have to check for the case where the triangle encloses the polytope. In that case the intersection lines of the polytope planes are computed and checked against the triangle. - Quads: handled as two triangles. This is implementation is certainly not the fastest. There are certainly ways and strategies to improve it. I also enabled the code for PolytopeIntersector in osgkeyboardmouse and added keybindings to switch the type of intersector ('p') and the picking coordinate system ('c') on the fly. Since the PolytopeIntersector does not have a canonical ordering for its intersections (as opposed to the LineSegementIntersector) I chaged the implementation to toggle all hit geometries. I tested the functionality with osgkeyboardmouse and several models and it seems to work for polygonal models. Special nodes such as billboards do not work. The next thing on my todo-list is to implement a an improved Intersection-Structure for the PolytopeIntersector. We need to know which primitives where hit (and where). "
2007-05-23 19:05:59 +08:00
2006-06-12 22:04:40 +08:00
}
void saveSelectedModel(osg::Node* scene)
2006-06-12 22:04:40 +08:00
{
if (!scene) return;
2006-06-12 22:04:40 +08:00
CreateModelToSaveVisitor cmtsv;
scene->accept(cmtsv);
2006-06-12 22:04:40 +08:00
if (cmtsv._group->getNumChildren()>0)
{
std::cout<<"Writing selected compoents to 'selected_model.osg'"<<std::endl;
osgDB::writeNodeFile(*cmtsv._group, "selected_model.osg");
}
}
protected:
float _mx,_my;
From Peter Hrenka, (note from Robert Osfield, renamed GenericPrimitiveFunctor mention below to TemplatePrimitiveFunctor). "Since we desperately needed a means for picking Lines and Points I implemented (hopefully!) proper geometrical tests for the PolytopeIntersector. First of all I implemented a new "GenericPrimiteFunctor" which is basically an extended copy TriangleFunctor which also handles Points, Lines and Quads through suitable overloads of operator(). I would have liked to call it "PrimitiveFunctor" but that name was already used... I used a template method to remove redundancy in the drawElements method overloads. If you know of platforms where this will not work I can change it to the style used in TriangleFunctor. In PolytopeIntersector.cpp I implemented a "PolytopePrimitiveIntersector" which provides the needed overloads for Points, Lines, Triangles and Quads to the GenericPrimitiveFunctor. This is then used in the intersect method of PolytopeIntersector. Implementation summary: - Points: Check distance to all planes - Lines: Check distance of both ends against each plane. If both are outside -> line is out If both are in -> continue checking One is in, one is out -> compute intersection point (candidate) Then check all candidates against all other polytope planes. The remaining candidates are the proper intersection points of the line with the polytope. - Triangles: Perform Line-Checks for all edges of the triangle as above. If there is an proper intersection -> done. In the case where there are more than 2 polytope plane to check against we have to check for the case where the triangle encloses the polytope. In that case the intersection lines of the polytope planes are computed and checked against the triangle. - Quads: handled as two triangles. This is implementation is certainly not the fastest. There are certainly ways and strategies to improve it. I also enabled the code for PolytopeIntersector in osgkeyboardmouse and added keybindings to switch the type of intersector ('p') and the picking coordinate system ('c') on the fly. Since the PolytopeIntersector does not have a canonical ordering for its intersections (as opposed to the LineSegementIntersector) I chaged the implementation to toggle all hit geometries. I tested the functionality with osgkeyboardmouse and several models and it seems to work for polygonal models. Special nodes such as billboards do not work. The next thing on my todo-list is to implement a an improved Intersection-Structure for the PolytopeIntersector. We need to know which primitives where hit (and where). "
2007-05-23 19:05:59 +08:00
bool _usePolytopeIntersector;
bool _useWindowCoordinates;
2006-06-12 22:04:40 +08:00
};
int main( int argc, char **argv )
{
osg::ref_ptr<osg::Node> loadedModel;
// load the scene.
if (argc>1) loadedModel = osgDB::readNodeFile(argv[1]);
// if not loaded assume no arguments passed in, try use default mode instead.
if (!loadedModel) loadedModel = osgDB::readNodeFile("dumptruck.osg");
if (!loadedModel)
{
std::cout << argv[0] <<": No data loaded." << std::endl;
return 1;
}
// create the window to draw to.
osg::ref_ptr<osg::GraphicsContext::Traits> traits = new osg::GraphicsContext::Traits;
traits->x = 200;
traits->y = 200;
traits->width = 800;
traits->height = 600;
traits->windowDecoration = true;
traits->doubleBuffer = true;
traits->sharedContext = 0;
osg::ref_ptr<osg::GraphicsContext> gc = osg::GraphicsContext::createGraphicsContext(traits.get());
osgViewer::GraphicsWindow* gw = dynamic_cast<osgViewer::GraphicsWindow*>(gc.get());
if (!gw)
{
osg::notify(osg::NOTICE)<<"Error: unable to create graphics window."<<std::endl;
return 1;
}
// create the view of the scene.
osgViewer::Viewer viewer;
viewer.getCamera()->setGraphicsContext(gc.get());
viewer.getCamera()->setViewport(0,0,800,600);
viewer.setSceneData(loadedModel.get());
// create a tracball manipulator to move the camera around in response to keyboard/mouse events
viewer.setCameraManipulator( new osgGA::TrackballManipulator );
osg::ref_ptr<osgGA::StateSetManipulator> statesetManipulator = new osgGA::StateSetManipulator(viewer.getCamera()->getStateSet());
viewer.addEventHandler(statesetManipulator.get());
// add the pick handler
viewer.addEventHandler(new PickHandler());
viewer.realize();
// main loop (note, window toolkits which take control over the main loop will require a window redraw callback containing the code below.)
while(!viewer.done())
{
viewer.frame();
}
return 0;
}