Re: [osg-users] Shadows in osgviewerQT ? (solved / patch)
On Sun, Nov 2, 2008 at 6:38 PM, Julian Scheid [EMAIL PROTECTED]wrote: - 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. Just realized that this won't compile outside of OS X. Not sure what the best solution is, could do an ifdef in QOSGWidget.cpp or, maybe better, change Carbon WindowData to carry an HIViewRef instead of a WindowPtr - though I don't know the implications of that. Julian ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Shadows in osgviewerQT ? (solved / patch)
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
Re: [osg-users] Shadows in osgviewerQT ?
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-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Shadows in osgviewerQT?
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-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
