10.6), which will forward all multi-touch events from a trackpad to the
corresponding osgGA-event-structures.
The support is switched off per default, but you can enable multi-touch
support via a new flag for GraphicsWindowCocoa::WindowData or directly
via the GraphicsWindowCocoa-class.
After switching multi-touch-support on, all mouse-events from the
trackpad get ignored, otherwise you'll have multiple events for the same
pointer which is very confusing (as the trackpad reports absolute
movement, and as a mouse relative movement).
I think this is not a problem, as multi-touch-input is a completely
different beast as a mouse, so you'll have to code your own
event-handlers anyway.
While coding this stuff, I asked myself if we should refactor
GUIEventAdapter/EventQueue and assign a specific event-type for
touch-input instead of using PUSH/DRAG/RELEASE. This will make it
clearer how to use the code, but will break the mouse-emulation for the
first touch-point and with that all existing manipulators. What do you
think? I am happy to code the proposed changes.
Additionally I created a small (and ugly) example osgmultitouch which
makes use of the osgGA::MultiTouchTrackballManipulator, shows all
touch-points on a HUD and demonstrates how to get the touchpoints from
an osgGA::GUIEventAdapter.
There's even a small example video here: http://vimeo.com/31611842"
Line 251:
int getKeyEventWindowedResolutionDown() const { return _keyEventWindowedResolutionUp; }
Should be replaced with:
int getKeyEventWindowedResolutionDown() const { return _keyEventWindowedResolutionDown; }"
UIView, respecting the sizes via GraphicsContext::Traits.
This helps users, who want to integrate osg into an existing ios-app
with multiple UIViews. Additinally a view-controller gets only created
if needed, set IGNORE_ORIENTATION via the WindowData-struct.
"
CID 11836: Uninitialized scalar field (UNINIT_CTOR)
Non-static class member _fullscreen is not initialized in this constructor nor in any functions that it calls.
implement the recently introduced setSyncToVBlank-method.
Additionally I added a ToggleSyncToVBlank-eventhandler to osgViewer. I
used it to test the code, perhaps you'll find it useful and include it
in the distribution."
I also fixed the vsync implementation introduced with rev.11357 that was crashing with the Windows Error #170. So I removed your temporary /* */ around the vsync condition..."
enum DeviceOrientation{
PORTRAIT_ORIENTATION = 1<<0,
PORTRAIT_UPSIDEDOWN_ORIENTATION = 1<<1,
LANDSCAPE_LEFT_ORIENTATION = 1<<2,
LANDSCAPE_RIGHT_ORIENTATION = 1<<3,
ALL_ORIENTATIONS = PORTRAIT_ORIENTATION | PORTRAIT_UPSIDEDOWN_ORIENTATION | LANDSCAPE_LEFT_ORIENTATION | LANDSCAPE_RIGHT_ORIENTATION
};
typedef unsigned int DeviceOrientationFlags;
The main motivation for this is to easily allow the user to specifiy that the device is in a horizontal orientation rather then having to rotate the view matrix. All flags have been tested individually as well as in combinations. The default is ALL_ORIENTATIONS to keep the exiting functionality for anyone who hasn't specified WindowData for their context traits.
"
that the windows did not act on repaint request (WM_PAINT, EXPOSE,...)
Detailed explanation:
- I implemented requestRedraw using the push approach (not using
GraphicsWindow::_requestRedraw flag that I was considering) as there may be
multiple viewers reading the flag and fighting to reset it after the paint
request, while some viewers may not spot the request to redraw
- I made windows call GraphicsWindow::requestRedraw when they receive
appropriate message (WM_PAINT, EXPOSE, RESIZE,...)
- There were issues on Linux that windows did not want to close using x
button. Resolved by moving the test for DeleteWindow event from
swapBuffersImplementation() to GraphicsWindowX11::checkEvents(). The difficulty
was that DeleteWindow event is not coming using _eventDisplay, but through
_display.
- The last difficulty was that it is necessary to call
ViewerBase::checkWindowStatus() to set _done to true when all windows are
closed. This did not happened recently in ON_DEMAND run scheme. I put the call
to checkWindowStatus() to eventTraversal.
"
disable pragmas that turn off specific warnings for MSVC.
Unfortunately it's presence is only checked in osg/Export header,
making other Export headers disable warnings no matter what, which is
kind of incoherent.
My fix adds #include <osg/Config> to every Export header. I've also
unified checking whether to disable warnings to current osg/Export
way:
#if defined(_MSC_VER) && defined(OSG_DISABLE_MSVC_WARNINGS).
Attachment contains all changed Export files in their original locations."
/** Convenience method for setting up multiple slave cameras that depth partition the specified camera.*/
bool setUpDepthPartitionForCamera(osg::Camera* cameraToPartition, DepthPartitionSettings* dps=0);
/** Convenience method for setting up multiple slave cameras that depth partition each of the view's active cameras.*/
bool setUpDepthPartition(DepthPartitionSettings* dsp=0);
and another problem is:
example osgkeyboard is not work (keys not highlight) if user have 2 keyboard layout native and english and current user layout is native
I try to explain my changes
we need something that is identify key without modifier keys and layout -> this is UnmodifedKey
I think osg must have its own UnmodifiedKeys table. Code must be run same on different platforms. This can de guaranteed by UnmodifiedKeys table.
Mikhail Izmestev helped me. He implemented VirtualKey changes in GraphicsWindowX11"
attached you'll find the second part of the IOS-submission. It contains
* GraphicsWindowIOS, which supports external and "retina" displays,
multisample-buffers (for IOS > 4.0) and multi-touch-events
* an ios-specific implementation of the imageio-plugin
* an iphone-viewer example
* cMake support for creating a xcode-project
* an updated ReadMe-file describing the necessary steps to get a
working xcode-project-file from CMake
Please credit Thomas Hogarth and Stephan Huber for these changes.
This brings the ios-support in line with the git-fork on github. It
needs some more testing and some more love, the cmake-process is still a
little complicated.
You'll need a special version of the freetype lib compiled for IOS,
there's one bundled in the OpenFrameworks-distribution, which can be used."
Notes, from Robert Osfield, modified CMakeLists.txt files so that the IOS specific paths are within IF(APPLE) blocks.
Initial email from Tim : "I've implemented using a timestamp, available with ARB_timer_query and OpenGL 3.3, to gather GPU stats. This is nice because it can accurately fix the GPU draw time with respect to the other times on the stats graph, rather than having to estimate the wall time of the end of GPU drawing. This also prevents anomalies like the GPU phase starting before the draw phase..."
Changes to Tim's submission by Robert: Removal of need for swap buffer callback in ViewerBase.cpp, by
integrating a osg::State::frameCompleted() method that does the stats timing collection. Introduction of a
GraphicsContext::swapBuffersCallbackOrImplementation() method that calls the State::frameCompleted() and
the swap buffers callback or the swapImplementation as required.
Also I've done the osguserstats example. I've kept the "toy example" that was in the modified osgviewer.cpp I had sent you, because they show different uses of custom stats lines (a value displayed directly, a value without bars and a value with bars and graph). I also added a function and a thread that will sleep for a given number of milliseconds and record this time in the stats. I think it clearly shows how to record the time some processing takes and add that to the stats graph, whether the processing takes place on the same thread as the viewer or on another thread.
BTW, feel free to modify the colors I've given to each user stats line... I'm not very artistic. :-)
I've also added more doc comments to the addUserStats() method in ViewerEventHandlers, so hopefully the arguments are clear and the way to get the results you want is also clear. Maybe I went overboard, but the function makes some assumptions that may not be obvious and has many arguments, so I preferred to be explicit."
The user calls statsHandler->addUserStatsLine() providing:
- the label they want for that line in the graph
- the text and bar colors they want in the graph
- the stats names they want queried (one for time taken, one for begin and one for end time) and a few settings for how these will be displayed.
Then all they have to do is call viewer->getViewerStats()->setAttribute(framenumber, name, value) for their three attributes each frame and they'll have their stats in the graph.
They can also give only a time taken attribute (or some other numerical value they want printed, which can be averaged or not), or only begin+end attributes, and the graph will accordingly display only the (average or not) numerical value or only the bars.
Along the way I cleaned up the existing code a bit:
* Each time the setUpScene() or createCameraTimeStats() methods added a line to the graph, they did pretty much the same thing, so I moved that into a separate method called createTimeStatsLine() which is called by setUpScene() and createCameraTimeStats().
* I moved the font, characterSize, startBlocks and leftPos variables to member variables, since they were being passed around everywhere but were set only once at the beginning.
* The geode on which stats lines are added is also kept in a member variable, and createCameraTimeStats() adds the per-camera lines to this geode instead of returning a new Group with a new Geode. This further reduces the number of variables the createCameraTimeStats() method needs as input.
"
to get QWidgetImage to a point where it can fill a need we have: to be
able to use Qt to make HUDs and to display widgets over / inside an OSG
scene.
---------------
Current results
---------------
I've attached what I have at this point. The modified QWidgetImage +
QGraphicsViewAdapter classes can be rendered fullscreen (i.e. the Qt
QGraphicsView's size follows the size of the OSG window) or on a quad in
the scene as before. It will let events go through to OSG if no widget
is under the mouse when they happen (useful when used as a HUD with
transparent parts - a click-focus scheme could be added later too). It
also supercedes Martin Scheffler's submission because it adds a
getter/setter for the QGraphicsViewAdapter's background color (and the
user can set their widget to be transparent using
widget->setAttribute(Qt::WA_TranslucentBackground) themselves).
The included osgQtBrowser example has been modified to serve as a test
bed for these changes. It has lots more command line arguments than
before, some of which can be removed eventually (once things are
tested). Note that it may be interesting to change its name or split it
into two examples. Though if things go well, the specific QWebViewImage
class can be removed completely and we can consolidate to using
QWidgetImage everywhere, and then a single example to demonstrate it
would make more sense, albeit not named osgQtBrowser... You can try this
path by using the --useWidgetImage --useBrowser command line arguments -
this results in an equivalent setup to QWebViewImage, but using
QWidgetImage, and doesn't work completely yet for some unknown reason,
see below.
----------------
Remaining issues
----------------
There are a few issues left to fix, and for these I request the
community's assistance. They are not blockers for me, and with my
limited Qt experience I don't feel like I'm getting any closer to fixing
them, so if someone else could pitch in and see what they can find, it
would be appreciated. It would be really nice to get them fixed, that
way we'd really have a first-class integration of Qt widgets in an OSG
scene. The issues are noted in the osgQtBrowser.cpp source file, but
here they are too:
-------------------------------------------------------------------
QWidgetImage still has some issues, some examples are:
1. Editing in the QTextEdit doesn't work. Also when started with
--useBrowser, editing in the search field on YouTube doesn't
work. But that same search field when using QWebViewImage
works... And editing in the text field in the pop-up getInteger
dialog works too. All these cases use QGraphicsViewAdapter
under the hood, so why do some work and others don't?
a) osgQtBrowser --useWidgetImage [--fullscreen] (optional)
b) Try to click in the QTextEdit and type, or to select text
and drag-and-drop it somewhere else in the QTextEdit. These
don't work.
c) osgQtBrowser --useWidgetImage --sanityCheck
d) Try the operations in b), they all work.
e) osgQtBrowser --useWidgetImage --useBrowser [--fullscreen]
f) Try to click in the search field and type, it doesn't work.
g) osgQtBrowser
h) Try the operation in f), it works.
2. Operations on floating windows (--numFloatingWindows 1 or more).
Moving by dragging the titlebar, clicking the close button,
resizing them, none of these work. I wonder if it's because the
OS manages those functions (they're functions of the window
decorations) so we need to do something special for that? But
in --sanityCheck mode they work.
a) osgQtBrowser --useWidgetImage --numFloatingWindows 1
[--fullscreen]
b) Try to drag the floating window, click the close button, or
drag its sides to resize it. None of these work.
c) osgQtBrowser --useWidgetImage --numFloatingWindows 1
--sanityCheck
d) Try the operations in b), all they work.
e) osgQtBrowser --useWidgetImage [--fullscreen]
f) Click the button so that the getInteger() dialog is
displayed, then try to move that dialog or close it with the
close button, these don't work.
g) osgQtBrowser --useWidgetImage --sanityCheck
h) Try the operation in f), it works.
3. (Minor) The QGraphicsView's scrollbars don't appear when
using QWidgetImage or QWebViewImage. QGraphicsView is a
QAbstractScrollArea and it should display scrollbars as soon as
the scene is too large to fit the view.
a) osgQtBrowser --useWidgetImage --fullscreen
b) Resize the OSG window so it's smaller than the QTextEdit.
Scrollbars should appear but don't.
c) osgQtBrowser --useWidgetImage --sanityCheck
d) Try the operation in b), scrollbars appear. Even if you have
floating windows (by clicking the button or by adding
--numFloatingWindows 1) and move them outside the view,
scrollbars appear too. You can't test that case in OSG for
now because of problem 2 above, but that's pretty cool.
4. (Minor) In sanity check mode, the widget added to the
QGraphicsView is centered. With QGraphicsViewAdapter, it is not.
a) osgQtBrowser --useWidgetImage [--fullscreen]
b) The QTextEdit and button are not in the center of the image
generated by the QGraphicsViewAdapter.
c) osgQtBrowser --useWidgetImage --sanityCheck
d) The QTextEdit and button are in the center of the
QGraphicsView.
-------------------------------------------------------------------
As you can see I've put specific repro steps there too, so it's clear
what I mean by a given problem. The --sanityCheck mode is useful to see
what should happen in a "normal" Qt app that demonstrates the same
situation, so hopefully we can get to a point where it behaves the same
with --sanityCheck and without."
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).
"
