Hi again,
please find attached a patch against current trunk that fixes my problems.
This patch does the following (in order of the chunks in the patch):
- Add a missing include in GraphicsWindowsX11 without which it won't compile
on my Mac.
- Add a missing include to the osgviewerQt build (taken straight from
src/osgviewer/CMakeLists.txt)
- Ensure GraphicsWindowsCarbon::WindowData is used with QOSGWidget for Mac
builds even on 10.4 and 10.5. Without this change, the widget will use the
X11 WindowData struct but the peer will expect a Carbon WindowData struct,
leading to a segfault. I'm not sure this is the right fix - it might have to
pay attention to other configure-time variables. (I.e. it might not work if
you asked for using the X11 peers instead of the carbon peers at configure
time)
- Extract a WindowPtr from the HIViewRef that QWidget::winId() returns.
Without this change, the peer tries to call GetWindowPort on the HIViewRef
which returns 0. This was the reason that the window remained white.
- Setup the camera only after ViewerQOSG's Qt base class has been
initialized. Without this change, the view is wrong (doesn't cover the whole
window).
- Open the ViewerQOSG window at 30/30 instead of 0/0. When opened at 0/0 it
lacks any window decoration (not sure why that is so - might be a Qt
feature?)
I hope this helps.
Cheers,
Julian
On Fri, Oct 31, 2008 at 12:26 PM, Julian Scheid [EMAIL PROTECTED]wrote:
Hi,
OK so I figured out that my problems are due to using AdapterWidget - I
understand that shadows etc. should work fine with QOSGWidget.
Unfortunately QOSGWidget doesn't work here: the widgets remains white and
Qt prints warnings about recursive repaint.
I've checked out the latest OSG trunk and tried with that but get the same
result (actually it segfaults due to a bogus ifdef in the QOSGWidget source
code - I'll send over a patch shortly - but after fixing that I get the same
result.)
I've started tracking down the problem, so far the only thing that I
figured out is that GetWindowPort always seems to return 0 for the
QOSGWidget's native peer - is that expected?
I'm using Qt 4.4.3 on an Intel Mac with OS X 10.5. The Carbon code paths
are used, not X11. Are there any known problems with QOSGWidget with Qt
4.4, OS X 10.5 or with the Carbon peers?
Thanks in advance,
Julian
On Thu, Oct 30, 2008 at 3:30 AM, Julian Scheid [EMAIL PROTECTED]wrote:
Hi,
I'm trying to embed osg in a Qt4 application. I've had some troubles with
FSAA/multisampling but managed to work around it by configuring the
QGLWidget for FSAA instead of osg.
However, I'm now trying to get shadows to work based on the osgshadow
code, and it seems that no matter which shadowing technique I try it brings
my machine to a grinding halt - the whole screen starts to flicker wildly,
circles and balls reminiscent of Katamari Damacy are drawn into the scene,
and when continuous update (via timer) is enabled I have no recourse but to
restart my machine. (This is one of the new Intel Macbooks running OS X
10.5)
I gather that when embedded in Qt, the GraphicsWindowCarbon code isn't
used and osg just uses the existing GL context. Does that mean that I would
have to manually setup Qt's GL context and somehow synchronize it with osg's
shadow magic?
If all that is meant to be supported in the Qt viewer, is there any chance
you could add an example for this situation?
Thanks in advance,
-Julian
osg-qosgwidget-osx.patch
Description: Binary data
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org