Re: [osg-users] SVN (2.8) bugs in osgviewerQt
Hi Morné, Thanks again for your help!! You saved me a lot of debugging headache :) You're welcome, we have to stick together when we're doing similar projects so we all move forward much faster! PS. Do you want me to submit a modified osgviewerQt example with these fixes/workarounds? It would be nice to get others' comments on these changes, so I would say yes. Plus it would allow us to test these same features in the future when other things change. J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] SVN (2.8) bugs in osgviewerQt
Hi Robert, J-S, Thanks for the suggestions! I removed the Qt event relay methods and added a dummy view with a zero sized viewport to my viewer. The single context, multiple view tiled viewer now works as expected, adding/removing views and clearing the window as it should. Thanks again for your help!! You saved me a lot of debugging headache :) Regards, Morné PS. Do you want me to submit a modified osgviewerQt example with these fixes/workarounds? On Tue, Feb 3, 2009 at 7:57 PM, Jean-Sébastien Guay jean-sebastien.g...@cm-labs.com wrote: Hi Morné, The other approach might be to create an empty View that does nothing, has no scene, but at least has a Camera with the GraphicsWindow assigned to it. It's viewport could be zero sized so would be litte more than a non op, and you have have the GraphicsWindow do the clear each frame for you. This approach why a bit inelegant would probably prevent the problems you are seeing, and would just require an additionally couple of lines of set up code at the creation time, thereafter you'd just ignore this extra View. Yep, in my testing what Robert suggests would work since as long as you have at least one view there is no problem. It's removing that last view and then adding others that brings up the problem. Sorry I couldn't find anything more definitive on my end. J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] SVN (2.8) bugs in osgviewerQt
Hi Robert,
I first posted about these problems in the Test 2.8 thread. I still
see two problems in the osgviewerQt example and managed to reproduce
both in the attached modified file.
1. Unable to spin/throw a model using QOSGWidget as a viewer.
2. viewer-addView doesn't work if the composite viewer is empty and
trying to add a new view at runtime.
These problems can be reproduced with the following command line (and
the above modified file):
osgviewerQt cessna.osg --QOSGWidget --CompositeViewer
Apart from this issue, 2.8 works fine in my application.
Thanks for all the effort you put into OSG, it really is an excellent library!
Cheers,
Morne
/* OpenSceneGraph example, osganimate.
*
* Permission is hereby granted, free of charge, to any person obtaining a copy
* of this software and associated documentation files (the Software), to deal
* in the Software without restriction, including without limitation the rights
* to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
* copies of the Software, and to permit persons to whom the Software is
* furnished to do so, subject to the following conditions:
*
* THE SOFTWARE IS PROVIDED AS IS, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
* IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
* FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
* AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
* LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
* OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
* THE SOFTWARE.
*/
#if USE_QT4
#include QtCore/QString
#include QtCore/QTimer
#include QtGui/QKeyEvent
#include QtGui/QApplication
#include QtGui/QtGui
#include QtGui/QWidget
using Qt::WindowFlags;
#else
class QWidget;
#include qtimer.h
#include qgl.h
#include qapplication.h
#define WindowFlags WFlags
#endif
#include osgViewer/Viewer
#include osgViewer/CompositeViewer
#include osgViewer/ViewerEventHandlers
#include osgViewer/GraphicsWindow
#include osgViewer/ViewerEventHandlers
#if defined(WIN32) !defined(__CYGWIN__)
#include osgViewer/api/Win32/GraphicsWindowWin32
typedef HWND WindowHandle;
typedef osgViewer::GraphicsWindowWin32::WindowData WindowData;
#elif defined(__APPLE__) // Assume using Carbon on Mac.
#include osgViewer/api/Carbon/GraphicsWindowCarbon
typedef WindowRef WindowHandle;
typedef osgViewer::GraphicsWindowCarbon::WindowData WindowData;
#else // all other unix
#include osgViewer/api/X11/GraphicsWindowX11
typedef Window WindowHandle;
typedef osgViewer::GraphicsWindowX11::WindowData WindowData;
#endif
#include osgGA/TrackballManipulator
#include osgGA/FlightManipulator
#include osgGA/DriveManipulator
#include osgGA/KeySwitchMatrixManipulator
#include osgGA/StateSetManipulator
#include osgGA/AnimationPathManipulator
#include osgGA/TerrainManipulator
#include osgDB/ReadFile
#include iostream
#include sstream
class QOSGWidget : public QWidget
{
public:
QOSGWidget( QWidget * parent = 0, const char * name = 0, WindowFlags f
= 0, bool overrideTraits = false);
virtual ~QOSGWidget() {}
osgViewer::GraphicsWindow* getGraphicsWindow() { return _gw.get(); }
const osgViewer::GraphicsWindow* getGraphicsWindow() const { return
_gw.get(); }
protected:
void init();
void createContext();
virtual void mouseDoubleClickEvent ( QMouseEvent * event );
virtual void closeEvent( QCloseEvent * event );
virtual void destroyEvent( bool destroyWindow = true, bool
destroySubWindows = true);
virtual void resizeEvent( QResizeEvent * event );
virtual void keyPressEvent( QKeyEvent* event );
virtual void keyReleaseEvent( QKeyEvent* event );
virtual void mousePressEvent( QMouseEvent* event );
virtual void mouseReleaseEvent( QMouseEvent* event );
virtual void mouseMoveEvent( QMouseEvent* event );
osg::ref_ptrosgViewer::GraphicsWindow _gw;
bool _overrideTraits;
};
QOSGWidget::QOSGWidget( QWidget * parent, const char * name, WindowFlags f,
bool overrideTraits):
#if USE_QT4
QWidget(parent, f), _overrideTraits (overrideTraits)
#else
QWidget(parent, name, f), _overrideTraits (overrideTraits)
#endif
{
createContext();
#if USE_QT4
setAttribute(Qt::WA_PaintOnScreen);
setAttribute(Qt::WA_NoSystemBackground);
setFocusPolicy(Qt::ClickFocus);
#else
setBackgroundMode(Qt::NoBackground);
#endif
}
void QOSGWidget::createContext()
{
osg::DisplaySettings* ds = osg::DisplaySettings::instance();
osg::ref_ptrosg::GraphicsContext::Traits traits = new
osg::GraphicsContext::Traits;
traits-readDISPLAY();
if (traits-displayNum0) traits-displayNum = 0;
traits-windowName = osgViewerQt;
traits-screenNum = 0;
traits-x = x();
traits-y = y();
traits-width = width();
traits-height =
Re: [osg-users] SVN (2.8) bugs in osgviewerQt
Five min. ago trunk works on Suse 10.3, but if I use --QOSGWidget a vertical black band appears on the right side of the window. No black band if I omit --QOSGWidget Hope it helps mario Morné Pistorius wrote: Hi Robert, I first posted about these problems in the Test 2.8 thread. I still see two problems in the osgviewerQt example and managed to reproduce both in the attached modified file. 1. Unable to spin/throw a model using QOSGWidget as a viewer. 2. viewer-addView doesn't work if the composite viewer is empty and trying to add a new view at runtime. These problems can be reproduced with the following command line (and the above modified file): osgviewerQt cessna.osg --QOSGWidget --CompositeViewer Apart from this issue, 2.8 works fine in my application. Thanks for all the effort you put into OSG, it really is an excellent library! Cheers, Morne ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- Ing. Mario Valle Data Analysis Group | http://www.cscs.ch/~mvalle Swiss National Supercomputing Centre (CSCS) | Tel: +41 (91) 610.82.60 v. Cantonale Galleria 2, 6928 Manno, Switzerland | Fax: +41 (91) 610.82.82 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] SVN (2.8) bugs in osgviewerQt
Hi Mario, On Tue, Feb 3, 2009 at 12:45 PM, Mario Valle mva...@cscs.ch wrote: Five min. ago trunk works on Suse 10.3, but if I use --QOSGWidget a vertical black band appears on the right side of the window. No black band if I omit --QOSGWidget How big is the black band? This suggests that the window sizes are wrong. I don't see the black band, with kubuntu 8.10, for qt version I get: pkg-config QtCore --modversion 4.4.3 What version of Qt are you using? Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] SVN (2.8) bugs in osgviewerQt
Hello Morné, Sorry, not enough info :) Pressing 'a' will add a view, 'r' will remove it. It works as expected until the last view is removed. Another way to see it is to construct the composite viewer without adding any views at compile time, and then trying to add one pressing 'a' at runtime. We're doing something similar to this (as you might have seen in previous discussions about CompositeViewer::addView() in the past month or so). There's one major difference though, we create a new GraphicsWindow for each view (because we want Qt to manage the split between windows, and we want each window to be undockable). For us it works well, and it should for you too. Just so you know, we're using Qt 4.4.x on Windows. I've tested your example, and I see the two issues you do: - The trackball manipulator does not throw (since Robert does not see this we can assume this is a Windows-specific problem, either caused by Qt on Windows or GraphicsWindowWin32's event handling) - When there are no views in the CompositeViewer (either because none were added at startup, or because all existing views were removed with 'r') then adding views doesn't have any visible effect (the window contains either what it contained when the last view was removed, or if you put another window over it then it doesn't repaint). I'm looking into this to see if I can find out what we're doing differently (other than a different graphics context for each view) that could fix your issues. I've tried some things (realizing the viewer, stopping/starting threading manually, etc.) but nothing has worked yet. I'll be checking this on my off time between other tasks though, so you might have to wait a day or two until I've had enough total time to work on it. I'll get back to you soon. J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] SVN (2.8) bugs in osgviewerQt
Hi again Morné,
- The trackball manipulator does not throw (since Robert does not see
this we can assume this is a Windows-specific problem, either caused by
Qt on Windows or GraphicsWindowWin32's event handling)
I've found out why this is. Since QOSGWidget uses GraphicsWindowWin32
directly, the graphics window already sends mouse events to the event
queue. So in QOSGWidget::mouse*Event (Press, DoubleClick, Release,
Move), you don't want to call _gw-getEventQueue()-mouseButton*()
because then it means that the same event is sent twice. This has the
effect that if two release events are received by the
TrackballManipulator, it stops the throw since the mouse speed when it
gets the second release is 0.
I would still send the events to QWidget though, just to be sure, so I
would replace those methods by:
void QOSGWidget::mousePressEvent( QMouseEvent* event )
{
QWidget::mousePressEvent(event);
}
(or just not override them) and so on for all other event methods. The
actual event will be put in the event queue in
GraphicsWindowWin32::handleNativeWindowingEvent().
In our project, we had run into the same problem, but we resolved it
differently. We subclassed GraphicsWindowWin32 to ignore all events, and
instead add them in the event queue in the overridden QOSGWidget
methods. I don't remember why we did it this way, but I think the above
is more general, in addition to not requiring a subclass.
I'm still looking for the cause/solution to the addView() problem.
J-S
--
__
Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com
http://www.cm-labs.com/
http://whitestar02.webhop.org/
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] SVN (2.8) bugs in osgviewerQt
Hi Morne, On Tue, Feb 3, 2009 at 10:50 AM, Morné Pistorius mpistorius@googlemail.com wrote: I first posted about these problems in the Test 2.8 thread. I still see two problems in the osgviewerQt example and managed to reproduce both in the attached modified file. I've just downloaded and tested your modified file. 1. Unable to spin/throw a model using QOSGWidget as a viewer. For me at least, the spinning and throwing works for both of the cessna models. What platform and Qt version are you working with? 2. viewer-addView doesn't work if the composite viewer is empty and trying to add a new view at runtime. How do I reproduce this problem? Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] SVN (2.8) bugs in osgviewerQt
Hi J-S,
Thank you so much for the help, much appreciated. I downloaded and
built Qt 4.4.3 today, thinking it might have been a Qt problem, since
I was using an older version than Robert.
I will replace the event methods with your suggestion.
W.r.t the composite viewer, I would really rather use it with multiple
views in single context. In our application, these tiled views could
be very many at once and I think context switching between all of them
would be bad for performance.
Again, I appreciate your help looking into this!
Thanks,
Morné
On Tue, Feb 3, 2009 at 4:21 PM, Jean-Sébastien Guay
jean-sebastien.g...@cm-labs.com wrote:
Hi again Morné,
- The trackball manipulator does not throw (since Robert does not see this
we can assume this is a Windows-specific problem, either caused by Qt on
Windows or GraphicsWindowWin32's event handling)
I've found out why this is. Since QOSGWidget uses GraphicsWindowWin32
directly, the graphics window already sends mouse events to the event queue.
So in QOSGWidget::mouse*Event (Press, DoubleClick, Release, Move), you don't
want to call _gw-getEventQueue()-mouseButton*() because then it means that
the same event is sent twice. This has the effect that if two release events
are received by the TrackballManipulator, it stops the throw since the mouse
speed when it gets the second release is 0.
I would still send the events to QWidget though, just to be sure, so I would
replace those methods by:
void QOSGWidget::mousePressEvent( QMouseEvent* event )
{
QWidget::mousePressEvent(event);
}
(or just not override them) and so on for all other event methods. The
actual event will be put in the event queue in
GraphicsWindowWin32::handleNativeWindowingEvent().
In our project, we had run into the same problem, but we resolved it
differently. We subclassed GraphicsWindowWin32 to ignore all events, and
instead add them in the event queue in the overridden QOSGWidget methods. I
don't remember why we did it this way, but I think the above is more
general, in addition to not requiring a subclass.
I'm still looking for the cause/solution to the addView() problem.
J-S
--
__
Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com
http://www.cm-labs.com/
http://whitestar02.webhop.org/
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] SVN (2.8) bugs in osgviewerQt
Hello Morné, W.r.t the composite viewer, I would really rather use it with multiple views in single context. In our application, these tiled views could be very many at once and I think context switching between all of them would be bad for performance. Oh, I was not suggesting you do it the same way as we do... We do it that way for specific reasons which you might not share. It's a case of doing it the right way for your own project - both ways should work. Still looking, but I'm running out of options... I'll get back to you. J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] SVN (2.8) bugs in osgviewerQt
The band width is proportional to the window width. It is approx. 1/5 of the client area. My Qt version: 4.3.1 Ciao! mario Robert Osfield wrote: Hi Mario, On Tue, Feb 3, 2009 at 12:45 PM, Mario Valle mva...@cscs.ch wrote: Five min. ago trunk works on Suse 10.3, but if I use --QOSGWidget a vertical black band appears on the right side of the window. No black band if I omit --QOSGWidget How big is the black band? This suggests that the window sizes are wrong. I don't see the black band, with kubuntu 8.10, for qt version I get: pkg-config QtCore --modversion 4.4.3 What version of Qt are you using? Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- Ing. Mario Valle Data Analysis Group | http://www.cscs.ch/~mvalle Swiss National Supercomputing Centre (CSCS) | Tel: +41 (91) 610.82.60 v. Cantonale Galleria 2, 6928 Manno, Switzerland | Fax: +41 (91) 610.82.82 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] SVN (2.8) bugs in osgviewerQt
Hi Robert, On Tue, Feb 3, 2009 at 11:21 AM, Robert Osfield robert.osfi...@gmail.com wrote: Hi Morne, On Tue, Feb 3, 2009 at 10:50 AM, Morné Pistorius mpistorius@googlemail.com wrote: I first posted about these problems in the Test 2.8 thread. I still see two problems in the osgviewerQt example and managed to reproduce both in the attached modified file. I've just downloaded and tested your modified file. 1. Unable to spin/throw a model using QOSGWidget as a viewer. For me at least, the spinning and throwing works for both of the cessna models. What platform and Qt version are you working with? I am on Windows Vista, using Qt 4.3.3. Do you think it is a Qt problem? When trying to debug it, I could rotate the model, but not throw it. TrackballManipulator::IsMouseMoving() always returned false on a mouse button RELEASE event. This only happens for the QOSGWidget though, I can throw it fine using the QGLWidget. 2. viewer-addView doesn't work if the composite viewer is empty and trying to add a new view at runtime. How do I reproduce this problem? Sorry, not enough info :) Pressing 'a' will add a view, 'r' will remove it. It works as expected until the last view is removed. Another way to see it is to construct the composite viewer without adding any views at compile time, and then trying to add one pressing 'a' at runtime. Cheers, Morne ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] SVN (2.8) bugs in osgviewerQt
Hi Morne, I've been able to reproduce the rendering issue with CompositeViewer with no View's using your modified example, and rather than dive into QT code that I'm not so familiar with I thought I'd recreate a similar usage of CompositeViewer in the osgcompositeviewer example. I've now start coding up additions but have come unstuck in trying to work out how to create an CompositeViewer which has its own window that it renders to without there being any Camera's assigned to the viewer, as without any views you don't have any cameras, and it's the camera's that hold the references to the graphics windows, so there is no way to actually specify the type of viewer setup your propose, without changing to quite a different model. In your QT example you have a window that is created for you, and an graphics context assigned to it, then you assign this to viewer, even if you didn't assign it to a viewer you would have a window. Also if your delete all the views you'd still have the window as the window is owned by Qt rather than by the viewer. This makes the set up quite different than a standard osgViewer based viewer that owns everything. The way to replicate the QT viewer setup would be to keep a reference to the GraphicsWindow in the application main loop, so that even when you remove all the views you still keep the window alive. Once all the views were removed the viewer itself wouldn't know about the GraphicsWindow so it wouldn't be able to do any. This would mean that the application main loop would need to step in an do it's own clear and swap buffers on the GraphicsWindow while the viewer was inactive without a view to render. I guess a similar viewer.frame() by pass could be done in the QT case for when the viewer has no views. The other approach might be to create an empty View that does nothing, has no scene, but at least has a Camera with the GraphicsWindow assigned to it. It's viewport could be zero sized so would be litte more than a non op, and you have have the GraphicsWindow do the clear each frame for you. This approach why a bit inelegant would probably prevent the problems you are seeing, and would just require an additionally couple of lines of set up code at the creation time, thereafter you'd just ignore this extra View. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] SVN (2.8) bugs in osgviewerQt
Hi Morné, The other approach might be to create an empty View that does nothing, has no scene, but at least has a Camera with the GraphicsWindow assigned to it. It's viewport could be zero sized so would be litte more than a non op, and you have have the GraphicsWindow do the clear each frame for you. This approach why a bit inelegant would probably prevent the problems you are seeing, and would just require an additionally couple of lines of set up code at the creation time, thereafter you'd just ignore this extra View. Yep, in my testing what Robert suggests would work since as long as you have at least one view there is no problem. It's removing that last view and then adding others that brings up the problem. Sorry I couldn't find anything more definitive on my end. J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
