osgViewer behaves smarter, when the computer will reboot or shutdown. In
older versions the reboot/shutdown got cancelled by GraphicsWindowCocoa,
now it behaves more system conform.
"
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."
Mathieu Marache, he added the last missing piece to this puzzle.
I think it is safe to commit these changes to trunk, as the traditional
way via dylibs should work as before.
Here's some more info how to get frameworks:
With these modifications it is possible to compile frameworks on OS X,
when you set the Cmake-option OSG_COMPILE_FRAMEWORKS to true. If you
want to embed the frameworks in your app-bundle make sure to set
OSG_COMPILE_FRAMEWORKS_INSTALL_NAME_DIR accordingly.
You'll have to build the install-target of the generated xcode-projects
as this sets the install_name_dirs of the frameworks and plugins."
"Here is a small fix in the eventTraversal() function of both viewer
and composite viewer class.
if (getCameraWithFocus())
{
if (getCameraWithFocus()!=getCamera()) // Newly added
{
osg::Viewport* viewport = getCameraWithFocus()->getViewport();
osg::Matrix localCameraVPW =
getCameraWithFocus()->getViewMatrix() *
getCameraWithFocus()->getProjectionMatrix();
if (viewport) localCameraVPW *= viewport->computeWindowMatrix();
osg::Matrix matrix( osg::Matrix::inverse(localCameraVPW) *
masterCameraVPW );
osg::Vec3d new_coord = osg::Vec3d(x,y,0.0) * matrix;
x = new_coord.x();
y = new_coord.y();
}
...
}
I put an additional conditional statement here to ensure that
_cameraWithCamera and _camera are different, otherwise it's no need to
calculate the transition matrix from main camera to focus camera. The
excess calculations of 'matrix' and 'new_coord' may cause
floating-point error and return a slightly wrong result other than an
identity matrix. It seems OK in most cases but will be still pain when
there is little difference between two mouse moving events. "
To reproduce, on win32:
-Run osgViewer in a windowed mode, with the cursor off, as such:
osgViewer::Viewer::Windows windows;
viewer.getWindows(windows);
for(osgViewer::Viewer::Windows::iterator itr = windows.begin();
itr != windows.end();
++itr)
{
(*itr)->useCursor( false );
}
-Quickly move the cursor into the window (cursor it should be hidden)
-Resize the window by dragging the border (notice the cursor changes to "resize" cursor)
-Move the cursor back to the inside of the window (notice the cursor is not hidden anymore)
The attached SVN patch will set the cursor to a "NoCursor" during useCursor(false). This correctly stores the no cursor state, so it can be rejuvenated after a future cursor change. This patch also fixes a couple instances where a hidden cursor should show itself, like when it's on the title bar, or the window close button."
> quote from http://www.opengl.org/registry/specs/ARB/wgl_pbuffer.txt
> The following attributes are supported by wglCreatePbufferARB:
>
> WGL_PBUFFER_LARGEST_ARB If this attribute is set to a
> non-zero value, the largest
> available pbuffer is allocated
> when the allocation of the pbuffer
> would otherwise fail due to
> insufficient resources. The width
> or height of the allocated pbuffer
> never exceeds <iWidth> and <iHeight>,
> respectively. Use wglQueryPbufferARB
> to retrieve the dimensions of the
> allocated pbuffer.
It notifies the user when the size is not as requested, but I could find no way for the program to detect this. I've added two lines to write the new size back into the _traits, I think this is appropriate, but I am not absolutely sure.
In PixelBufferX11 was no support, so I've added GLX_LARGEST_PBUFFER(_SGIX) support, with the same writeback to the _trais.
I have tested the GLX_LARGEST_PBUFFER version on linux and the WGL_PBUFFER_LARGEST_ARB with windows, all tested with the modified autocapture I just submitted.
"autocapture --pbuffer --window 100 100 18192 18192 cow.osg.\[0,0,-22.7\].trans"
gives me a 4096x4096 image on my windows machine,
and a 8192x8192 image on linux."
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.
In Scene::updateSceneGraph(), change:
if (getSceneData())
{
updateVisitor.setImageRequestHandler(getImagePager());
getSceneData()->accept(updateVisitor);
}
if (getDatabasePager())
{
// synchronize changes required by the DatabasePager thread to the scene graph
getDatabasePager()->updateSceneGraph((*updateVisitor.getFrameStamp()));
}
to
if (getDatabasePager())
{
// synchronize changes required by the DatabasePager thread to the scene graph
getDatabasePager()->updateSceneGraph((*updateVisitor.getFrameStamp()));
}
if (getSceneData())
{
updateVisitor.setImageRequestHandler(getImagePager());
getSceneData()->accept(updateVisitor);
}
That is, just swap the positions of two 'if () {...}' segments.
While working on a paged terrain, I need to collect every newly allocated PagedLODs and make them temporarily unrenderable in the next frame, which are all done in a update callback. But I found that these PagedLODs will always be shown before collecting them, because of the unsuitable sequence in Scene::updateSceneGraph(). DatabasePager is synchronized AFTER the user updating traversal, that is, user cannot IMMEDIATELY find out changes made by DatabasePager.
"
