"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).
"
Below is the changes made to the included files. The examples CMakeList.txt file was not included but the code change needed for osgviewerMFC inclusion is listed below.
CMakeList.txt:
This is a little different than other example cmakelist.txt files in that I could not use the setup_example macro. I had to go in and extract out the important parts of the macro and inline them in the CMakeList.txt file so that I could add the WIN32 declaration into the ADD_EXECUTABLE() statement. In the future the setup_example macro might be modified to support osgviewerMFC but this is special case so you might not want to muddy the water for one example.
MFC_OSG.h:
This file had some small changes:
From: #include <osgViewer/GraphicsWindowWin32>
To: #include <osgViewer/api/win32/GraphicsWindowWin32>
Also added two new function declarations
Void PreFrameUpdate(void);
Void PostFrameUpdate(void);
MFC_OSG.cpp:
This file changed only in that I am explicitly showing the viewer run loop and added the two new functions in the MFC_OSG.h file.
"
the osgsimpleviewerQt4 example in my Visual studio solutions... After
looking into it it seems that you cannot have both Qt3 and Qt4
enabled. After modifying the root CMakeLists.txt to use :
FIND_PACKAGE(Qt) which should ask you to choose betwwen Qt3 and Qt4
if you have both
instead of :
FIND_PACKAGE(Qt3)
FIND_PACKAGE(Qt4)
I had the project generated. But then due to the way CMake handles Qt4
I had to modify osgsimpleviewerQt4's CMakeLists.txt to have the binary
link with QtOpengl4. "
"Attached is a patch allows access access to the CMake MACOSX_BUNDLE
option. Now SETUP_APPLICATION and SETUP_EXAMPLE take an additional
optional parameter that specifies if the program is a command line
application or a GUI application (think: IS_COMMANDLINE_APP). Passing
1 means true (is_commandline_app). Passing 0 or omitting the parameter
means false.
I changed the scripts for osgversion and osgunittests to support this
option because I believe they are command line apps. Are there any
others?"
