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).
"
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"
