I found very useful to have a control whether osgView::setCameraManipulator does or does not reset camera to home position.
I extended method signature as follows:
void setCameraManipulator(osgGA::MatrixManipulator* manipulator, bool resetPosition = true);
keeping the current usage intact (default parameter), while enabling user to disable the position reset. That can be useful in the situation when manipulator position was already loaded, for example from a file (user specification), or defined any other way, while we do not want to be reset to home position. Other usability is usage of two manipulators in a modeling program (orbiting around the model, walking on the model) and changing between them while we want to preserve the position of a camera in the change. Games may benefit from it as well when we change from user-defined helicopter manipulator to soldier manipulator because the user escaped the helicopter. The camera will change manipulator but the position is expected to be kept in the transition (provided that user makes the state transition between the two manipulators himself).
"
osg::GraphicsContext, in order to give good integration with the
application's GUI toolkit. This works really well.
However, I need to share OpenGL texture resources with the standard
osgViewer GraphicsContext implementations, in particular the
PixelBuffers. This is essential for my application to conserve graphics
memory on low-end hardware. Currently the standard osg implementations
will not share resources with another derived osg::GraphicsContext,
other than the pre-defined osgViewer classes e.g. PixelBufferX11 is
hardcoded to only share resources with GraphicsWindowX11 and
PixelBufferX11 objects, and no other osg::GraphicsContext object.
To address this in the cleanest way I could think of, I have moved the
OpenGL handle variables for each platform into a small utility class,
e.g. GraphicsHandleX11 for unix. Then GraphicsWindowX11, PixelBufferX11
and any other derived osg::GraphicsContext class can inherit from
GraphicsHandleX11 to share OpenGL resources.
I have updated the X11, Win32 and Carbon implementations to use this.
The changes are minor. I haven't touched the Cocoa implmentation as
I'm not familiar with it at all and couldn't test it - it will work
unchanged.
Without this I had some horrible hacks in my application, this greatly
simplifies things for me. It also simplifies the osgViewer
implementations slightly. Perhaps it may help with other users'
desires to share resources with external graphics contexts, as was
discussed on the user list recently."
Notes from Robert Osfield, adapted Colin's submission to work with the new EGL related changes.
I've needed to run a recorded simulation offscreen and save it to a sequence of images, and the ScreenCaptureHandler seemed to be the simplest way to do that, and with this change it's possible.
Another change: I've also added the ability to specify continuous capture of all frames, or a certain number of frames. ScreenCaptureHandler now has a setFramesToCapture(int) method. The argument will be interpreted as:
0 : don't capture
<0 : capture continuously
>0 : capture that number of frames then stop
I also added startCapture() and stopCapture() methods so that user code can start capturing (either continuously or the given number of frames) at a given point in their program. setFramesToCapture() won't start capturing, you have to call startCapture() afterwards. The handler also now has another key to toggle continuous capture (defaults to 'C').
Note that continuous capture will of course only work if the CaptureOperation writes to different files (for example, a WriteToFile with SEQUENTIAL_NUMBER mode) or does something different each time... Otherwise it will just overwrite of course. :-)
I've also taken the chance to refactor the addCallbackToViewer() method a bit too, since finding the right camera is needed in two places now.
I've tested all cases (I think). If you want to try, in osgviewer.cpp and replace the line
// add the screen capture handler
viewer.addEventHandler(new osgViewer::ScreenCaptureHandler);
with
// add the screen capture handler
osgViewer::ScreenCaptureHandler* captureHandler = new
osgViewer::ScreenCaptureHandler(
new osgViewer::ScreenCaptureHandler::WriteToFile(
"screenshot", "jpg",
osgViewer::ScreenCaptureHandler::WriteToFile::SEQUENTIAL_NUMBER),
-1);
viewer.addEventHandler(captureHandler);
captureHandler->startCapture();
And vary the "-1" (put 0, 10, 50) and then use the 'c' and 'C' keys and see how it reacts.
"
GraphicsWindowCocoa-implementation, which enhances multithreaded
stability, it ensures that modifications to the size of an openglcontext
is done only from one thread.
"
implementation of GraoicsWindowCocoa:
Enhancements/Bugfixes:
+ now it's possible to integrate osgViewer better into existing
cocoa-applications:
* create one or more NSOpenGLView(s) and add these to your window(s)
* create one or more NSWindows
* disable the integrated event-polling of osgViewer, and let the work be
done by Cocoa / NSApplicationRun. You'll have to run the osgViewer's
runloop in a separate thread
+ missing menu-event-handling implemented
+ added NSAutoReleasePools where necessary, this fixes some memory-leaks
+ fixed some crashes and thread-issues"
Original email from Frederic at start of thread:
"he patch attached, made from r10068, fix two things, in other of importance :
- the selected cursor is never shown ( second change in file ). Only the left arrow is always displayed.
- remove the arbitrary ( in my sense ) limitation that the user cannot choose a cursor with the same shape that one used when resizing the window. This limitation doesn't exist for X11, and we have a diverging behaviour there ( first change in file ). Flightgear use the LeftRightCursor in look around mode."
Follow up email from Frederic (with changes that finally made it into this check in:
"I've just tested Mark's suggestion and it works perfectly, even when the
cursor goes to the border then come back inside the window.
But his patch doesn't seem to be based on the last revision of the
files, or at least not on the trunk, and there are more changes than
expected in them, including some loss from the previous patches.
The patch attached is based on r10068 of
src/osgViewer/GraphicsWindowWin32.cpp and r10067 of
include/osgViewer/api/Win32/GraphicsWindowWin32"
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.)"
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.""
set to off. But could be activated/decativated via CMake as well as system
environment variable. I also modified src\osgViewer\CMakeLists.txt to turn
off this workaround by default as suggested."
facilitate the subclassing of Image providing interactive behaviours so as
used in the vnc interactive VncImage class.
osgViewer::InteractiveImageHandler provides an event handler that convertes osgGA
mouse and keyboard events into the coordinate frame of an image based on ray intersection with geometry in
the associated subgraph.
Changed the ordering of events processing in Viewer and CompositeViewer to allow
scene graph event handlers to take precidence over viewer event handlers and camera manipulators
This code will add two extra statistics options:
-Camera scene statistics, stats for the scene after culling (updated at 10 Hz)
-View scene statistics, stats for the complete scene (updated at 5 Hz)
Each camera and each view will expand the statistics to the right.
I also added the requests and objects to compile of the databasepager to the databasepager statistics.""
viewer.addEventHandler(new osgViewer::ScreenCaptureHandler(
new osgViewer::WriteToFileCaptureOperation("filename", "jpg")));
and the filename will be what you want. The WriteToFileCaptureOperation will add the context ID and the file number (if in SEQUENTIAL_NUMBER mode) to the file name.
(The attached also clarifies some notify messages, and corrects the comment when adding the handler in osgviewer.cpp)
I also remembered, the current architecture could allow a different CaptureOperation for each context, but currently the API only allows setting one CaptureOperation for all contexts. This could be improved if need be.
"
