http://www.mail-archive.com/osg-users@lists.openscenegraph.org/msg23734.html
The change is source compatible with current osg code and will not affect current users, it simply adds an additional parameter to the GraphicsWindowWin32::WindowData struct constructor and defaults to the current behavior.
Attached are the files "include/osgViewer/api/Win32/GraphicsWindowWin32" and "src/osgViewer/GraphicsWindowWin32.cpp" with my changes, based on svn revision 10045. In addition, I have provided an svn patch file with the same changes for your convenience.
I have discussed the matter with my supervisor, and agreed that my company makes no copyright claim over this extremely trivial change (or to put it another way, we assign copyright to the open scene graph community.)"
The osgViewer::CompositeViewer had partial support for Producer Camera
config files, but it was not working completely. Here is the completed
implementation. File: src/osgViewer/CompositeViewer.cpp.
"
linked with system libraries using LINK_INTERNAL instead of
LINK_EXTERNAL. This caused it to try to link with libXrandrd instead of
libXrandr, which failed. Attached is the fixed CMakeLists.txt."
Also, there was also a small bug in osgDB's CMakeLists.txt that was causing an error when I tested with CMake 2.4.4.
IF(${OSG_DEFAULT_IMAGE_PLUGIN_FOR_OSX} STREQUAL "quicktime")
was changed to
IF(OSG_DEFAULT_IMAGE_PLUGIN_FOR_OSX STREQUAL "quicktime")
"
some stuff out into DarwinUtils.h/.mm so both implementations can share
some of the code. There's even a bugfix for GraphicsWindowCarbon, which
fixes some issues with multiple windows on different screens."
"There is error in WoW shader, you can see it by this simple example:
osgviewer cessna.osg --wowvx-42 --clear-color 0,0,0
Clear color may be choosed any with at least one component equals to 0
or 1. In my case I see weird blinking between normal image and image
with depth map at right side on the screen."
Because there already exists the option to convert slow path geometry to the fast path by computing an internal fast path alternative, I added a new optimizer option that automatically does this. To check the results I also made some changes to the statistics gathering and rendering.
Somewhat unrelated, but also part of the optimizer I disabled removal of CameraView nodes during RemoveRedundantNodes optimization.
As discussed on the ML, CameraViews were removed from the scenegraph. This solves that issue.
Summary:
-Geometry::areFastPathsUsed now also looks at internalOptimizedGeometry
-Added Optimize option to make all slow path geometry compute their internal fast path alternative
-Added fast geometry counter to the statistics
-Disabled removel of CameraViews in optimizer
"
- The text and dark background rectangles are now correctly placed, and
slightly resized here and there.
- All counters (vertices, etc) now use a fixed formatting with 0 digits
precision, to prevent the text from being shown in scientific notation
when the number get large (e.g. 6.34344e+6). I tested with a scene
containing roughly 4 million vertices, to make sure its stats would
display correctly.
I also made slight changes to osgcompositeviewer (attached) to aid in
testing the stats display, specifically displaying of camera and view
names."
It's a minimal change, it just calls an already existing protected method. It was trivial to subclass the handler to do it in our code, but pushing the change into OSG makes sense as it's generally useful to have it in the handler itself.
I also noticed that the handle() method was overridden from osgGA::GUIEventHandler but wasn't marked virtual. It wasn't intended that subclasses not be able to override it in turn, so I've added the keyword.""
GraphicsWindowCarbon::requestWarpPointer() places the mouse pointer in a (global?) display coordination, but it must be in a local window coordination. This problem is critical because the mouse cursor can go off a window especially when you place the window on the secondary screen.
Attached is the file to fix this problem.
I tested this modified file with the following situations (on FlightGear) and all works fine.
- two windows on two screens (each has one window).
- two windows on two screens (secondary screen has all windows).
- two windows on two screens (primary screen has all windows).
In all scenarios, warp requests (by right-click the mouse) successfully moves the mouse pointer to the center of the main window,
and it is what it's supposed to be in the flightgear."
consider these initial cpack support scripts. It is hidden behind a
BUILD_PACKAGES option so won't affect the normal user. The submission
1) set the COMPONENT attribute on all cmake install commands.
COMPONENT names are according to
http://www.openscenegraph.org/projects/osg/wiki/Community/Packaging
2) provide cmake script and a template for creating CPack
configuration files. It will generate target for creating packages
with everything that gets "installed" (make package on unx, project
PACKAGE in MSVC) plus targets for generating one package per COMPONENT
(i.e. libopenscenegraph-core etc.).
I have temporariliy uploaded some examples to
http://www.openscenegraph.org/projects/osg/wiki/Community/People/MattiasHelsing
If this submission makes it into svn we can develop it to generate
rpms, installers for windows and mac (I know at least J-S don't like
these but there may be others who do ;) and even DEBs (not sure if we
can make them "ubuntu-ready" but they eventually may - at least we
could put a deb on the website)"
