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.
"
avoid threading issues associated with compile running in a parallel with
update/cull on the first frame.
Also added automatic recompile when a new SceneData is applied to a View.
get an excess Tab key report when switching back to an OSG
application (usually FlightGear :-). Although KDE has consumed
the Tab, it's sometimes still in the XKeymapEvent's key_vector,
and followed by a Tab KeyRelease event.
Avoid this artifact by
- asking for a "fresh" keymap (via XQueryKeymap()), rather than
using the unreliable(?) XKeymapEvent's key_vector, and by
- flushing all key events on focus-in (to avoid the KeyRelease)
After Super-press, Tab-press, Super-release, Tab-release (note
the wrong release order!) I still get an extra Tab event. But
this is not surprising and not exactly wrong either. Also it's
hard to avoid, as we can't see what happened to the keyboard
before we regained focus.
Files changed:
src/osgViewer/GraphicsWindowX11.cpp
include/osgViewer/api/X11/GraphicsWindowX11"
It's implemented in the same way that 3D Spherical Display and Panoramic Spherical Display.
You can test it running:
osgviewer --wowvx-20 cow.osg
osgviewer --wowvx-42 cow.osg
depending on the size of your Philips WOWvx display (20" or 42")
Other arguments you can use to control the 3D effect are:
--wow-content <value>
This value defines the kind of content that can be:
0: No depth
1: Signage
2: Movie
3: CGI
4: Still
--wow-factor <value>
Percentage of the display recommended depth value. Default 64, Range [0-255]
--wow-offset <value>
Amount of range behind the screen. Default 128, Range [0-255]
0: Range is shifted in the direction of the viewer.
128: Range is equally divided in front and behind the screen.
255: Range is shifted away from the viewer.
"
key, but it didn't pick up the initial state. So, if NumLock was on for
the OS at startup (LED on), it was still off for OSG. And the first
keypress turned the LED off, and NumLock on for OSG. The attached fix
picks up the state on every FocusIn, just like it was done in the last
commits for CapsLock. The difference is, that the NumLock mask isn't
standardized (e.g. 0x10 for Linux, and 0x80 for AIX), so we have to do
a reverse lookup (::rescanModifierMapping()).
Note that I could not reproduce the problem on my system, but someone
else confirmed it twice on his, and the patch fixed it for him.
Changed files:
./include/osgViewer/api/X11/GraphicsWindowX11
./src/osgViewer/GraphicsWindowX11.cpp
"
It sets osgGA's keymask when restoring keys on FocusIn, according
to the state values of XKeyEvent and XCrossingEvent. (These are
the only source for X11's current capslock state that avoids
pulling in the XKB extension.)
"
The win32 pbuffer implementation returned an error unless both the
WGL_ARB_pbuffer and the WGL_ARB_render_texture functions were present.
This was too restrictive, as a pbuffer can usefully be created without
render-to-texture, e.g. for use with glReadPixels. The osg 1.2/Producer
pbuffers worked without RTT, and osgUtil::RenderStage has all the code to
handle both RTT and non-RTT pbuffers, doing a read and copy in the
latter case.
With these changes I have successfully tested the osgprerender example
on a graphics card which supports RTT, and one which doesn't. Plus
tested in my own application.
In order to aid diagnostics I have also added more function status
return checks, and associated error messages. I have included the win32
error text in all error messages output. And there were some errors
with multi-threaded handling of "bind to texture" and a temporary window
context which I have corrected.
These is one (pre-existing) problem with multi-threaded use of pbuffers
in osgViewer & osgprerender, which I have not been able to fix. A win32
device context (HDC) can only be destroyed from the thread that created
it. The pbuffers for pre-render cameras are created in
osgUtil::RenderStage::runCameraSetUp, from the draw thread. But
closeImplementation is normally invoked from the destructor in the main
application thread. With the additional error messages I have added,
osgprerender will now output a couple of warnings from
osgViewer::PixelBufferWin32::closeImplementation() at exit, after
running multi-threaded on windows. I think that is a good thing, to
highlight the problem. I looked into fixing it in osgViewer::Renderer &
osgUtil::RenderStage, but it was too involved for me. My own
application requirements are only single-threaded.
Unrelated fix - an uninitialised variable in
osg::GraphicsThread::FlushDeletedGLObjectsOperation().
"
remain in pressed state after revealing, even if they are no
longer pressed on the keyboard. This can have bad effects,
especially if the stuck keys are modifier keys. One has to
press and release the stuck keys again to reset the wrong state.
The fix keeps track of all key presses and releases. On FocusOut
and UnmapNotify it releases all keys that are in pressed state,
and on KeymapNotify (following a FocusIn), it sets the currently
pressed keys again. To avoid confusion in the OSG-using application
normal keys are always reported released /before/ and pressed
/after/ modifier keys.
As current key states are returned as char[32] keymap by
XQueryKeymap and XKeymapEvent, this format is also used to
recognize modifier keys and for maintaining the current
internal key state. Functions to set/clear/query bits in
such a keymap are added.
The patch was extensively tested with osgkeyboard and
FlightGear under KDE and fvwm2. It was not tested on a
Xinerama setup or with multiple windows, but as _eventDisplay
is used throughout, there should be no problems. The patch also
makes the following changes:
- removes old and obsolete handling of modifier keys in ::adaptKey().
This wasn't only unused, but also wrong (and for that reason commented
out in revision 7066). The modifier states are actually handled
in ./src/osgGA/EventQueue.cpp (EventQueue::keyPress/keyRelease).
- fixes some spelling"
