[osg-users] mouse event handling
Hi All, I implemented a PointPicker derived from osgGA::GUIEventHandler and overloading: virtual bool handle(const osgGA::GUIEventAdapter ea,osgGA::GUIActionAdapter aa, osg::Object*, osg::NodeVisitor*); in which I handle both osgGA::GUIEventAdapter::PUSH and osgGA::GUIEventAdapter::RELEASE cases and always return false. In my Qt application I have a ViewerWidget that inherits from osgQt::GLWidget and osgViewer::CompositeViewer. All key events ara handled in ViewerWidget by overloading keyPressEvent(QKeyEvent*). Now, I thought to activate the PointPicker by pressing 'C' key. So for Qt::Key_C key I call: getView(0)-addEventHandler(pointPicker); Since the point picker must be deactivated after the first pick, then I thought to handle the mouse release event on the ViewerWidget side also, overloading the method mouseReleaseEvent: ViewerWidget::mouseReleaseEvent(QMouseEvent* event) where I call: superclass::mouseReleaseEvent(event); getView(0)-removeEventHandler(pointPicker); The problem is that when removeEventHandler is called the event has not been already processed by PointPiker::handle(...). So osgGA::GUIEventAdapter::RELEASE case never happens. I tryed to call eventTraversal() as follows: superclass::mouseReleaseEvent(event); eventTraversal(); getView(0)-removeEventHandler(pointPicker); but unfortunately it does not solve the problem. I found a workaround but I will appreciate if someone could explain how to solve this case. Regards, Gianni -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=61405#61405 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] mouse event handling
Hi Gianni, Rather than adding/removing the event handler I would add a flag to the event handle to say whether it's active or not and then enable/disable as required. Robert. On 24 October 2014 08:57, Gianni Ambrosio g.ambrosio+...@gmail.com wrote: Hi All, I implemented a PointPicker derived from osgGA::GUIEventHandler and overloading: virtual bool handle(const osgGA::GUIEventAdapter ea,osgGA::GUIActionAdapter aa, osg::Object*, osg::NodeVisitor*); in which I handle both osgGA::GUIEventAdapter::PUSH and osgGA::GUIEventAdapter::RELEASE cases and always return false. In my Qt application I have a ViewerWidget that inherits from osgQt::GLWidget and osgViewer::CompositeViewer. All key events ara handled in ViewerWidget by overloading keyPressEvent(QKeyEvent*). Now, I thought to activate the PointPicker by pressing 'C' key. So for Qt::Key_C key I call: getView(0)-addEventHandler(pointPicker); Since the point picker must be deactivated after the first pick, then I thought to handle the mouse release event on the ViewerWidget side also, overloading the method mouseReleaseEvent: ViewerWidget::mouseReleaseEvent(QMouseEvent* event) where I call: superclass::mouseReleaseEvent(event); getView(0)-removeEventHandler(pointPicker); The problem is that when removeEventHandler is called the event has not been already processed by PointPiker::handle(...). So osgGA::GUIEventAdapter::RELEASE case never happens. I tryed to call eventTraversal() as follows: superclass::mouseReleaseEvent(event); eventTraversal(); getView(0)-removeEventHandler(pointPicker); but unfortunately it does not solve the problem. I found a workaround but I will appreciate if someone could explain how to solve this case. Regards, Gianni -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=61405#61405 ___ 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] mouse event handling
Hi Robert, thanks for the fast reply. That's exactly the workaroud I found. Just out of curiosity, is there any way to force the event handling on the OSG part in Qt event handling method? Best regards, Gianni robertosfield wrote: Hi Gianni, Rather than adding/removing the event handler I would add a flag to the event handle to say whether it's active or not and then enable/disable as required. -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=61407#61407 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] mouse event handling
On 24 October 2014 09:09, Gianni Ambrosio g.ambrosio+...@gmail.com wrote: Hi Robert, thanks for the fast reply. That's exactly the workaroud I found. Just out of curiosity, is there any way to force the event handling on the OSG part in Qt event handling method? I not a Qt coder so can't comment on the Qt side. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] How do I adapt the osgViewer::Viewer in order to have my model in fullscreen mode?
Hi, With your last post I remembered that the openGL textures must have 2x1 or 1x1 dimensions. So, I already fix it and now I don’t have the warning that my texture is being scaled. Nevertheless, the render remains the same. The image is rendered partially in the bottom-left side. Could be the projection that is wrong?! As I mention, I setProjectionMatrixAsOrtho2D(0.0, traits-width, 0.0, traits-height) on the camera object. Must I have an transformation matrix for the viewer? Thanks in advance for any kind of help! Best Regards, Filipe -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=61409#61409 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] How do I adapt the osgViewer::Viewer in order to have my model in fullscreen mode?
HI Filipe, On 24 October 2014 09:46, Filipe P filipe.edu.pimen...@gmail.com wrote: With your last post I remembered that the openGL textures must have 2x1 or 1x1 dimensions. So, I already fix it and now I don't have the warning that my texture is being scaled. OpenGL and graphics hardware has supported non power of two texture for many years, the OSG fully supports via the Texture setting I mentioned. As long as you don't need compatibility with old hardware it's fine to use non power of two texture. Nevertheless, the render remains the same. The image is rendered partially in the bottom-left side. Could be the projection that is wrong?! As I mention, I setProjectionMatrixAsOrtho2D(0.0, traits-width, 0.0, traits-height) on the camera object. Must I have an transformation matrix for the viewer? Thanks in advance for any kind of help! Frankly, it's rather hard to follow the twists on turns of your problems, there really are too many unknowns for us to guess what you do and no not understand, or what you may or may not have done correctly or incorrectly. I suggest that you need to learn more of the basics of OpenGL and computer graphics. There are plenty of resources only, and the OSG we have several books. You can't expect members of the OSG community to teach how to program, you'll need to pitch in and learn stuff from the resources available. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] mouse event handling
robertosfield wrote: I not a Qt coder so can't comment on the Qt side. Honestrly I'm not sure this is just a matter of Qt code. I can get the mouse event on the Qt side and let OSG code handlling it later. I debugged that code and the mouse event seems correctly added to the osg event queue but calling eventTraversal() the event is not processed. I guess the event is processed in a frame() call, but removing the event handler too early (in mouseReleaseEvent()) it causes the behaviour I experienced. That's why I asked if there is a way to force event processing in pure OSG code. Best regards, Gianni -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=61411#61411 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] mouse event handling
Hi Gianni, On 24 October 2014 10:48, Gianni Ambrosio g.ambrosio+...@gmail.com wrote: Honestrly I'm not sure this is just a matter of Qt code. I can get the mouse event on the Qt side and let OSG code handlling it later. I debugged that code and the mouse event seems correctly added to the osg event queue but calling eventTraversal() the event is not processed. I guess the event is processed in a frame() call, but removing the event handler too early (in mouseReleaseEvent()) it causes the behaviour I experienced. That's why I asked if there is a way to force event processing in pure OSG code. There really is too little to go on for a 3rd party to know what might be going on, what is correct and what might not be. You have all the code in front of you, I and others don't, there are really limits to our ability to onimpotent. As for forcing event processing in pure OSG code. Well you can create an event and pass it directly to the event handling/callback. Robert ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Quad Buffer Stereo in osgViewer::CompositeViewer
Hi, Just a note to say this is now completely resolved. It was my fault, the stereo failed in my application because I was setting up the display settings of the 3D view after adding it to the composite viewer. Anyone who is trying to get something similar to work please beware: The order of operations in setting up composite views matters A LOT. The issues with enabling the active stereo on my Stereo Monitor were resolved by setting the Select when the display is in 3D mode: option to Always in the Nvidia control panel. Thanks again for the help! ... Cheers, Guy -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=61413#61413 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] GeometryTechnique race condition crash
Hi Robert, We too have some trouble with the database pager. It all started after we used DatabasePager::setUpThreads to use more threads. We get memory corruption but only on linux. Tried to use valgrind but then the problem does not occur. We are still in the process of pinpointing it down, some theories I have and it might help you so here are my two cents: - we have some osgb files that reference the same images. We also have some files that use proxy nodes to reference other files because we have some objects that can be build out of subobjects. - What could happen is that the database pager tries to load this referenced image or object and find it in the registry cache. Then it could occur that more database pager threads run the incremental compilation over the same objects. Cheers, Pjotr -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=61414#61414 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] GeometryTechnique race condition crash
Hi Pjotr, On 24 October 2014 14:54, Pjotr Svetachov pjotrsvetac...@gmail.com wrote: We too have some trouble with the database pager. It all started after we used DatabasePager::setUpThreads to use more threads. We get memory corruption but only on linux. Tried to use valgrind but then the problem does not occur. Curiously I have found the a similar behaviour, I get crashes but when I run in valgrind I don't get any and the only issues picked up are ones that occur during cleanup and look to benign. The crashes I get look likely to be memory corruption. This happens from my new shader based terrain technique, I suspect even though the code is different there are similarities in that they create subgraphs that contain geometry and state that need compiling, culling and rendering. We are still in the process of pinpointing it down, some theories I have and it might help you so here are my two cents: - we have some osgb files that reference the same images. We also have some files that use proxy nodes to reference other files because we have some objects that can be build out of subobjects. There are some specific .osgb threading issues related to initialization of the wrappers. There is chance that you are hitting up against this. For my own work I'm not currently testing against .osgb and get problems so I believe the .osgb issues can be dealt with separately. - What could happen is that the database pager tries to load this referenced image or object and find it in the registry cache. Then it could occur that more database pager threads run the incremental compilation over the same objects. The IncrementalCompileOperator only compiles objects from the GraphicsThreads assoicated with teh GraphicsContext and this ensures that for a single context all the GL objects are compiled in series, and duplicates if they exist will be checked to see if they compiling and they've already compiled will be skipped. Given this I don't think there is any danger of multiple entries. Today I added a mutex around the access to the subgraph managed by the custom TerrainTechnique I have, this looks to be fixed the crashes, but as I yet I can't spot the time that the subgraph is contended. The GeometryTechnique has a similar local subgraph so may also be hitting up to the same issue. The odd thing is that the design of the DatabasePager should be avoided this contention issue, something I haven't yet got to the bottom of. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] GeometryTechnique race condition crash
robertosfield wrote: There are some specific .osgb threading issues related to initialization of the wrappers. There is chance that you are hitting up against this. For my own work I'm not currently testing against .osgb and get problems so I believe the .osgb issues can be dealt with separately. We already had this issue and we make sure that we are pre loading all the plugins and serializers we need at program start to avoid this issue. robertosfield wrote: Hi Pjotr, - What could happen is that the database pager tries to load this referenced image or object and find it in the registry cache. Then it could occur that more database pager threads run the incremental compilation over the same objects. The IncrementalCompileOperator only compiles objects from the GraphicsThreads assoicated with teh GraphicsContext and this ensures that for a single context all the GL objects are compiled in series, and duplicates if they exist will be checked to see if they compiling and they've already compiled will be skipped. Given this I don't think there is any danger of multiple entries. What about FindCompileableGLObjectsVisitor, it is run on the pager thread. Is that visitor thread safe? Just had a quick look at it and there are too many different paths in osg code I'm not familiar with to make an assessment for me about thread safety. For example it can call Geometry::setUseVertexBufferObjects depending on the database pager flags, is that method thread safe. Cheers, Pjotr -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=61416#61416 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] order of PreRender camera with respect to the main camera
Hi Community, I am facing the same problem for long time and always have to hack it. I have prerender camera that has to follow the main camera. My pre-render camera is always a frame behind the main camera which is updated by a CameraManipulator. The update of the Pre-Render camera is done with UpdateCallback that simply copy the ViewMatrix of the main camera, but it seam that the main camera is updated afterwards. What is the order of these updates? I was expecting the main camera is updated from the CameraMainpulator and then everything else (including the Pre-Render cameras), but seam it is not the case? Any hints on this? Thanks a bunch as always! Nick -- trajce nikolov nick ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] GeometryTechnique race condition crash
Hi Pjotr, On 24 October 2014 16:02, Pjotr Svetachov pjotrsvetac...@gmail.com wrote: What about FindCompileableGLObjectsVisitor, it is run on the pager thread. Is that visitor thread safe? Just had a quick look at it and there are too many different paths in osg code I'm not familiar with to make an assessment for me about thread safety. For example it can call Geometry::setUseVertexBufferObjects depending on the database pager flags, is that method thread safe. Initially I was about to say that FindCompileableGLObjectsVisitor just collects data so should be thread safe, but your point about setUseVertexBufferObjects() etc. is an something that is potentially unsafe. The visitor currently assumes that it's working on the subgraph single threaded and has complete control over it, but in cases where the subgraph is shared and that shared subgraph is being traversed by other threads we have potential for threading conflicts. I don't know yet whether than it an issue here, but could be so will look at this possibility. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] order of PreRender camera with respect to the main camera
Hi Nick, The update of the CameraManipulator happens at the end of VIewer::updateTraversal(). The default Viewer::frame() implementation() runs the event and then update traversal. Your own application can override any of the viewer.frame() or updateTraversal/eventTraversal() methods so if you want to take control and do things in a different from standard you can do. Robert. On 24 October 2014 16:13, Trajce Nikolov NICK trajce.nikolov.n...@gmail.com wrote: Hi Community, I am facing the same problem for long time and always have to hack it. I have prerender camera that has to follow the main camera. My pre-render camera is always a frame behind the main camera which is updated by a CameraManipulator. The update of the Pre-Render camera is done with UpdateCallback that simply copy the ViewMatrix of the main camera, but it seam that the main camera is updated afterwards. What is the order of these updates? I was expecting the main camera is updated from the CameraMainpulator and then everything else (including the Pre-Render cameras), but seam it is not the case? Any hints on this? Thanks a bunch as always! Nick -- trajce nikolov nick ___ 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] order of PreRender camera with respect to the main camera
thanks Robert Nick On Fri, Oct 24, 2014 at 5:19 PM, Robert Osfield robert.osfi...@gmail.com wrote: Hi Nick, The update of the CameraManipulator happens at the end of VIewer::updateTraversal(). The default Viewer::frame() implementation() runs the event and then update traversal. Your own application can override any of the viewer.frame() or updateTraversal/eventTraversal() methods so if you want to take control and do things in a different from standard you can do. Robert. On 24 October 2014 16:13, Trajce Nikolov NICK trajce.nikolov.n...@gmail.com wrote: Hi Community, I am facing the same problem for long time and always have to hack it. I have prerender camera that has to follow the main camera. My pre-render camera is always a frame behind the main camera which is updated by a CameraManipulator. The update of the Pre-Render camera is done with UpdateCallback that simply copy the ViewMatrix of the main camera, but it seam that the main camera is updated afterwards. What is the order of these updates? I was expecting the main camera is updated from the CameraMainpulator and then everything else (including the Pre-Render cameras), but seam it is not the case? Any hints on this? Thanks a bunch as always! Nick -- trajce nikolov nick ___ 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 -- trajce nikolov nick ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] GeometryTechnique race condition crash
On Fri, Oct 24, 2014 at 03:35:06PM +0100, Robert Osfield wrote: Hi Pjotr, On 24 October 2014 14:54, Pjotr Svetachov pjotrsvetac...@gmail.com wrote: We too have some trouble with the database pager. It all started after we used DatabasePager::setUpThreads to use more threads. We get memory corruption but only on linux. Tried to use valgrind but then the problem does not occur. Curiously I have found the a similar behaviour, I get crashes but when I run in valgrind I don't get any and the only issues picked up are ones that occur during cleanup and look to benign. Running valgrind with memcheck is deficient when it comes to debugging multithreaded race conditions this is because while it supports running multithreaded programs and valgrind runs each application thread in a real thread, the valgrind data structures can't support multiple threads and so only one thread is allowed to run at a time. So any program that runs under valgrind has little concurrency as it turns into one thread running for a while followed by another, so these kinds of race conditions don't show up. valgrind --tool=helgrind The helgrind tool is designed to find potential problems accessing data without a lock. It sill will only run one thread at a time, but it is designed to look for these kinds of problems. This was very useful for me to track down what I posted. From my earlier post adding a sleep, in StateToCompile::apply causes the one thread to wait and allows the other thread to get in and mess things up, then it will crash very frequently and valgrind memcheck will see the access after delete. OpenThreads::Thread::microSleep(10); The crashes I get look likely to be memory corruption. This happens from my new shader based terrain technique, I suspect even though the code is different there are similarities in that they create subgraphs that contain geometry and state that need compiling, culling and rendering. We are still in the process of pinpointing it down, some theories I have and it might help you so here are my two cents: - we have some osgb files that reference the same images. We also have some files that use proxy nodes to reference other files because we have some objects that can be build out of subobjects. There are some specific .osgb threading issues related to initialization of the wrappers. There is chance that you are hitting up against this. For my own work I'm not currently testing against .osgb and get problems so I believe the .osgb issues can be dealt with separately. - What could happen is that the database pager tries to load this referenced image or object and find it in the registry cache. Then it could occur that more database pager threads run the incremental compilation over the same objects. The IncrementalCompileOperator only compiles objects from the GraphicsThreads assoicated with teh GraphicsContext and this ensures that for a single context all the GL objects are compiled in series, and duplicates if they exist will be checked to see if they compiling and they've already compiled will be skipped. Given this I don't think there is any danger of multiple entries. Today I added a mutex around the access to the subgraph managed by the custom TerrainTechnique I have, this looks to be fixed the crashes, but as I yet I can't spot the time that the subgraph is contended. The GeometryTechnique has a similar local subgraph so may also be hitting up to the same issue. The odd thing is that the design of the DatabasePager should be avoided this contention issue, something I haven't yet got to the bottom of. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- David Fries da...@fries.netPGP pub CB1EE8F0 http://fries.net/~david/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
