the matrix.getRotate() function when a matrix contains a scale as well
as a rotation.
The scale can optionally be switched off, see the top of
testQuatFromMatrix().
As expected, all the current methods for mat to quat conversion fail
these new tests. When the scale is omitted, mk2 of getRotate with sign
instead of signOrZero passes, as well as mk1.
"
Changed this back to setup_example since WIN32 flag is now supported.
MFC_OSG.h:
Added flag to indicate when the rendering thread has exited.
MFC_OSG.cpp:
Code modifications to support rendering flag thread exit.
MFC_OSG_MDIView.cpp:
Change to OnDestroy function to wait until we get render thread exit flag is true before we close the window.
Main Exit Process:
User presses escape button
Viewer captures escape button and stops threading etc.
Viewer sets Done when shutdown is complete
MFC Render Thread monitors viewer->done for true
MFC Render Thread exits while loop and sets MFC Done flag
MFC View Window monitors MFC Done flag and then closes/destroys the window
"
"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?"
It should not be introusive to any other palatform apart MSVC, but in order to link to debug-specific libs
I had to change plugins CMakeLists to differentiate debug/release linkage, I have used the same macro used in core libs
Now the macro used for plugin and examples linking test for existance of TARGET_LIBRARIES_VARS
that holds the names of the variables that have to be used for linking"
