[osg-users] Gstreamer within OSG
Hello all, I am planning to write some code to allow blitting of gstreamer buffers into osg textures. Eg for playing a video file or a network stream on to OSG primitives. I did a preliminary search and did not see anyone having gone down this path before. I thought I would post a message in case anyone has been down this path and knows any pertinent information. Thanks ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] General render debugging question
* previous=0x) Line 480
C++
osg73-osgUtilrd.dll!osgUtil::RenderStage::drawImplementation(osg::RenderInfo
renderInfo={...}, osgUtil::RenderLeaf * previous=0x) Line 1367
C++
osg73-osgUtilrd.dll!osgUtil::RenderStage::drawInner(osg::RenderInfo
renderInfo={...}, osgUtil::RenderLeaf * previous=0x, bool
doCopyTexture=false) Line 936C++
osg73-osgUtilrd.dll!osgUtil::RenderStage::draw(osg::RenderInfo
renderInfo={...}, osgUtil::RenderLeaf * previous=0x) Line 1208
C++
osg73-osgUtilrd.dll!osgUtil::SceneView::draw() Line 1443 +
0x15 bytes C++
osg73-osgrd.dll!osg::Stats::collectStats(const
std::basic_stringchar,std::char_traitschar,std::allocatorchar
str={...}) Line 80 + 0x4a bytes C++
osg73-osgViewerrd.dll!osgViewer::Renderer::cull_draw() Line
849 C++
osg73-osgrd.dll!osg::GraphicsContext::runOperations() Line
751 C++
osg73-osgViewerrd.dll!osgViewer::ViewerBase::renderingTraversals() Line 809
+ 0x17 bytes C++
osg73-osgViewerrd.dll!osgViewer::ViewerBase::frame(double
simulationTime=2.2281973105867356e-303) Line 643 C++
osg73-osgViewerrd.dll!osgViewer::ViewerBase::frame(double
simulationTime=6.5245075982572160e-306) Line 645 + 0x9 bytes C++
KERNELBASE.dll!_OutputDebugStringA@4() + 0x60 bytes
-Original Message-
From: osg-users-boun...@lists.openscenegraph.org
[mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Robert
Osfield
Sent: Monday, June 06, 2011 11:51 PM
To: OpenSceneGraph Users
Subject: Re: [osg-users] General render debugging question
Hi Brad,
On Mon, Jun 6, 2011 at 11:27 PM, Brad Huber mailto:br...@procerus.com
br...@procerus.com wrote:
I'm currently trying to track down a render-time application crash.
What I'm wondering is how to trace from a crash in the rendergraph to
the associated node(s) in the scene graph. Is there any straight forward
way?
The crash could be for any reason, it may or may not be related to the scene
graph at all.
Personally I use a debugger and get a strack trace to get an idea of where
the crash is and then from this investigate. There is no automagic way of
knowing exactly what is causing a crash, nor is there a way of automatically
knowing what you are doing with the scene graph that may or may not be
causing a crash.
If a straight debugger doesn't give you enough clues then you could look at
using a memory/thread analsyis tool like valgrind, or an OpenGL debug tool
like gDEBugger.
Also just observing the app when it crashes and looking to see if there is
any correleations that might give you a clue. All it's just dtective work.
Robert.
___
osg-users mailing list
mailto:osg-users@lists.openscenegraph.org
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
image001.png___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] General render debugging question
Hello everyone, Simple general question. I searched the archives but didn't stumble on anything. I'm currently trying to track down a render-time application crash. What I'm wondering is how to trace from a crash in the rendergraph to the associated node(s) in the scene graph. Is there any straight forward way? Thanks for any insight ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] CompositeViewer issues
A while back I sent an email regarding a bug in CompositeViewer. Please see the text below. I've also reattached the code for convenience. The bug still exists in the trunk code and I am currently trying to resolve it. I am trying to get a little better understanding before I submit any possible changes. Basically my question is when the frame of the window/graphics context is selected (but the mouse has not yet been over any views within the window), what view do you send/address events to? I think the main thing that I am wondering is since a context can contain multiple views, is there a master view per context? Thanks -Brad -Original Message- From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Brad Huber Sent: Monday, September 27, 2010 9:07 AM To: 'OpenSceneGraph Users' Subject: Re: [osg-users] CompositeViewer issues Has anyone had a chance to try the sample program I posted to see if the bug is the same in Linux? Thanks -Brad -Original Message- From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Brad Huber Sent: Thursday, September 23, 2010 1:22 PM To: 'OpenSceneGraph Users' Subject: Re: [osg-users] CompositeViewer issues Robert, Attached is a simple stripped down app that demonstrates the problem. The program creates two windows (2 views total). The 1st has a HUD and the 2nd doesn't. Resizing the 2nd window causes the HUD in the first window to resize (it shouldn't). I am reliably producing this bug on my Win7 machine. I'm quite confident that this bug will be reproducible on all Windows. I am a little bit less sure of Linux/Mac, etc. I've included a Visual Studio 2005 project but since there is only one source file it should be easy to get it building under Linux. Thanks -Brad -Original Message- From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Robert Osfield Sent: Wednesday, September 22, 2010 2:25 AM To: OpenSceneGraph Users Subject: Re: [osg-users] CompositeViewer issues Hi Brad, Could you see if you can reproduce this problem with the one of the OSG examples, or a small tweak of one to reproduce this problem. If I can reproduce it reliably then there is a much better chance of spotting the culprit and finding a solution. Cheers, Robert. On Tue, Sep 21, 2010 at 10:27 PM, Brad Huber br...@procerusuav.com wrote: Hello, I recently converted our osg based application over to use Composite Viewer because we need multiple Views on the same scene graph. Im running in to a little snag which appears to be a bug in CompositeViewer. Simple way of explaining the manifestation of the issue is that I have two Windows and two Views (one view per window) and they both have event handlers attached to the views which react to the osgGA::GUIEventAdapter::RESIZE event. Resizing works hunky dory for view 0 but it does not work correctly for view 1. I believe the culprit is related to these lines of code found in CompositeViewer::eventTraversal(). osgViewer::View* masterView = getViewWithFocus() ? getViewWithFocus() : _views[0].get(); . . . viewEventsMap[masterView].insert( viewEventsMap[masterView].end(), gw_events.begin(), gw_events.end() ); The problem is that when resizing, apparently getViewWithFocus() returns NULL (I guess because the mouse is over the window frame and not the view within the window. Therefore a resize event is taken out of the graphics window queue for the 2nd window and stuck into the event queue for the 0 view (a mismatch). The effect for me is that the when I resize one window the HUD I have set up in the other window receives the resize event and changes which obviously isnt what I want J. This does seem to be somewhat intermittent and may be related to whether your mouse tends to fall off the window frame towards the view or away from the view PS I dont have a solution in hand yet. I thought I would throw this out there in case its a known issue or something. Thanks -Brad ___ 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 mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org CompositeViewer_Playground.zi_ Description: Binary data ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Supporting multiple frame rates
Hello, We currently have an OSG based application which renders at 30-60+ fps on our development hardware with discrete gpus. Unfortunately we have to be able to deploy on a wide range of hardware including stuff that is significantly less capable (Intel GPUs, etc). On some of these slower platforms we are seeing framerates that are 10-15 fps. This is actually ok for us with one exception, live video. We show live video in the scene graph (for now strictly in the HUD). We have a requirement to make the video render at native speed (~30 fps). I am looking for a way to make the HUD/video render at 30 fps and let the rest of the scene graph render at a floating rate (whatever the machine can handle). How might this be accomplished? Since this is a HUD, obviously it must ultimately render to the same graphics context, however it doesn't really need to respect the depth buffer, etc of the rest of the scene (it should always render on top). PS Should I be thinking about render to texture? Related threads I came across: http://forum.openscenegraph.org/viewtopic.php?t=7858 http://lists.openscenegraph.org/pipermail/osg-users-openscenegraph.org/2008- January/006000.html http://forum.openscenegraph.org/viewtopic.php?t=7117 Thanks -Brad ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Supporting multiple frame rates
Robert, Farshid, Thanks for the ideas. Given what you've said, would it make more sense to pursue using two contexts? Perhaps the main scene would render to an invisible off screen context and then the visible context would copy the frame buffer from the invisible context and render the video frames on top of that. I imagine there would be some difficulty in having additional threading complexity to deal with. -Brad -Original Message- From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Robert Osfield Sent: Thursday, April 28, 2011 9:59 AM To: OpenSceneGraph Users Subject: Re: [osg-users] Supporting multiple frame rates Hi Brad, I'm afraid decoupling the rendering of two parts of graphics window so that they can run at their own frame rate won't be a straight forward task, and well off the standard viewer path used by the vast majority of the community. You are infact the first I recall wanting to do exactly this combination of video at 30fps and man scene at it's own frame rate. Thoughts off the top of my head: You only need to do something special when 3D scene takes longer than 30ms and would cause frame rate to drop below the min 30fps, so the follow suggestions are for when frame rate would drop below 30. Could you render the video to the front buffer and just overlay the background 3D scene? This would enable you to remove the need for a swap buffers call at the end of the render of teh video texture. Another approach would be to render the 3D scene into a texture and then compose each frame from the 3D scene texture and the video texture and do the swap buffers at video texture frame rate. In both cases you the 3D scene is taking too long to render, and since you are using a single graphics context there isn't a natural way to split up and decouple the rendering completely, so to be able to put out frames at 30fps you'll need to break the render of the 3D scene into segments each of which can fit into with the time available when rendering at 30fps. Splitting the scene won't be trivial, the easist method would be something like depth partitioning, and render different partition in depth and balance the depth range for each so that the load is as well balanced as you can get it. That's my best suggestions so far... Far from trivial to set up, very much on the bleeding edge! Robert. On Thu, Apr 28, 2011 at 4:39 PM, Brad Huber br...@procerus.com wrote: Hello, We currently have an OSG based application which renders at 30-60+ fps on our development hardware with discrete gpus. Unfortunately we have to be able to deploy on a wide range of hardware including stuff that is significantly less capable (Intel GPUs, etc). On some of these slower platforms we are seeing framerates that are 10-15 fps. This is actually ok for us with one exception, live video. We show live video in the scene graph (for now strictly in the HUD). We have a requirement to make the video render at native speed (~30 fps). I am looking for a way to make the HUD/video render at 30 fps and let the rest of the scene graph render at a floating rate (whatever the machine can handle). How might this be accomplished? Since this is a HUD, obviously it must ultimately render to the same graphics context, however it doesnt really need to respect the depth buffer, etc of the rest of the scene (it should always render on top). PS Should I be thinking about render to texture? Related threads I came across: http://forum.openscenegraph.org/viewtopic.php?t=7858 http://lists.openscenegraph.org/pipermail/osg-users-openscenegraph.org /2008-January/006000.html http://forum.openscenegraph.org/viewtopic.php?t=7117 Thanks -Brad ___ 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 mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Supporting multiple frame rates
Ok Thanks. This gives an idea of how to pursue a couple of different options. I'll post back with any results. Thanks -Brad -Original Message- From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Robert Osfield Sent: Thursday, April 28, 2011 12:27 PM To: OpenSceneGraph Users Subject: Re: [osg-users] Supporting multiple frame rates Hi Brad, I also thought about the two context route but didn't suggest it as I'm doubtful that the graphics driver/card will be able to interleave the rendering on the two threads in way that doesn't have one thread stalling the other as they contend for resources on the graphics card. Using a pbuffer to render the 3d scene and the main graphics window doing the compositing would be the easier option to implement though, so I'd suggest trying it out, you'd need to use two viewers to decouple the frames, at least then you'd know whether it's good enough a solution or not. Robert. On Thu, Apr 28, 2011 at 5:52 PM, Brad Huber br...@procerus.com wrote: Robert, Farshid, Thanks for the ideas. Given what you've said, would it make more sense to pursue using two contexts? Perhaps the main scene would render to an invisible off screen context and then the visible context would copy the frame buffer from the invisible context and render the video frames on top of that. I imagine there would be some difficulty in having additional threading complexity to deal with. -Brad -Original Message- From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Robert Osfield Sent: Thursday, April 28, 2011 9:59 AM To: OpenSceneGraph Users Subject: Re: [osg-users] Supporting multiple frame rates Hi Brad, I'm afraid decoupling the rendering of two parts of graphics window so that they can run at their own frame rate won't be a straight forward task, and well off the standard viewer path used by the vast majority of the community. You are infact the first I recall wanting to do exactly this combination of video at 30fps and man scene at it's own frame rate. Thoughts off the top of my head: You only need to do something special when 3D scene takes longer than 30ms and would cause frame rate to drop below the min 30fps, so the follow suggestions are for when frame rate would drop below 30. Could you render the video to the front buffer and just overlay the background 3D scene? This would enable you to remove the need for a swap buffers call at the end of the render of teh video texture. Another approach would be to render the 3D scene into a texture and then compose each frame from the 3D scene texture and the video texture and do the swap buffers at video texture frame rate. In both cases you the 3D scene is taking too long to render, and since you are using a single graphics context there isn't a natural way to split up and decouple the rendering completely, so to be able to put out frames at 30fps you'll need to break the render of the 3D scene into segments each of which can fit into with the time available when rendering at 30fps. Splitting the scene won't be trivial, the easist method would be something like depth partitioning, and render different partition in depth and balance the depth range for each so that the load is as well balanced as you can get it. That's my best suggestions so far... Far from trivial to set up, very much on the bleeding edge! Robert. On Thu, Apr 28, 2011 at 4:39 PM, Brad Huber br...@procerus.com wrote: Hello, We currently have an OSG based application which renders at 30-60+ fps on our development hardware with discrete gpus. Unfortunately we have to be able to deploy on a wide range of hardware including stuff that is significantly less capable (Intel GPUs, etc). On some of these slower platforms we are seeing framerates that are 10-15 fps. This is actually ok for us with one exception, live video. We show live video in the scene graph (for now strictly in the HUD). We have a requirement to make the video render at native speed (~30 fps). I am looking for a way to make the HUD/video render at 30 fps and let the rest of the scene graph render at a floating rate (whatever the machine can handle). How might this be accomplished? Since this is a HUD, obviously it must ultimately render to the same graphics context, however it doesnt really need to respect the depth buffer, etc of the rest of the scene (it should always render on top). PS Should I be thinking about render to texture? Related threads I came across: http://forum.openscenegraph.org/viewtopic.php?t=7858 http://lists.openscenegraph.org/pipermail/osg-users-openscenegraph.or g /2008-January/006000.html http://forum.openscenegraph.org/viewtopic.php?t=7117 Thanks -Brad
Re: [osg-users] osgTerrain -- ON_DEMAND rendering broken?
Exactly. Thanks Jason. In my working copy I've removed the setNumChildrenRequiringUpdateTraversal call and ON_DEMAND rendering in osgViewer works again. I would not propose this as a fix because it probably broke something else and so that's why I'd like to see why this change was included and investigate if there is another feasible solution that allows ON_DEMAND functionality to continue to work like it did before rev 11307. Thanks -Brad -Original Message- From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Jason Beverage Sent: Wednesday, October 20, 2010 7:50 AM To: OpenSceneGraph Users Subject: Re: [osg-users] osgTerrain -- ON_DEMAND rendering broken? Hi Robert, Brad is talking about OSG's ON_DEMAND mode to (osgviewer --run-on-demand). The setting of the setNumChildrenRequiringUpdateTraversal to get an update traversal in osgTerrain (as well in osgEarth) causes the frameloop to run continuously instead of only when something changes. So even if you're sitting still and nothing needs paged in and no tiles need processed in the osgTerrain::Terrain's update callback the frameloop still runs as fast as it can. Jason On Wed, Oct 20, 2010 at 4:34 AM, Robert Osfield robert.osfi...@gmail.com wrote: HI Brad, What do you mean by ON_DEMAND rendering in osgTerrain? Is this an osgEarth feature, rather than an osgTerrain one? Robert. On Wed, Oct 20, 2010 at 12:01 AM, Brad Huber br...@procerusuav.com wrote: It appears that ON_DEMAND rendering is broken in osgTerrain as of rev 11307. The offend lines appear to be the manual setting of numchildrenrequiringupdatetraversal in the constructors for osgTerrain::Terrain. We are using osgEarth (using osgTerrain) and would really like to use ON_DEMAND to greatly reduce our cpu/gpu footprint. Obviously this change was introduced to fix something (boundary equalization?). Is there another option? Thanks -Brad ___ 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 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] osgTerrain -- ON_DEMAND rendering broken?
Robert, Ok thanks for the confirmation. Is there an alternative that can allow ON_DEMAND to continue working? Thanks -Brad -Original Message- From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Robert Osfield Sent: Wednesday, October 20, 2010 12:37 PM To: OpenSceneGraph Users Subject: Re: [osg-users] osgTerrain -- ON_DEMAND rendering broken? Hi Brad, On Wed, Oct 20, 2010 at 6:02 PM, Brad Huber In my working copy I've removed the setNumChildrenRequiringUpdateTraversal call and ON_DEMAND rendering in osgViewer works again. I would not propose this as a fix because it probably broke something else and so that's why I'd like to see why this change was included and investigate if there is another feasible solution that allows ON_DEMAND functionality to continue to work like it did before rev 11307. I believe I made this change to support the new boundary equalization feature in osgTerrain. Robert. ___ 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] osgTerrain -- ON_DEMAND rendering broken?
It appears that ON_DEMAND rendering is broken in osgTerrain as of rev 11307. The offend lines appear to be the manual setting of numchildrenrequiringupdatetraversal in the constructors for osgTerrain::Terrain. We are using osgEarth (using osgTerrain) and would really like to use ON_DEMAND to greatly reduce our cpu/gpu footprint. Obviously this change was introduced to fix something (boundary equalization?). Is there another option? Thanks -Brad ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] How Camera Manipulators Work
Matt, You might take a look at the osgEarth project. The osgEarthUtil::EarthManipulator (a CameraManipulator) that they are using allows remapping of inputs to actions. For example you can program what keys do and what mouse buttons and scrollwheels do. I'm not sure that it achieves a full decoupling that you're driving at, but might be worth a look. -Brad -Original Message- From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Matt Caron Sent: Tuesday, October 19, 2010 9:58 AM To: osg-users@lists.openscenegraph.org Subject: Re: [osg-users] How Camera Manipulators Work Chuck, I think I'm gonna come back to this thread in a little while with a proposed project to realize the mapping that has been discussed over the past few entries. Maybe you can take a look at the proposal and give some feedback? I agree that most users probably find the current manipulators usable with some tweaking, but for such an object oriented and modularized system, I hate to think that the typical user is out there adjusting source code for the manipulator and then calling it something else. I think this part of the system is just far too tangled in its logic and should be opened up for extensibility purposes. For those who find the current manipulators to be useful, theres no reason we can't provide a factory to hand out all the versions of manipulators that people are used to - mapped to the IO that people are used toso I think we can keep it equally simple for users who don't want extensibility, but at the same time we can make new manipulators far easier for those of us with unusual IO devices, or unusual manipulator logic. At the moment I'd say my two primary goals for this camera re-write are: 1) Separation of IO from Camera Manipulators 2) Pluggable IO system with regard to Camera Manipulators 3) Factory(s) to build the manipulators everyone is used to Thanks. Matt -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=32867#32867 ___ 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] CompositeViewer issues
Has anyone had a chance to try the sample program I posted to see if the bug is the same in Linux? Thanks -Brad -Original Message- From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Brad Huber Sent: Thursday, September 23, 2010 1:22 PM To: 'OpenSceneGraph Users' Subject: Re: [osg-users] CompositeViewer issues Robert, Attached is a simple stripped down app that demonstrates the problem. The program creates two windows (2 views total). The 1st has a HUD and the 2nd doesn't. Resizing the 2nd window causes the HUD in the first window to resize (it shouldn't). I am reliably producing this bug on my Win7 machine. I'm quite confident that this bug will be reproducible on all Windows. I am a little bit less sure of Linux/Mac, etc. I've included a Visual Studio 2005 project but since there is only one source file it should be easy to get it building under Linux. Thanks -Brad -Original Message- From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Robert Osfield Sent: Wednesday, September 22, 2010 2:25 AM To: OpenSceneGraph Users Subject: Re: [osg-users] CompositeViewer issues Hi Brad, Could you see if you can reproduce this problem with the one of the OSG examples, or a small tweak of one to reproduce this problem. If I can reproduce it reliably then there is a much better chance of spotting the culprit and finding a solution. Cheers, Robert. On Tue, Sep 21, 2010 at 10:27 PM, Brad Huber br...@procerusuav.com wrote: Hello, I recently converted our osg based application over to use Composite Viewer because we need multiple Views on the same scene graph. Im running in to a little snag which appears to be a bug in CompositeViewer. Simple way of explaining the manifestation of the issue is that I have two Windows and two Views (one view per window) and they both have event handlers attached to the views which react to the osgGA::GUIEventAdapter::RESIZE event. Resizing works hunky dory for view 0 but it does not work correctly for view 1. I believe the culprit is related to these lines of code found in CompositeViewer::eventTraversal(). osgViewer::View* masterView = getViewWithFocus() ? getViewWithFocus() : _views[0].get(); . . . viewEventsMap[masterView].insert( viewEventsMap[masterView].end(), gw_events.begin(), gw_events.end() ); The problem is that when resizing, apparently getViewWithFocus() returns NULL (I guess because the mouse is over the window frame and not the view within the window. Therefore a resize event is taken out of the graphics window queue for the 2nd window and stuck into the event queue for the 0 view (a mismatch). The effect for me is that the when I resize one window the HUD I have set up in the other window receives the resize event and changes which obviously isnt what I want J. This does seem to be somewhat intermittent and may be related to whether your mouse tends to fall off the window frame towards the view or away from the view PS I dont have a solution in hand yet. I thought I would throw this out there in case its a known issue or something. Thanks -Brad ___ 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 mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] CompositeViewer issues
Robert, Attached is a simple stripped down app that demonstrates the problem. The program creates two windows (2 views total). The 1st has a HUD and the 2nd doesn't. Resizing the 2nd window causes the HUD in the first window to resize (it shouldn't). I am reliably producing this bug on my Win7 machine. I'm quite confident that this bug will be reproducible on all Windows. I am a little bit less sure of Linux/Mac, etc. I've included a Visual Studio 2005 project but since there is only one source file it should be easy to get it building under Linux. Thanks -Brad -Original Message- From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Robert Osfield Sent: Wednesday, September 22, 2010 2:25 AM To: OpenSceneGraph Users Subject: Re: [osg-users] CompositeViewer issues Hi Brad, Could you see if you can reproduce this problem with the one of the OSG examples, or a small tweak of one to reproduce this problem. If I can reproduce it reliably then there is a much better chance of spotting the culprit and finding a solution. Cheers, Robert. On Tue, Sep 21, 2010 at 10:27 PM, Brad Huber br...@procerusuav.com wrote: Hello, I recently converted our osg based application over to use Composite Viewer because we need multiple Views on the same scene graph. Im running in to a little snag which appears to be a bug in CompositeViewer. Simple way of explaining the manifestation of the issue is that I have two Windows and two Views (one view per window) and they both have event handlers attached to the views which react to the osgGA::GUIEventAdapter::RESIZE event. Resizing works hunky dory for view 0 but it does not work correctly for view 1. I believe the culprit is related to these lines of code found in CompositeViewer::eventTraversal(). osgViewer::View* masterView = getViewWithFocus() ? getViewWithFocus() : _views[0].get(); . . . viewEventsMap[masterView].insert( viewEventsMap[masterView].end(), gw_events.begin(), gw_events.end() ); The problem is that when resizing, apparently getViewWithFocus() returns NULL (I guess because the mouse is over the window frame and not the view within the window. Therefore a resize event is taken out of the graphics window queue for the 2nd window and stuck into the event queue for the 0 view (a mismatch). The effect for me is that the when I resize one window the HUD I have set up in the other window receives the resize event and changes which obviously isnt what I want J. This does seem to be somewhat intermittent and may be related to whether your mouse tends to fall off the window frame towards the view or away from the view PS I dont have a solution in hand yet. I thought I would throw this out there in case its a known issue or something. Thanks -Brad ___ 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 CompositeViewer_Playground.zi_ Description: Binary data ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] CompositeViewer issues
Hello, I recently converted our osg based application over to use Composite Viewer because we need multiple Views on the same scene graph. I'm running in to a little snag which appears to be a bug in CompositeViewer. Simple way of explaining the manifestation of the issue is that I have two Windows and two Views (one view per window) and they both have event handlers attached to the views which react to the osgGA::GUIEventAdapter::RESIZE event. Resizing works hunky dory for view 0 but it does not work correctly for view 1. I believe the culprit is related to these lines of code found in CompositeViewer::eventTraversal(). osgViewer::View* masterView = getViewWithFocus() ? getViewWithFocus() : _views[0].get(); . . . viewEventsMap[masterView].insert( viewEventsMap[masterView].end(), gw_events.begin(), gw_events.end() ); The problem is that when resizing, apparently getViewWithFocus() returns NULL (I guess because the mouse is over the window frame and not the view within the window. Therefore a resize event is taken out of the graphics window queue for the 2nd window and stuck into the event queue for the 0 view (a mismatch). The effect for me is that the when I resize one window the HUD I have set up in the other window receives the resize event and changes which obviously isn't what I want J. This does seem to be somewhat intermittent and may be related to whether your mouse tends to fall off the window frame towards the view or away from the view. PS I don't have a solution in hand yet. I thought I would throw this out there in case it's a known issue or something. Thanks -Brad ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Keypress broken since rev 11749
Gentlemen,
I apologize for being inactive on the thread these last few days. I was on
vacation at the Reno Air Races J.
Trajce- to address your point about how to make MFC “work properly”. The
example code IS NOT a dialog based MFC app. My app IS a dialog based MFC app.
Dialogs in MFC do not capture/receive the WM_CHAR message and that is why I
cannot properly pass it on to the OSG window. Of course there are other work
arounds that address my particular problem (I believe I’ve already fixed it),
but I’m trying to bring up the point that this may be a fundamental issue in
the key handling.
Robert- One issue with including both the translated and untranslated keys in
the event is that there is not a one to one mapping. In windows sometimes 3
key presses will translate to one WM_CHAR (translated key) message and they
don’t even need to be pressed at the same time (in the case of dead keys).
Whereas I believe there is a one-to-one between WM_KEYDOWN and key presses…
Thanks
-Brad
From: osg-users-boun...@lists.openscenegraph.org
[mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Trajce (Nick)
Nikolov
Sent: Friday, September 17, 2010 10:57 AM
To: osg-users@lists.openscenegraph.org
Subject: Re: [osg-users] Keypress broken since rev 11749
Hi Robert,
I find some time to dig into this. And here are my observations ( I am working
with Vivien's submission, with osgviewerMFC )
I put break points in GraphicsWindowWin32.cpp:
Line: 2476
case WM_KEYDOWN:
case WM_SYSKEYDOWN :
{
int keySymbol = 0;
Line: 2451
/
case WM_CHAR :
/
{
// if event was not handled by WM_KEYDOWN then we take care of
it here
// this method gives directly the utf16 char back so just need
to add it as it is
if(!_keypresshandled)
{
// first check if key is already registered on the map
case WM_KEYDOWN/WM_SYSKEYDOWN : get its chance to handle every single key you
press, even a dead key. So, for my czech character 'č', I have to press: SHIFT,
'+', and 'c', in this order, and for each of these three I get WM_KEYDOWN. The
only difference is that when I complete this sequence, on top of all
WM_KEYDOWNs, it gets to case WM_CHAR: with my 'č'. This is how the system is
managing these events. To reflect this behavior into OSG, only one single line
needs to be added, I think, and that will fix Brad's issue as well:
else
{
// was no special key, let WM_CHAR handle it
_keypresshandled = false;
_lastkeysymbol = keySymbol;
/* the new line */
getEventQueue()-keyPress(keySymbol, eventTime);
}
This was the key that was waste (being 'eaten' :) ..).
So to me it sounds that, with Vivien's submission, only the dead key +
'something' was not firing an event in osg - for the rest it should work as
before, not as Brad states above that the key events stopped work. I am very
curious what he was actually doing.
Cheers,
-Nick
On Fri, Sep 17, 2010 at 8:04 PM, Vivien Delage vdel...@gmail.com wrote:
Hi guys,
I understand you Robert. I have no problem with reverting the code for now if
this causes issues for other people. I will go and experiment a bit more on how
to fix the dead key problem. Maybe I can find a solution which is not using the
WM_CHAR message. I will let you know how it goes on my side.
Cheers,
Vivien
--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=31778#31778
___
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] Keypress broken since rev 11749
JS- Great. Sounds reasonable. -Brad -Original Message- From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Jean-Sébastien Guay Sent: Monday, September 20, 2010 9:51 AM To: OpenSceneGraph Users Subject: Re: [osg-users] Keypress broken since rev 11749 Hi Brad, Robert- One issue with including both the translated and untranslated keys in the event is that there is not a one to one mapping. In windows sometimes 3 key presses will translate to one WM_CHAR (translated key) message and they don’t even need to be pressed at the same time (in the case of dead keys). Whereas I believe there is a one-to-one between WM_KEYDOWN and key presses… I don't think that's a problem, in that case there will be 3 keydown events: - the first two would have an untranslated key code but the translated code would be invalid (say -1 so the app can recognize it and just do nothing if it only wants translated codes) - and the third event would have both a translated and untranslated codes (both would be valid). Thus apps that want raw keypresses could get them, and apps (or osgWidget::Input) that need translated keys could just ignore keypresses where the translated code is invalid. 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] Keypress broken since rev 11749
Nick, I tried the change you proposed, thanks. It is not sufficient because keySymbol gets set to 0 in adaptKey. Therefore a key press of 0 is inserted into the event queue. Something along these lines would work but I dont know if we want to generate extra/indistinguishable keydowns in this manner. I would advocate what JS proposed instead. For example the user hits ` then a. I believe a fix along the lines of what Nick proposed would generate 3 keydowns, one for ` one for a and one for à. A fix along the lines of what JS proposed would generate 2 keydowns. One for ` with a translated code of 0. One for a with a translated code of à. This way the translated and untranslated codes are distinguishable. JS- However I am wary of the issue where the WM_KEYDOWN is received and WM_CHAR is not (as in my case). In this case how do you handle what you are proposing? Another option would be to make separate keydown and char events (like windows has). It sounds like this would be a lot of work. Also Im not sure how other OSs handle this Thanks -Brad From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Trajce (Nick) Nikolov Sent: Monday, September 20, 2010 10:03 AM To: OpenSceneGraph Users Subject: Re: [osg-users] Keypress broken since rev 11749 Hi Brad, did you tried my change with adding the new extra line in GraphicsWindowWin32.cpp ? I think it will fix it. This way the key that was being translated to WM_CHAR will be passed as WM_KEYDOWN as well -Nick On Mon, Sep 20, 2010 at 5:51 PM, Jean-Sébastien Guay jean-sebastien.g...@cm-labs.com wrote: Hi Brad, Robert- One issue with including both the translated and untranslated keys in the event is that there is not a one to one mapping. In windows sometimes 3 key presses will translate to one WM_CHAR (translated key) message and they dont even need to be pressed at the same time (in the case of dead keys). Whereas I believe there is a one-to-one between WM_KEYDOWN and key presses I don't think that's a problem, in that case there will be 3 keydown events: - the first two would have an untranslated key code but the translated code would be invalid (say -1 so the app can recognize it and just do nothing if it only wants translated codes) - and the third event would have both a translated and untranslated codes (both would be valid). Thus apps that want raw keypresses could get them, and apps (or osgWidget::Input) that need translated keys could just ignore keypresses where the translated code is invalid. 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] Keypress broken since rev 11749
Nick,
According to my understanding and experience, CDialog::PreTranslateMessage(MSG
*msg) does not receive WM_CHAR messages so I cannot do anything about that. In
the MFC documentation there is a CWnd::GetDlgCode method which tells the
framework which key messages (like WM_CHAR) your class would like to receive
but again this does not work for CDialog classes. GetDlgCode does not get
called and PreTranslateMessage does not ever get WM_CHAR. Therefore I cannot
use any WM_CHAR based mechanism with my existing CDialog based app. I can use
a work around (ie don’t rely on any WM_KEYDOWN) and use WM_KEYUP instead. I
could also investigate inserting a control on top of the dialog which would
allow receipt of WM_CHAR messages. Anyway there is apparently nothing I can do
to force WM_CHAR to work with CDialog.
Thanks
-Brad
From: osg-users-boun...@lists.openscenegraph.org
[mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Trajce (Nick)
Nikolov
Sent: Monday, September 20, 2010 11:06 AM
To: OpenSceneGraph Users
Subject: Re: [osg-users] Keypress broken since rev 11749
Hi Brad,
Dialogs in MFC do not capture/receive the WM_CHAR message and that is why I
cannot properly pass it on to the OSG window
you could override CDialog::PreTranslateMessage( MSG* msg ) and do it the same
way is CView from the osgviewerMFC example
-Nick
On Mon, Sep 20, 2010 at 5:29 PM, Brad Huber br...@procerusuav.com wrote:
Gentlemen,
I apologize for being inactive on the thread these last few days. I was on
vacation at the Reno Air Races J.
Trajce- to address your point about how to make MFC “work properly”. The
example code IS NOT a dialog based MFC app. My app IS a dialog based MFC app.
Dialogs in MFC do not capture/receive the WM_CHAR message and that is why I
cannot properly pass it on to the OSG window. Of course there are other work
arounds that address my particular problem (I believe I’ve already fixed it),
but I’m trying to bring up the point that this may be a fundamental issue in
the key handling.
Robert- One issue with including both the translated and untranslated keys in
the event is that there is not a one to one mapping. In windows sometimes 3
key presses will translate to one WM_CHAR (translated key) message and they
don’t even need to be pressed at the same time (in the case of dead keys).
Whereas I believe there is a one-to-one between WM_KEYDOWN and key presses…
Thanks
-Brad
From: osg-users-boun...@lists.openscenegraph.org
[mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Trajce (Nick)
Nikolov
Sent: Friday, September 17, 2010 10:57 AM
To: osg-users@lists.openscenegraph.org
Subject: Re: [osg-users] Keypress broken since rev 11749
Hi Robert,
I find some time to dig into this. And here are my observations ( I am working
with Vivien's submission, with osgviewerMFC )
I put break points in GraphicsWindowWin32.cpp:
Line: 2476
case WM_KEYDOWN:
case WM_SYSKEYDOWN :
{
int keySymbol = 0;
Line: 2451
/
case WM_CHAR :
/
{
// if event was not handled by WM_KEYDOWN then we take care of
it here
// this method gives directly the utf16 char back so just need
to add it as it is
if(!_keypresshandled)
{
// first check if key is already registered on the map
case WM_KEYDOWN/WM_SYSKEYDOWN : get its chance to handle every single key you
press, even a dead key. So, for my czech character 'č', I have to press: SHIFT,
'+', and 'c', in this order, and for each of these three I get WM_KEYDOWN. The
only difference is that when I complete this sequence, on top of all
WM_KEYDOWNs, it gets to case WM_CHAR: with my 'č'. This is how the system is
managing these events. To reflect this behavior into OSG, only one single line
needs to be added, I think, and that will fix Brad's issue as well:
else
{
// was no special key, let WM_CHAR handle it
_keypresshandled = false;
_lastkeysymbol = keySymbol;
/* the new line */
getEventQueue()-keyPress(keySymbol, eventTime);
}
This was the key that was waste (being 'eaten' :) ..).
So to me it sounds that, with Vivien's submission, only the dead key +
'something' was not firing an event in osg - for the rest it should work as
before, not as Brad states above that the key events stopped work. I am very
curious what he was actually doing.
Cheers,
-Nick
On Fri, Sep 17, 2010 at 8:04 PM, Vivien Delage vdel...@gmail.com wrote:
Hi guys,
I understand you Robert. I have no problem with reverting the code for now if
this causes issues for other people. I will go
Re: [osg-users] Keypress broken since rev 11749
Nick,
Thanks for the extra input. I’m using VC80. I’ve previously hooked up Spy++
and noticed that my window does not receive either WM_CHAR or WM_GETDLGCODE.
In addition I tried something like what you’ve mentioned and it doesn’t ever
get a WM_CHAR. It does get WM_KEYDOWN and others. Anyway I’ve also come
across several posts online saying the CDialog is different wrt WM_CHAR.
You’re example says differently and I haven’t tried a stripped down version
like that. I don’t want to belabor the point. The issue is essentially fixed
for me (regardless of which way we do translated / raw messages).
I guess we’ll see which direction Robert would like to take it vis-à-vis
translated/untranslated, dead keys, etc.
Thanks
-Brad
From: osg-users-boun...@lists.openscenegraph.org
[mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Trajce (Nick)
Nikolov
Sent: Monday, September 20, 2010 12:15 PM
To: OpenSceneGraph Users
Subject: Re: [osg-users] Keypress broken since rev 11749
Hi again Brad,
http://msdn.microsoft.com/en-us/library/619z63f5(VS.80).aspx
note the Note. This makes me think you are using older MFC that is not doing
that .
-Nick
On Mon, Sep 20, 2010 at 9:37 PM, Trajce (Nick) Nikolov
nikolov.tra...@gmail.com wrote:
Hi Brad,
I hate arguing :) ... For me it works. I put a break point on the Sleep and I
get there
BOOL CDialogDlg::PreTranslateMessage( MSG *pMsg )
{
if (pMsg-message == WM_CHAR )
{
// will I get here
Sleep(10);
}
return CDialog::PreTranslateMessage(pMsg);
}
-Nick
On Mon, Sep 20, 2010 at 9:28 PM, Brad Huber br...@procerusuav.com wrote:
Nick,
According to my understanding and experience, CDialog::PreTranslateMessage(MSG
*msg) does not receive WM_CHAR messages so I cannot do anything about that. In
the MFC documentation there is a CWnd::GetDlgCode method which tells the
framework which key messages (like WM_CHAR) your class would like to receive
but again this does not work for CDialog classes. GetDlgCode does not get
called and PreTranslateMessage does not ever get WM_CHAR. Therefore I cannot
use any WM_CHAR based mechanism with my existing CDialog based app. I can use
a work around (ie don’t rely on any WM_KEYDOWN) and use WM_KEYUP instead. I
could also investigate inserting a control on top of the dialog which would
allow receipt of WM_CHAR messages. Anyway there is apparently nothing I can do
to force WM_CHAR to work with CDialog.
Thanks
-Brad
From: osg-users-boun...@lists.openscenegraph.org
[mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Trajce (Nick)
Nikolov
Sent: Monday, September 20, 2010 11:06 AM
To: OpenSceneGraph Users
Subject: Re: [osg-users] Keypress broken since rev 11749
Hi Brad,
Dialogs in MFC do not capture/receive the WM_CHAR message and that is why I
cannot properly pass it on to the OSG window
you could override CDialog::PreTranslateMessage( MSG* msg ) and do it the same
way is CView from the osgviewerMFC example
-Nick
On Mon, Sep 20, 2010 at 5:29 PM, Brad Huber br...@procerusuav.com wrote:
Gentlemen,
I apologize for being inactive on the thread these last few days. I was on
vacation at the Reno Air Races J.
Trajce- to address your point about how to make MFC “work properly”. The
example code IS NOT a dialog based MFC app. My app IS a dialog based MFC app.
Dialogs in MFC do not capture/receive the WM_CHAR message and that is why I
cannot properly pass it on to the OSG window. Of course there are other work
arounds that address my particular problem (I believe I’ve already fixed it),
but I’m trying to bring up the point that this may be a fundamental issue in
the key handling.
Robert- One issue with including both the translated and untranslated keys in
the event is that there is not a one to one mapping. In windows sometimes 3
key presses will translate to one WM_CHAR (translated key) message and they
don’t even need to be pressed at the same time (in the case of dead keys).
Whereas I believe there is a one-to-one between WM_KEYDOWN and key presses…
Thanks
-Brad
From: osg-users-boun...@lists.openscenegraph.org
[mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Trajce (Nick)
Nikolov
Sent: Friday, September 17, 2010 10:57 AM
To: osg-users@lists.openscenegraph.org
Subject: Re: [osg-users] Keypress broken since rev 11749
Hi Robert,
I find some time to dig into this. And here are my observations ( I am working
with Vivien's submission, with osgviewerMFC )
I put break points in GraphicsWindowWin32.cpp:
Line: 2476
case WM_KEYDOWN:
case WM_SYSKEYDOWN :
{
int keySymbol = 0;
Line: 2451
/
case WM_CHAR :
/
{
// if event was not handled by WM_KEYDOWN then we take care of
it here
Re: [osg-users] Keypress broken since rev 11749
Nick,
Yes.
-Brad
From: osg-users-boun...@lists.openscenegraph.org
[mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Trajce (Nick)
Nikolov
Sent: Monday, September 20, 2010 2:23 PM
To: OpenSceneGraph Users
Subject: Re: [osg-users] Keypress broken since rev 11749
Hi Brad,
VS 8.0. Is that 2005?
-Nick
On Mon, Sep 20, 2010 at 11:52 PM, Brad Huber br...@procerusuav.com wrote:
Nick,
Thanks for the extra input. I’m using VC80. I’ve previously hooked up Spy++
and noticed that my window does not receive either WM_CHAR or WM_GETDLGCODE.
In addition I tried something like what you’ve mentioned and it doesn’t ever
get a WM_CHAR. It does get WM_KEYDOWN and others. Anyway I’ve also come
across several posts online saying the CDialog is different wrt WM_CHAR.
You’re example says differently and I haven’t tried a stripped down version
like that. I don’t want to belabor the point. The issue is essentially fixed
for me (regardless of which way we do translated / raw messages).
I guess we’ll see which direction Robert would like to take it vis-à-vis
translated/untranslated, dead keys, etc.
Thanks
-Brad
From: osg-users-boun...@lists.openscenegraph.org
[mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Trajce (Nick)
Nikolov
Sent: Monday, September 20, 2010 12:15 PM
To: OpenSceneGraph Users
Subject: Re: [osg-users] Keypress broken since rev 11749
Hi again Brad,
http://msdn.microsoft.com/en-us/library/619z63f5(VS.80).aspx
note the Note. This makes me think you are using older MFC that is not doing
that .
-Nick
On Mon, Sep 20, 2010 at 9:37 PM, Trajce (Nick) Nikolov
nikolov.tra...@gmail.com wrote:
Hi Brad,
I hate arguing :) ... For me it works. I put a break point on the Sleep and I
get there
BOOL CDialogDlg::PreTranslateMessage( MSG *pMsg )
{
if (pMsg-message == WM_CHAR )
{
// will I get here
Sleep(10);
}
return CDialog::PreTranslateMessage(pMsg);
}
-Nick
On Mon, Sep 20, 2010 at 9:28 PM, Brad Huber br...@procerusuav.com wrote:
Nick,
According to my understanding and experience, CDialog::PreTranslateMessage(MSG
*msg) does not receive WM_CHAR messages so I cannot do anything about that. In
the MFC documentation there is a CWnd::GetDlgCode method which tells the
framework which key messages (like WM_CHAR) your class would like to receive
but again this does not work for CDialog classes. GetDlgCode does not get
called and PreTranslateMessage does not ever get WM_CHAR. Therefore I cannot
use any WM_CHAR based mechanism with my existing CDialog based app. I can use
a work around (ie don’t rely on any WM_KEYDOWN) and use WM_KEYUP instead. I
could also investigate inserting a control on top of the dialog which would
allow receipt of WM_CHAR messages. Anyway there is apparently nothing I can do
to force WM_CHAR to work with CDialog.
Thanks
-Brad
From: osg-users-boun...@lists.openscenegraph.org
[mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Trajce (Nick)
Nikolov
Sent: Monday, September 20, 2010 11:06 AM
To: OpenSceneGraph Users
Subject: Re: [osg-users] Keypress broken since rev 11749
Hi Brad,
Dialogs in MFC do not capture/receive the WM_CHAR message and that is why I
cannot properly pass it on to the OSG window
you could override CDialog::PreTranslateMessage( MSG* msg ) and do it the same
way is CView from the osgviewerMFC example
-Nick
On Mon, Sep 20, 2010 at 5:29 PM, Brad Huber br...@procerusuav.com wrote:
Gentlemen,
I apologize for being inactive on the thread these last few days. I was on
vacation at the Reno Air Races J.
Trajce- to address your point about how to make MFC “work properly”. The
example code IS NOT a dialog based MFC app. My app IS a dialog based MFC app.
Dialogs in MFC do not capture/receive the WM_CHAR message and that is why I
cannot properly pass it on to the OSG window. Of course there are other work
arounds that address my particular problem (I believe I’ve already fixed it),
but I’m trying to bring up the point that this may be a fundamental issue in
the key handling.
Robert- One issue with including both the translated and untranslated keys in
the event is that there is not a one to one mapping. In windows sometimes 3
key presses will translate to one WM_CHAR (translated key) message and they
don’t even need to be pressed at the same time (in the case of dead keys).
Whereas I believe there is a one-to-one between WM_KEYDOWN and key presses…
Thanks
-Brad
From: osg-users-boun...@lists.openscenegraph.org
[mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Trajce (Nick)
Nikolov
Sent: Friday, September 17, 2010 10:57 AM
To: osg-users@lists.openscenegraph.org
Subject: Re: [osg-users] Keypress broken since rev 11749
Hi Robert,
I find some time to dig into this. And here are my observations ( I am working
with Vivien's submission, with osgviewerMFC
Re: [osg-users] Keypress broken since rev 11749
JS, You're right. I believe osgviewer still works correctly. I didn't look if it uses keyup or keydown. It appears that the osg window in my app does not get the WM_CHAR messages and so the change mentioned below broke it for me. I'm looking at why this message isn't being propagated. A different question, is why is the code written this way? I mean as I understand in windows you get a WM_KEYDOWN msg for all keys and then if it is a character you later get a WM_CHAR (possible multiple depending on key repeat?) and then when the user releases the key you get a WM_KEYUP. That's my understanding anyway. The current osg implementation seems more convoluted..? Thanks -Brad -Original Message- From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Jean-Sébastien Guay Sent: Wednesday, September 15, 2010 5:19 PM To: OpenSceneGraph Users Subject: Re: [osg-users] Keypress broken since rev 11749 Hi Brad, It appears that with the changes to GraphicsWindowWin32.cpp at rev 11749 that keypress does not get called when one hits a non special key (eg one of the letter keys). If I understand correctly, non-special keys are no longer totally handled from WM_KEYDOWN and they are supposed to use WM_CHAR or something. This does not appear to work. Ill keep looking, but perhaps someone else has already noticed the bug/fix? From your description above, it makes me think that in osgviewer, the normal keys shouldn't work, for example pressing 's' shouldn't show the onscreen stats (since the StatsHandler does its work on osgGA::GUIEventAdapter::KEYDOWN events). But it still does, with an OSG compiled last night (Windows 7 64-bit, Visual C++ 2008 sp1 32-bit build). Can you be more specific on what I would need to do to see this 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] Keypress broken since rev 11749
Vivien, JS, A couple of thoughts- My app is an MFC based concoction. As such the osg window is a dialog and not a control. Apparently dialogs do not (and cannot) receive WM_CHAR messages. One work around for me is to only use keyup and not to use keydown. However I think this doesn't address a general problem as outlined below. My understanding is that WM_KEYDOWN is generated instantly when a key is pressed. It tells you that a key was pressed. It does not really tell you if that key was an 'a' or 'A' or 'á'. WM_CHAR does the necessary translations and tells you which a was meant. Now the problem is that both mechanisms seem very necessary that's why Windows generates WM_KEYDOWN AND WM_CHAR and not just one or the other. Often times in game programming you want to know when the a button or the tilde button was pressed. You don't want the computer to do dead keys and turn it into something else. I guess what I'm saying is that I would argue that the mapping should be WM_KEYDOWN - osgGA::GUIEventAdapter::KEYDOWN and WM_KEYUP - osgGA::GUIEventAdapter::KEYUP. There might need to be a separate mechanism for handling WM_CHAR. An example from the game side would be if you are playing DOOM and using 'a','w','s','d' for straffing, you want those buttons to work regardless of if someone hit the ~ or ^ previously or had the caps lock on, etc. Now if you are putting text into an edit box, then you want the ~ or ^... PS I'm no expert so what I'm saying could be misguided :) Thoughts? -Brad -Original Message- From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Jean-Sébastien Guay Sent: Thursday, September 16, 2010 11:35 AM To: osg-users@lists.openscenegraph.org Subject: Re: [osg-users] Keypress broken since rev 11749 Hi Vivien, Thanks for replying, it's good to know why the change was needed. I did it in order to fix an issue with dead keys that were not handled correctly. Dead keys are used for key combination. For example in French keyboard pressing '^' key then after that 'u' key should result in the character 'û'. This was not working properly with osg. I didn't know that, I'm a native French speaker but I rarely use French when I use my computer (just how I've always done it) and I've never tried to use accented characters in an OSG app. I guess with osgWidget::Input now it becomes possible and desirable for some apps, so I understand the need for your change. If you were to make an OSG-based e-mail or IM client I would probably need to use accented characters in it too :-) Now the real question is why you do not receive the event WM_CHAR on your application. Any idea on that? Brad, how are you using the osgViewer::GraphicsWindowWin32? Is it in a normal osgViewer window? Is it in a Qt or other GUI toolkit window? If that's the case then perhaps the GUI toolkit is not redirecting all its Windows messages to the GraphicsWindow correctly? 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] Keypress broken since rev 11749
It appears that with the changes to GraphicsWindowWin32.cpp at rev 11749 that keypress does not get called when one hits a non special key (eg one of the letter keys). If I understand correctly, non-special keys are no longer totally handled from WM_KEYDOWN and they are supposed to use WM_CHAR or something. This does not appear to work. I'll keep looking, but perhaps someone else has already noticed the bug/fix? Thanks -Brad ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Granular LOD control
Hello, I am interested in granularly controlling the LODScale for different parts of my scene graph. For example I have one part of the graph rendering a globe (osgEarth) and another part rendering items on the globe. I would like to be able to increase or decrease the LODScale for just the globe portion without disturbing everything else. The CullSettings are typically attached to the Camera. I wasn't sure initially that creating two separate cameras was the right solution. I still want the depth buffering and render order stuff to be preserved the way it is now (the globe and the items on the globe render to the same depth buffer). Thoughts? Thanks -Brad ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Plugin to Node Kit?
Robert, Here is what I would like to do: We have an existing app that has a GUI which builds a directshow graph including selecting a capture device and properties on that capture device and building the necessary intermediate filters. If I can pass a Directshow Pin (or pointer to pin) into the directshow texture then my work is done. Obviously this does require the tighter coupling of which you speak. Within the plugin architecture- the current abilities of osgDirectshow are not expressive enough. The alternative that I see would be way more complex and would be something like making the plugin read the .grf file format which allows specifying complex graphs. Also I would need to make our app able to write these files which it doesn't currently. Very much overkill in my opinion. The third alternative would be for me to expose DirectshowTexture but not to have commits accepted back to the community. Thoughts? Thanks -Brad -Original Message- From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Robert Osfield Sent: Tuesday, June 29, 2010 3:28 AM To: OpenSceneGraph Users Subject: Re: [osg-users] Plugin to Node Kit? Hi Brad, The plugins are designed to be entirely encapsulated within themselves and not to export any symbols, save for any C function entry points for enabling static linking of plugins. This decoupled approach does mean that you don't have any public interface to access internals classes/methods. In general this isn't an issue though. What specifically about the DirectShowTexture header do you need access to? It may be that you do what you want within any specific access to it. Keeping a loose coupling is generally the best programming approach as it enables you to change you backend implementation easily - such as if you needed to support a new platform. Robert. On Tue, Jun 29, 2010 at 12:51 AM, Brad Huber br...@procerusuav.com wrote: Hello, I am curious what the path is for a osg plugin to become a node kit (or portions of it). Does anyone have some information / insight? The reason that I ask is that Im trying to use the Directshow texture class that is currently in the osg directshow plugin. I do not believe a plugin is sufficient for what Im trying to do because I want to work directly with the low-level directshow graph. As I understand, this is something that cannot be easily done via the file based plugin architecture. For example I want to instantiate a rather complex graph (programmatically from a GUI) and then connect a pin to the Directshow texture. Perhaps Im not seeing the correct way to go about this, if so, I would love some advice. Otherwise- what is the process to go from plugin to node kit especially for a platform specific library such as directshow. Thanks for your input -Brad ___ 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 mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Plugin to Node Kit?
Stephan, Excellent idea. I'm still cutting my teeth on this stuff. I'll pursue this option. I'll see if I can find some examples of passing non-primitive types through the plugin options. Thanks -Brad -Original Message- From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Stephan Maximilian Huber Sent: Tuesday, June 29, 2010 10:27 AM To: OpenSceneGraph Users Subject: Re: [osg-users] Plugin to Node Kit? Hi Brad, if the only thing you want is to pass paramters / objects to the plugin, so it sets up its stuff accordingly you can use ReaderWriter::Options::setPluginData and extend the DirectoShow-Plugin to use these plugin-data if available. So you can feed you directshow-pin to the plugin and set it up accordingly and you can submit these changes back to the community. This should work the other way round, too. Add the data you are interested in to the options-object, and use them afterwards. Just thinking loud, cheers, Stephan Am 29.06.10 17:57, schrieb Brad Huber: Robert, Here is what I would like to do: We have an existing app that has a GUI which builds a directshow graph including selecting a capture device and properties on that capture device and building the necessary intermediate filters. If I can pass a Directshow Pin (or pointer to pin) into the directshow texture then my work is done. Obviously this does require the tighter coupling of which you speak. Within the plugin architecture- the current abilities of osgDirectshow are not expressive enough. The alternative that I see would be way more complex and would be something like making the plugin read the .grf file format which allows specifying complex graphs. Also I would need to make our app able to write these files which it doesn't currently. Very much overkill in my opinion. The third alternative would be for me to expose DirectshowTexture but not to have commits accepted back to the community. Thoughts? Thanks -Brad -Original Message- From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Robert Osfield Sent: Tuesday, June 29, 2010 3:28 AM To: OpenSceneGraph Users Subject: Re: [osg-users] Plugin to Node Kit? Hi Brad, The plugins are designed to be entirely encapsulated within themselves and not to export any symbols, save for any C function entry points for enabling static linking of plugins. This decoupled approach does mean that you don't have any public interface to access internals classes/methods. In general this isn't an issue though. What specifically about the DirectShowTexture header do you need access to? It may be that you do what you want within any specific access to it. Keeping a loose coupling is generally the best programming approach as it enables you to change you backend implementation easily - such as if you needed to support a new platform. Robert. On Tue, Jun 29, 2010 at 12:51 AM, Brad Huber br...@procerusuav.com wrote: Hello, I am curious what the path is for a osg plugin to become a node kit (or portions of it). Does anyone have some information / insight? The reason that I ask is that I'm trying to use the Directshow texture class that is currently in the osg directshow plugin. I do not believe a plugin is sufficient for what I'm trying to do because I want to work directly with the low-level directshow graph. As I understand, this is something that cannot be easily done via the file based plugin architecture. For example I want to instantiate a rather complex graph (programmatically from a GUI) and then connect a pin to the Directshow texture. Perhaps I'm not seeing the correct way to go about this, if so, I would love some advice. Otherwise- what is the process to go from plugin to node kit especially for a platform specific library such as directshow. Thanks for your input -Brad ___ 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 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 mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Plugin to Node Kit?
Hello, I am curious what the path is for a osg plugin to become a node kit (or portions of it). Does anyone have some information / insight? The reason that I ask is that I'm trying to use the Directshow texture class that is currently in the osg directshow plugin. I do not believe a plugin is sufficient for what I'm trying to do because I want to work directly with the low-level directshow graph. As I understand, this is something that cannot be easily done via the file based plugin architecture. For example I want to instantiate a rather complex graph (programmatically from a GUI) and then connect a pin to the Directshow texture. Perhaps I'm not seeing the correct way to go about this, if so, I would love some advice. Otherwise- what is the process to go from plugin to node kit especially for a platform specific library such as directshow. Thanks for your input -Brad ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgText issue
Thanks Robert and Terry. I've left off solving the problem for the moment and I switched to using an AutoTransform node for the same effect. Seems to be working well. BTW it might be nice if osgText had a provision for allowing screen size position/offsets. Eg you can currently use osgText::setPosition to set the texts position In model space but not one for screen space. In my case I was trying to have a label appear to the side of a 3d object in the scene. Seems like a common enough application. That's part of my reason for switching to autotransform. Perhaps I missed another better method (Billboard?). Thanks -Brad From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Brad Huber Sent: Thursday, June 03, 2010 5:06 PM To: 'OpenSceneGraph Users' Subject: Re: [osg-users] osgText issue It looks like for some reason my screen aligned, screen sized text is getting small feature culled under certain circumstances. My small feature cull is set to the default (2 pixels) and my text is definitely larger than 2 pixels (when it does show). When I disable small feature culling the text always shows correctly. I'm still not sure why this is happening but is it possible that it is using the world size of my drawables for culling rather than the actual screen size? Also, I'm not sure why this is an intermittent problem. (ie text doesn't show then I zoom in and it shows, then zoom back out and it still shows). Thoughts? Thanks -Brad From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Brad Huber Sent: Thursday, June 03, 2010 10:02 AM To: 'OpenSceneGraph Users' Subject: [osg-users] osgText issue Cedric (or anyone else), I'm running in to a similar issue to what is described here: http://www.mail-archive.com/osg-users@lists.openscenegraph.org/msg15610.html a long time ago by Cedric Pinson. I searched around in the forum archives and didn't see any resolution to this issue nor did I find anything else similar. Did you ever find a solution to this problem? The way it manifests for me is that there is an osgText object in the visible scene but it doesn't show until I zoom the camera in on it. Then it appears and if I zoom the camera back out it sticks around. It should be showing the whole time. Thanks -Brad ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] osgText issue
Cedric (or anyone else), I'm running in to a similar issue to what is described here: http://www.mail-archive.com/osg-users@lists.openscenegraph.org/msg15610.html a long time ago by Cedric Pinson. I searched around in the forum archives and didn't see any resolution to this issue nor did I find anything else similar. Did you ever find a solution to this problem? The way it manifests for me is that there is an osgText object in the visible scene but it doesn't show until I zoom the camera in on it. Then it appears and if I zoom the camera back out it sticks around. It should be showing the whole time. Thanks -Brad ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgText issue
It looks like for some reason my screen aligned, screen sized text is getting small feature culled under certain circumstances. My small feature cull is set to the default (2 pixels) and my text is definitely larger than 2 pixels (when it does show). When I disable small feature culling the text always shows correctly. I'm still not sure why this is happening but is it possible that it is using the world size of my drawables for culling rather than the actual screen size? Also, I'm not sure why this is an intermittent problem. (ie text doesn't show then I zoom in and it shows, then zoom back out and it still shows). Thoughts? Thanks -Brad From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Brad Huber Sent: Thursday, June 03, 2010 10:02 AM To: 'OpenSceneGraph Users' Subject: [osg-users] osgText issue Cedric (or anyone else), I'm running in to a similar issue to what is described here: http://www.mail-archive.com/osg-users@lists.openscenegraph.org/msg15610.html a long time ago by Cedric Pinson. I searched around in the forum archives and didn't see any resolution to this issue nor did I find anything else similar. Did you ever find a solution to this problem? The way it manifests for me is that there is an osgText object in the visible scene but it doesn't show until I zoom the camera in on it. Then it appears and if I zoom the camera back out it sticks around. It should be showing the whole time. Thanks -Brad ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Debugging osg state issues
Just to drop a note I found the solution to the issue I was seeing in case anyone else has something similar. I am using CEGUI (CEGUIDrawable). It requires that the texture unit be set (to zero) before the CEGUI render routines. Unfortunately with the new changes as of rev 10926 of OSG (which removes redundant sets of the texture unit) OSG no longer sets the texture unit back to what it needs. I fixed the problem by modifying CEGUIDrawable so that it restores the texture unit that was being used. Thanks -Brad -Original Message- From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Brad Huber Sent: Wednesday, May 26, 2010 2:16 PM To: 'OpenSceneGraph Users' Subject: Re: [osg-users] Debugging osg state issues It seems that this issue is definitely texture related. The problem did not manifest before rev 10926 in the trunk. It now manifests from rev 10926 onward. 10926 has changes which try to prevent thrashing of the active texture unit. I'm going through the changes to see how I might have my scene graph wrong or if there could be some other issue. I would appreciate it if anyone else has extra insight (specifically how something might render correctly before the change and incorrectly after the change). Thanks -Brad -Original Message- From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Robert Osfield Sent: Saturday, May 22, 2010 2:27 AM To: OpenSceneGraph Users Subject: Re: [osg-users] Debugging osg state issues Hi Brad, You could use a draw callback on the drawable and there query OpenGL or the osg::State object to find out what state has been applied. In general the OSG is pretty reliable w.r.t state application, the same scheme has been in place for the best part of decade now. Areas that are most likely to come unstuck is in your set of the scene graph - perhaps you aren't placing the StateSet's in appropriate place in the scene graph to get the result you want, the OSG uses top down inheritance of StateSet, state isn't inherited to siblings like in Inventor. Another area that you might come unstuck is not assigning all the vertex attributes that you require correctly - a missing colour array, or normal array? Try outputting your scene graph to a .osg file and then inspect it. Robert. On Fri, May 21, 2010 at 10:06 PM, Brad Huber br...@procerusuav.com wrote: Im having an issue where some particular drawables arent rendering correctly. Im pretty certain that the state at render time is not what Im actually wanting it to be. Does anyone know of a convenient way to inspect the actual state at render time? The problem is convoluted enough that Im not sure I can just trust looking at the stateset of it (and its parents) before hand. I want to know the real render time answer. PS I tried putting another drawable as a sibling to the first drawable which looks at renderInfo.getState() but I dont think this is what I want for a couple of reasons Thanks -Brad ___ 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 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] Debugging osg state issues
It seems that this issue is definitely texture related. The problem did not manifest before rev 10926 in the trunk. It now manifests from rev 10926 onward. 10926 has changes which try to prevent thrashing of the active texture unit. I'm going through the changes to see how I might have my scene graph wrong or if there could be some other issue. I would appreciate it if anyone else has extra insight (specifically how something might render correctly before the change and incorrectly after the change). Thanks -Brad -Original Message- From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Robert Osfield Sent: Saturday, May 22, 2010 2:27 AM To: OpenSceneGraph Users Subject: Re: [osg-users] Debugging osg state issues Hi Brad, You could use a draw callback on the drawable and there query OpenGL or the osg::State object to find out what state has been applied. In general the OSG is pretty reliable w.r.t state application, the same scheme has been in place for the best part of decade now. Areas that are most likely to come unstuck is in your set of the scene graph - perhaps you aren't placing the StateSet's in appropriate place in the scene graph to get the result you want, the OSG uses top down inheritance of StateSet, state isn't inherited to siblings like in Inventor. Another area that you might come unstuck is not assigning all the vertex attributes that you require correctly - a missing colour array, or normal array? Try outputting your scene graph to a .osg file and then inspect it. Robert. On Fri, May 21, 2010 at 10:06 PM, Brad Huber br...@procerusuav.com wrote: Im having an issue where some particular drawables arent rendering correctly. Im pretty certain that the state at render time is not what Im actually wanting it to be. Does anyone know of a convenient way to inspect the actual state at render time? The problem is convoluted enough that Im not sure I can just trust looking at the stateset of it (and its parents) before hand. I want to know the real render time answer. PS I tried putting another drawable as a sibling to the first drawable which looks at renderInfo.getState() but I dont think this is what I want for a couple of reasons Thanks -Brad ___ 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 mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Debugging osg state issues
I'm having an issue where some particular drawables aren't rendering correctly. I'm pretty certain that the state at render time is not what I'm actually wanting it to be. Does anyone know of a convenient way to inspect the actual state at render time? The problem is convoluted enough that I'm not sure I can just trust looking at the stateset of it (and its parents) before hand. I want to know the real render time answer. PS I tried putting another drawable as a sibling to the first drawable which looks at renderInfo.getState() but I don't think this is what I want for a couple of reasons. Thanks -Brad ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Interesting issue with OSG upgrade
I'm seeing an interesting issue with an existing app upon upgrade from OSG
2.8 to the trunk (well 2.9.8).
A simplified version of the situation is like this: I have two drawables
both of which use texture unit 0.
In the stateset for both objects I have:
textureUnit 0 {
GL_TEXTURE_2D PROTECTED|ON
}
For simplicity I will refer to object one as Airplane and object two as
HUDElement.
The issue is this- when Airplane is in view, both Airplane and HUDElement
render correctly. When airplane is out of view(culled), HUDElement no
longer renders correctly (it appears the texture unit is turned off). If I
remove the GL_TEXTURE_2D ON from Airplane then HUDElement does not render
correctly even when Airplane is in view. Airplane and HUDElement are not
parents/children of each other and are in fairly distant parts of the graph.
This issue did not exist/manifest when I was using OSG 2.8 but now exists
when I 'm using OSG 2.9.8 (no other changes).
Does anyone have any thoughts for me?
PS I have suspicion about the actual render time state so I posted a
separate but related general question about that.
Thanks
-Brad
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] OpenGL extension/feature blacklist for GPUs
I am currently struggling with some issues where our OSG based app causes a crash in Intel driver DLLs on some customer computers equipped with Intel GPUs. As I recall OSG designers (Robert) have pushed to keep GPU based blacklist features out of OSG. So my question is, what other alternative tools exist? Surely this is a common problem in the graphics app world. Does anyone know of a 3rd party that keeps an accurate blacklist? Do there exist tools that programmatically probe correct support for features (Eg automated tests that read back and verify the results)? Can anyone point me to such information? Thanks! -Brad PS Don't bother with the answer Don't use Intel GPUs. Not an option J ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OpenGL extension/feature blacklist for GPUs
Robert, Thanks for the info. Yes I've used the disable extension mechanism. I guess I'm interested in some kind of actual list that would say which cards (and possibly driver version) have trouble with what extensions/features. Or a programmatic way to test the same thing. That way we can have more confidence that we can actually come up with the right extension disables and allow our app to work without us extensively testing on each set of hardware that our software might run on. To date the main issues we've experienced are with cards that report they support a feature/extension but in actuality they do not (it's buggy). Also I'm not advocating that these features be introduced into OSG, I'm just wondering if anyone knows of some helpful tools in this area. PS As a related question, do game/graphics app producers generally each have to develop and maintain their own blacklists for possibly large sets of different hardware? Seems like a lot of duplication of effort if they do. Thanks -Brad -Original Message- From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Robert Osfield Sent: Thursday, April 15, 2010 12:47 PM To: OpenSceneGraph Users Subject: Re: [osg-users] OpenGL extension/feature blacklist for GPUs Hi Brad, On Thu, Apr 15, 2010 at 7:37 PM, Brad Huber br...@procerusuav.com wrote: As I recall OSG designers (Robert) have pushed to keep GPU based blacklist features out of OSG. Actually the OSG already support disabling of extensions, see include/osg/GLExtensions: /** Set a list of extensions to disable for different OpenGL renderers. This allows * OSG applications to work around OpenGL drivers' bugs which are due to problematic extension support. * The format of the string is: * GLRendererString : ExtensionName, ExtensionName; GLRenderString2 : ExtensionName; * An example of is : SUN_XVR1000:GL_EXT_texture_filter_anisotropic * The default setting of GLExtensionDisableString is obtained from the OSG_GL_EXTENSION_DISABLE * environmental variable. */ extern OSG_EXPORT void setGLExtensionDisableString(const std::string disableString); This won't disable core features that the driver says it support, but it will enable you disable many of the extensions that can be problematic. As to what extensions are problematic is really up to the individual develop to decide for their app based on testing against the target hardware they have. Since the driver situation can change on a daily basis the OSG itself doesn't generally attempt to codify what works or doesn't work. I'd also recommend not codifying too much into your app either, using the above env var, or a your own application specific file on disk that can be used to help set the ExtensionDisableString and help you decide which OpenGL/scene graph features to use at runtime. This way you can alter the file/env var as you encounter different drivers/hardware/problems. Robert. ___ 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] GL_SCISSOR_TEST error
Wojtek, Thanks. Yes I think this is along the lines of what I'm seeing. It is the glScissor within RenderStage::drawImplementation. I am not using osg::Scissor or any sort of Stencil buffering. According to the Man page: http://www.opengl.org/documentation/specs/man_pages/hardcopy/GL/html/gl/scis sor.html invalid value happens when either width or height is negative. I turned on the debug print in RenderStage::drawImplementation and I get the following: clearing 0B0C7DC8 0,0,800,600 clearing 0B0FC118 0,0,800,600 clearing 0BFE0290 0,0,800,600 clearing 0B110638 0,0,260,180 Warning: detected OpenGL error 'invalid value' after applying GLMode 0xc11 repeated over and over per frame So apparently the scissor fails when setting the width and height to 260 and 180 (which obviously aren't negative). Though those dimensions tell me that the failure happens for my Render to Texture (RTT) pass. I'm not quite sure what you mean by the FBO/PBuffer being initialized wrong. I'll have a look at that and also try glIntercept. PS The exact same code works on one machine but not on another OLD machine. Thanks! -Brad From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Wojciech Lewandowski Sent: Thursday, September 10, 2009 3:06 AM To: OpenSceneGraph Users Subject: Re: [osg-users] GL_SCISSOR_TEST error Hi Brad, Does it happen in state.applyMode( GL_SCISSOR_TEST ) call inside RenderStage::drawImplementation method ? I saw such errors when RenderStage buffer (FBO/PBuffer) initialization went wrong. It just happens that GL_SCISSOR_TEST is first mode that is applied after RenderStage buffer intialization and apparently error during the buffer initalization may be mistakenly interpreted as glScissor issue when scissor is applied and tests glError. In fact, if RenderBuffer was not applied correctly it may be the case where passed scissor area rectangle may not match previously set RenderBuffer and will produce an error as well, but even then, it will be secondary issue to Render Buffer inititalization failure. I often use glIntercept to see what really happen in OpenGL under OSG wrapping. glIntercept does not work with multithreading but produces fairly well, informal logs when osgViewer is run in --SingleThreaded mode. Cheers, Wojtek - Original Message - From: Brad Huber mailto:br...@procerusuav.com To: osg-users@lists.openscenegraph.org Sent: Wednesday, September 09, 2009 10:27 PM Subject: [osg-users] GL_SCISSOR_TEST error Hello, I seem to be getting the error Warning: detected OpenGL error 'invalid value' after applying GLMode which has been mentioned in other threads. After setting the OSG_GL_ERROR_CHECKING environment variable to ONCE_PER_ATTRIBUTE I get the more descriptive string Warning: detected OpenGL error 'invalid value' after applying GLMode 0xc11 This code corresponds to GL_SCISSOR_TEST mode. When this warning is printed I traced up the call stack to see that it's from the call state.applyMode( GL_SCISSOR_TEST, true ); in osg::RenderStage::drawImplementation. My question is does anyone know why I would be getting this message with GL_SCISSOR_TEST? This test is being run on an older machine with an Intel 815 GM graphics chip. Is it possible scissor isn't supported or something? PS I'm using rev 10555 of OSG from the trunk Thanks in advance, -Brad _ ___ 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] GL_SCISSOR_TEST error
Hello, I seem to be getting the error Warning: detected OpenGL error 'invalid value' after applying GLMode which has been mentioned in other threads. After setting the OSG_GL_ERROR_CHECKING environment variable to ONCE_PER_ATTRIBUTE I get the more descriptive string Warning: detected OpenGL error 'invalid value' after applying GLMode 0xc11 This code corresponds to GL_SCISSOR_TEST mode. When this warning is printed I traced up the call stack to see that it's from the call state.applyMode( GL_SCISSOR_TEST, true ); in osg::RenderStage::drawImplementation. My question is does anyone know why I would be getting this message with GL_SCISSOR_TEST? This test is being run on an older machine with an Intel 815 GM graphics chip. Is it possible scissor isn't supported or something? PS I'm using rev 10555 of OSG from the trunk Thanks in advance, -Brad ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Runtime texture mod
Thanks Ulrich and Jason, Originally I was thinking of something that would load a texture and modify everything with a certain hue (eg everything with a given hue is set to a different hue at runtime). Sounds like there aren't any existing tools for something like that (though it wouldn't be that hard to write). I'll pursue the other option of setting a material on the geometry. This makes things slightly more complicated because the geometry must use 2 separate materials which our current models don't have. Thus I'll have to specifically edit/create each of our models with the different materials. PS Shaders are a difficult option because we will likely be running our software on machines that don't support the new shader stuff... That's the only reason I wanted to stay away. Thanks! -Brad -Original Message- From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Ulrich Hertlein Sent: Saturday, July 18, 2009 12:34 AM To: OpenSceneGraph Users Subject: Re: [osg-users] Runtime texture mod On 17/7/09 6:14 PM, Brad Huber wrote: Does anyone know of a good way to modify pixels in a texture at runtime w OSG? Basically I’m looking for a way for the user to select an arbitrary color to be used on an airplane or similar. EG ability to switch to any color as in the attached image. From what you're saying it sounds like you really only need to modify the object base colour, using one of the techniques that Jason suggested. If you *really* want to modify individual pixels in a texture you can use Image::data() to get a pointer to the image data and modify that directly. It might be a bit tricky since you have to take the Image format into account. Call Image::dirty() when you're done with the modification to upload the new data to the texture. Cheers, /ulrich ___ 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] OSG Texture - CEGUI Texture
The problem is that osgWidget doesn't offer a lot of functionality that one finds in a somewhat more mature toolkit (even CEGUI). For example: * common GUI widgets are already fully developed (eg progress bar, scroll bar, tables, close button, etc) * GUI elements (windows, buttons, etc) are easily skinnable * XML content specification with graphical layout editor * etc. For us the context/threading issues may not be too hard to swallow, so it seems like a pretty good fit. Anyway, I dont want to start a debate, just throwing in my two cents on why we've decided to go with CEGUI over osgWidget. -Brad -Original Message- From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Robert Osfield Sent: Sunday, July 12, 2009 10:06 AM To: OpenSceneGraph Users Subject: Re: [osg-users] OSG Texture - CEGUI Texture Hi Brad, Could you just use osgWidget instead? I've played with CEGUI in the past and found it's design very poor for doing general purpose graphics application integration - it can't handle multiple graphics context nor multi-threading, I learnt enough about it's short coming in design and implementation to know that it wasn't worth investing more time into, there are far better ways to tackle this type of work. Robert. On Thu, Jul 9, 2009 at 4:15 PM, Brad Huberbr...@procerusuav.com wrote: Hello, Im currently using an RTT Camera within OSG and I would like to use the texture associated with it in CEGUI. This will give the ability to render a 3d scene within a CEGUI window. Im coming up short finding out how to do this. Has anyone done this previously and might have a code snippet? I did find this http://www.gamedboy.com/tiki-index.php?page=MiniMap%20CEGUI which shows Ogre-CEGUI but they use a magic function that converts between Ogre and CEGUI textures Thanks -Brad ___ 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 mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] TexGen texture coordinates
Actually the solution is simple. I was barking up the wrong tree with the texgennode. That's why I was soliciting help. What my code (and osgspotlight) was lacking is a texture matrix to center the spotlight and make it accurate. I've included the snippet for reference. osg::ref_ptrosg::TexMat texMat = new osg::TexMat; texMat-setMatrix(osg::Matrixd::translate(osg::Vec3d(0.5,0.5,0.0))); stateset-setTextureAttributeAndModes(textureUnit, texMat, osg::StateAttribute::ON); Thanks -Brad -Original Message- From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Robert Osfield Sent: Tuesday, May 05, 2009 10:07 AM To: OpenSceneGraph Users Subject: Re: [osg-users] TexGen texture coordinates HI Brad, I'm afraid I don't have any ideas what might be up. You're tweaking code I wrote a long while back in ways that I don't understand. The best I can do is recommend you do some background reading on projective textures. I can point you in the right direction, but it's not my role to teach you the basics of 3rd graphics. Robert. On Tue, May 5, 2009 at 4:57 PM, Brad Huber br...@procerusuav.com wrote: Robert, Osgspotlight does not do quite what I need as it stands. I've attached a screenshot of a modified osgspotlight to illustrate. It draws a line along the look vector of the texgen. As you can see it points to the lower left of the texture rather than the center. I tried modifying the code a couple of different ways-- for example a simple translation as below (the 50's) causes the projected texture to look right in at least one location and still wrong in most locations. // create tex gen. osg::TexGenNode *ret = new osg::TexGenNode; ret-setTextureUnit(textureUnit); osg::TexGen* texgen = ret-getTexGen(); texgen-setMode(osg::TexGen::EYE_LINEAR); osg::Matrixd lookAt = osg::Matrixd::lookAt(position, position+look, up); osg::Matrixd perspective = osg::Matrixd::perspective(angle,1.0,0.1,100); osg::Matrixd mat = lookAt*perspective; mat(3,0) = 50; mat(3,1) = 50; texgen-setPlanesFromMatrix(mat); Thanks -Brad -Original Message- From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Robert Osfield Sent: Tuesday, May 05, 2009 2:43 AM To: OpenSceneGraph Users Subject: Re: [osg-users] TexGen texture coordinates Hi Brad, You have to apply translation and scale matrix to convert from eye coords to texture coords. The osgspotlight example will be doing this. Robert. On Tue, May 5, 2009 at 12:28 AM, Brad Huber br...@procerusuav.com wrote: Hello, I've been playing with code very similar to the osgspotlight example. Basically I'm using a TexGen Node to project a texture on to some terrain. The issue I'm having is that the texture coordinates being generated map the look vector to the lower left pixel of the texture rather than the middle pixel(s) of the texture like I need. For example in the osgspotlight program the spotlight is not actually in the center for the look vector passed to the texgen node. Does anyone know how to correct for this? Thanks -Brad ___ 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 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 mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] TexGen texture coordinates
Hello, I've been playing with code very similar to the osgspotlight example. Basically I'm using a TexGen Node to project a texture on to some terrain. The issue I'm having is that the texture coordinates being generated map the look vector to the lower left pixel of the texture rather than the middle pixel(s) of the texture like I need. For example in the osgspotlight program the spotlight is not actually in the center for the look vector passed to the texgen node. Does anyone know how to correct for this? Thanks -Brad ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Understanding message handling
Can anyone give me the scoop on how gui event messages are handled with osgViewer? I'm trying to get the viewer running inside a GUI toolkit (in this case MFC). It's mostly working for me except for event propagation. Basically I've noticed that if you do osg::GraphicsContext::createGraphicsContext and pass it an hwnd then a couple of things happen: One the osgViewer::GraphicsWindowWin32 registers a WindowProc function with windows. This causes the function to be called back by default and respond to messages. HOWEVER since we provided an hWnd to it then GraphicsWindowWin32 has _ownsWindow marked false. As a result it registers for messages, reacts to them, but never returns a value saying it handled the message. This doesn't seem like a great way to do it to me. I have no way to know if OSG handled the event (such as a key press). If I assume it did handle it, I get in trouble. If I assume it didn't handle it, I get in trouble. To granularly figure this out would be a major pain. Maybe there is another way I should be setting this up. Can anyone shed some light? Thanks -Brad ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Weirdness with TerrainManipulator
I've noticed some weirdness with the TerrainManipulator. I assume this is a bug but maybe not? The simplest way to produce this behavior is to run osgviewer and feed it something. I've been feeding it a globe of the blue marble data created using the osgdem tutorial page. This is the older vpb/osgdem format. I assume the behavior is the same with the new stuff. Ok next I have my globe and everything is hunky dory. Now I zoom in to look somewhere on the earth surface. I rotate the camera using left mouse so that the camera is BELOW the terrain of the point I was looking out. Now I zoom out so that the camera comes out the opposite side of the earth. I'm now looking at a point directly on the other side of the earth from where I was looking at a second ago. Now if I try to pan the terrain (middle mouse) things are screwed up and directions are reversed. It looks like the math is not able to handle this type of scenario. I have a recent version of Open Scene Graph (v 2.9.0) from the trunk (about a week or so old). Thanks -Brad ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OSG Multithreaded Viewer and Windows/MFC problem
Robert, The struggle I was having was that viewer.stopThreading() was NOT shutting down threads. The reason was that during the shutdown process the window was destructed which caused the osg camera to be invalidated. However it did not shut down the appropriate rendering threads. When stopThreading was called (after the window was destroyed) there were no cameras and renderers to get because they were already invalidated. Thus in this condition the threads were left running. You could argue that the programmer should never allow this situation to happen. Then again it might be nice if OSG were able to detect this type of condition. Thanks -Brad -Original Message- From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Robert Osfield Sent: Friday, February 13, 2009 7:11 AM To: OpenSceneGraph Users Subject: Re: [osg-users] OSG Multithreaded Viewer and Windows/MFC problem Hi Umit, I'm not familiar with MFC nor the osgviewerMFC example, so my guess is that there is some issue with it. viewer.stopThreading() will stop all the threading that the viewer itself starts. If you have other threads running then this is down to your app to handle them. As for the errors on exit, this could be due to a number of things. Without stack traces and knowledge of osgviewerMFC/MFC I can't make any clear suggestion. As a general note threading and clean up of graphics context are the items that one has to be careful of. Robert. On Fri, Feb 13, 2009 at 2:03 PM, Ümit Uzun umituzu...@gmail.com wrote: Hi Robert, I have known stopping viewer but I actually asked about static render running thread, and how should I stop it and order of stopping mechanism. For example I have tried much of below codes combinations but always I get error while shutting down the application. _viewer-setDone(TRUE); Sleep(1000); _viewer-stopThreading(); Sleep(1000); _endthread(); Firstly I should setDone to TRUE and then stop viewer threading and lastly I end the created thread for static render function. But it always give me error while trying to do all these operaion in destructor. But while I delete different place out of destructor, it is closing error-free. I mean if I delete the created object explicitly there is no problem, but if I delete the created object in destructor there is threading problem. Thanks so much. Regards. 2009/2/13 Robert Osfield robert.osfi...@gmail.com Hi Umit, The viewer.stopThreading() method will stop the threads and not return until all threads have been stopped. Robert. On Fri, Feb 13, 2009 at 6:51 AM, Ümit Uzun umituzu...@gmail.com wrote: Hi Brad, Could you give more explanation please? How can you be sure the thread was stopped and in which method? Regards. 2009/2/13 Brad Huber br...@procerusuav.com FYI, We spent some time debugging this and found the problem. I was making the unfortunate mistake of stopping the osg threads in a deconstructor which was called AFTER destroying the window. Apparently OSG does not gracefully shut down threads and such if the window is pulled out from under it. The fix was to make sure that stopping threading and shutting down the viewer was all down BEFORE the window was made invalid. Hope this helps someone else. Thanks -Brad From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Ümit Uzun Sent: Thursday, February 12, 2009 3:35 AM To: OpenSceneGraph Users Subject: Re: [osg-users] OSG Multithreaded Viewer and Windows/MFC problem Hi Brad, I have same problem , but I can't resolve exactly. I only find kludge :) How can you delete your class which contains static render function? If you delete this class in destructor, it's normal getting error while closing your application. I have tried almost a day to resolve this undefined problem but couldn't. And My solution is; deleting class before parent destructor calling. I mean, you have renderClass and mainClass. renderClass is which contains all rendering operation and static render function. You create renderClass object from mainClass and before closing application you should delete renderClass out of mainClass destructor. And after that you should let the mainClass destructor to run. I hope it will give you smooth and error-free closing :) Regards. 2009/2/12 Brad Huber br...@procerusuav.com Hello, I am currently struggling with a problem that is manifesting in our MFC based app when using MultiThreading model with osg viewer. First of all when setting up the viewer in my class I used: mViewer-setThreadingModel(osgViewer::ViewerBase::ThreadingModel::AutomaticS election); I also tried the default of not setting anything and the same problem happens. If I set it to single
Re: [osg-users] OSG Multithreaded Viewer and Windows/MFC problem
Umit,
Here is the high level:
My code is functionality similar to osgviewerMFC. That is to say that I
have the class cOSG which does my rendering and scene graph setup. The
problem I was having was in the class which instantiates the cOSG object.
This classs deconstructed looked something like:
class ClassA : public CWnd
{
};
ClassA::~ClassA()
{
delete mOSG; // The instantion of cOSG
}
The problem is that when this destructor is called the window (CWnd) for the
class is already destroyed. Instead the deletion of mOSG must be done in
the OnDestroy method:
void ClassA::OnDestroy()
{
delete mOSG;
}
Doing the deletion here ensures that the window hasnt been destroyed yet.
OSG can cleanup and stop render threads prior to the CWnd getting destroyed.
As far how the static render function / thread is shut downI do EXACTLY the
same as how its done in the osgviewerMFC example.
-Brad
From: osg-users-boun...@lists.openscenegraph.org
[mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Ümit Uzun
Sent: Friday, February 13, 2009 7:03 AM
To: OpenSceneGraph Users
Subject: Re: [osg-users] OSG Multithreaded Viewer and Windows/MFC problem
Hi Robert,
I have known stopping viewer but I actually asked about static render
running thread, and how should I stop it and order of stopping mechanism.
For example I have tried much of below codes combinations but always I get
error while shutting down the application.
_viewer-setDone(TRUE);
Sleep(1000);
_viewer-stopThreading();
Sleep(1000);
_endthread();
Firstly I should setDone to TRUE and then stop viewer threading and lastly
I end the created thread for static render function. But it always give me
error while trying to do all these operaion in destructor. But while I
delete different place out of destructor, it is closing error-free.
I mean if I delete the created object explicitly there is no problem, but if
I delete the created object in destructor there is threading problem.
Thanks so much. Regards.
2009/2/13 Robert Osfield robert.osfi...@gmail.com
Hi Umit,
The viewer.stopThreading() method will stop the threads and not return
until all threads have been stopped.
Robert.
On Fri, Feb 13, 2009 at 6:51 AM, Ümit Uzun umituzu...@gmail.com wrote:
Hi Brad,
Could you give more explanation please? How can you be sure the thread was
stopped and in which method?
Regards.
2009/2/13 Brad Huber br...@procerusuav.com
FYI,
We spent some time debugging this and found the problem.
I was making the unfortunate mistake of stopping the osg threads in a
deconstructor which was called AFTER destroying the window. Apparently
OSG
does not gracefully shut down threads and such if the window is pulled
out
from under it.
The fix was to make sure that stopping threading and shutting down the
viewer was all down BEFORE the window was made invalid.
Hope this helps someone else.
Thanks
-Brad
From: osg-users-boun...@lists.openscenegraph.org
[mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Ümit
Uzun
Sent: Thursday, February 12, 2009 3:35 AM
To: OpenSceneGraph Users
Subject: Re: [osg-users] OSG Multithreaded Viewer and Windows/MFC problem
Hi Brad,
I have same problem , but I can't resolve exactly. I only find kludge :)
How can you delete your class which contains static render function? If
you delete this class in destructor, it's normal getting error while
closing
your application. I have tried almost a day to resolve this undefined
problem but couldn't.
And My solution is; deleting class before parent destructor calling. I
mean, you have renderClass and mainClass.
renderClass is which contains all rendering operation and static render
function.
You create renderClass object from mainClass and before closing
application you should delete renderClass out of mainClass destructor.
And
after that you should let the mainClass destructor to run. I hope it will
give you smooth and error-free closing :)
Regards.
2009/2/12 Brad Huber br...@procerusuav.com
Hello,
I am currently struggling with a problem that is manifesting in our MFC
based app when using MultiThreading model with osg viewer.
First of all when setting up the viewer in my class I used:
mViewer-setThreadingModel(osgViewer::ViewerBase::ThreadingModel::AutomaticS
election);
I also tried the default of not setting anything and the same problem
happens. If I set it to single threaded the problem disappears but
obviously I don't want to run single threaded.
Everything seems to run fine and then when I close the app my class
destructor gets called. The only code in the destructor is:
mViewer-setDone(true);
Sleep(1000);
mViewer-stopThreading();
Sleep(1000);
Which is the same as what the example mfc code in the repository does.
The sleeps were only added to see if there was a race condition problem.
However when
Re: [osg-users] OSG Multithreaded Viewer and Windows/MFC problem
FYI,
We spent some time debugging this and found the problem.
I was making the unfortunate mistake of stopping the osg threads in a
deconstructor which was called AFTER destroying the window. Apparently OSG
does not gracefully shut down threads and such if the window is pulled out
from under it.
The fix was to make sure that stopping threading and shutting down the
viewer was all down BEFORE the window was made invalid.
Hope this helps someone else.
Thanks
-Brad
From: osg-users-boun...@lists.openscenegraph.org
[mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Ümit Uzun
Sent: Thursday, February 12, 2009 3:35 AM
To: OpenSceneGraph Users
Subject: Re: [osg-users] OSG Multithreaded Viewer and Windows/MFC problem
Hi Brad,
I have same problem , but I can't resolve exactly. I only find kludge :) How
can you delete your class which contains static render function? If you
delete this class in destructor, it's normal getting error while closing
your application. I have tried almost a day to resolve this undefined
problem but couldn't.
And My solution is; deleting class before parent destructor calling. I mean,
you have renderClass and mainClass.
renderClass is which contains all rendering operation and static render
function.
You create renderClass object from mainClass and before closing application
you should delete renderClass out of mainClass destructor. And after that
you should let the mainClass destructor to run. I hope it will give you
smooth and error-free closing :)
Regards.
2009/2/12 Brad Huber br...@procerusuav.com
Hello,
I am currently struggling with a problem that is manifesting in our MFC
based app when using MultiThreading model with osg viewer.
First of all when setting up the viewer in my class I used:
mViewer-setThreadingModel(osgViewer::ViewerBase::ThreadingModel::AutomaticS
election);
I also tried the default of not setting anything and the same problem
happens. If I set it to single threaded the problem disappears but
obviously I don't want to run single threaded.
Everything seems to run fine and then when I close the app my class
destructor gets called. The only code in the destructor is:
mViewer-setDone(true);
Sleep(1000);
mViewer-stopThreading();
Sleep(1000);
Which is the same as what the example mfc code in the repository does. The
sleeps were only added to see if there was a race condition problem.
However when I trace in to stopThreading I see that it returns immediately
on the first line:
if (!_threadsRunning) return;
As a result it doesn't kill any threads or anything else BUT there are
threads still running and they show up in the debugger.
Then as the app continues to close I get:
Which takes me to:
win32mutex.cpp line 111
int Mutex::lock() {
Win32MutexPrivateData *pd =
static_castWin32MutexPrivateData*(_prvData);
#ifdef USE_CRITICAL_SECTION
// Block until we can take this lock.
EnterCriticalSection( (pd-_cs) ); ß exception here!
return 0;
#else
This is OSG/Openthreads stuff! I look up the call stack and see the
osgViewer::Renderer.
Does anyone have any insights about why this is going on?
Thanks
-Brad
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
--
Ümit Uzun
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] OSG Multithreaded Viewer and Windows/MFC problem
Hello,
I am currently struggling with a problem that is manifesting in our MFC
based app when using MultiThreading model with osg viewer.
First of all when setting up the viewer in my class I used:
mViewer-setThreadingModel(osgViewer::ViewerBase::ThreadingModel::AutomaticS
election);
I also tried the default of not setting anything and the same problem
happens. If I set it to single threaded the problem disappears but
obviously I dont want to run single threaded.
Everything seems to run fine and then when I close the app my class
destructor gets called. The only code in the destructor is:
mViewer-setDone(true);
Sleep(1000);
mViewer-stopThreading();
Sleep(1000);
Which is the same as what the example mfc code in the repository does. The
sleeps were only added to see if there was a race condition problem.
However when I trace in to stopThreading I see that it returns immediately
on the first line:
if (!_threadsRunning) return;
As a result it doesnt kill any threads or anything else BUT there are
threads still running and they show up in the debugger.
Then as the app continues to close I get:
Which takes me to:
win32mutex.cpp line 111
int Mutex::lock() {
Win32MutexPrivateData *pd =
static_castWin32MutexPrivateData*(_prvData);
#ifdef USE_CRITICAL_SECTION
// Block until we can take this lock.
EnterCriticalSection( (pd-_cs) ); ß exception here!
return 0;
#else
This is OSG/Openthreads stuff! I look up the call stack and see the
osgViewer::Renderer.
Does anyone have any insights about why this is going on?
Thanks
-Brad
image001.png___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OSG with existing application
FYI, I appear to have this issue fixed/working. I thought it might be a problem caused by conflict between D3D and OSG/OpenGL but really it was a problem caused by a bunch of #defines in our app which made OSG not compile... Thanks -Brad -Original Message- From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Robert Osfield Sent: Friday, January 30, 2009 2:42 AM To: OpenSceneGraph Users Subject: Re: [osg-users] OSG with existing application Hi Brad, On Fri, Jan 30, 2009 at 12:32 AM, Brad Huber br...@procerusuav.com wrote: I should mention that I've already been working on bringing OSG in to the existing app but haven't been had luck yet. That's why I'm hoping someone can point me to any helpful info. Mixing the OSG with an exisitng OpenGL graphics context that has it's state being manipulated by existing OpenGL is awkward, but this is a very different problem than just opening up an OpenGL window alongside another OpenGL or D3D graphics context that doesn't share any state. For mixing other OpenGL code and OSG within a single graphics context is possible, many others have done it before you, but it is a bit awkward, this isn't thread to discuss it though so I'll not dive in any further. Robert. ___ 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] OSG with existing application
Hello, I am currently working on merging OSG into and existing application that my company has. This application uses DirectX - specifically Direct3D, DirectInput, and DirectShow. I'd like to be able to use the existing components side by side (different windows within the same parent window) with a new OSG piece. Does anyone know where I can find some info about using OpenGL and DirectX in the same app? Please don't say use google because I tried that already and didn't have luck J. If I have to I can strip out all the D3D stuff but I can't get by without DirectInput and DirectShow. Thanks Brad Huber ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OSG with existing application
I should mention that I've already been working on bringing OSG in to the existing app but haven't been had luck yet. That's why I'm hoping someone can point me to any helpful info. Thanks -Brad From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Brad Huber Sent: Thursday, January 29, 2009 5:30 PM To: 'OpenSceneGraph Users' Subject: [osg-users] OSG with existing application Hello, I am currently working on merging OSG into and existing application that my company has. This application uses DirectX - specifically Direct3D, DirectInput, and DirectShow. I'd like to be able to use the existing components side by side (different windows within the same parent window) with a new OSG piece. Does anyone know where I can find some info about using OpenGL and DirectX in the same app? Please don't say use google because I tried that already and didn't have luck J. If I have to I can strip out all the D3D stuff but I can't get by without DirectInput and DirectShow. Thanks Brad Huber ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] osgwidgetscrolled example
When I run the osgwidgetsrolled example, the window frame / theme is completely screwed up. I can still control the borders and corners with the mouse but they don't render properly. It seems to be finding the theme .pngs just fine but just doesn't display them properly. I have OSG 2.7.8. Anyone having/not having this problem? Thanks -Brad ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] AutoTransform and Draggers
Hello all, I'm having a little trouble wrapping my head around getting AutoTransform and Draggers to play together so I thought I'd turn to the trusty mailing list. What I'm trying to do: 1) Populate a scene with many things. One of which is an object - let's assume it's a sphere for simplicity. 2) I want the sphere to translate according to world coordinates but as far as scaling I want it to stay in model/screen coordinates. In other words the sphere moves around but never changes size. 3) I want to be able to move the sphere around with the mouse in a 2D plane. What I've done: I'm close to a solution. I can use the AutoTransform to accomplish (2) by setting setAutoScaleToScreen(true) and that works fine by itself (w/o using a dragger). I can use a dragger (TranslatePlaneDragger) to accomplish (3) and that works fine by itself (w/o using autotransform) but the problem is that the sphere scales with the world/scene which I don't want. Now for trying to combine them: I've thought of at least 3 options (actually more) for what the scene graph should look like which follow. Option 1: [Root] [Transform node (local to world)] [AutoTransform node] [Group node] [Selection node] [Dragger node] And under [Selection node]: [mySphereGeode node] And under [Dragger node]: [_translate2DDragger (which is the default TranslatePlaneDragger geom geode) node] Option 2: [Root] [Transform node (local to world)] [Group node] [Selection node] [Dragger node] And under [Selection node]: [AutoTransform node] [mySphereGeode node] And under [Dragger node]: [_translate2DDragger (which is the default TranslatePlaneDragger geom geode) node] Option 3: [Root] [Transform node (local to world)] [Group node] [Selection node] [Dragger node] And under [Selection node]: [AutoTransform1 node] [mySphereGeode node] And under [Dragger node]: [AutoTransform2 node] [_translate2DDragger (which is the default TranslatePlaneDragger geom geode) node] Conceptually Options 1 and 2 don't seem right to me. I've tried them anyway-option 1 seems like it works until you move the camera and things go screwy. I think it's because the translations as a result of the dragger are magnified/scaled by the autotransform node above it. Option 2 works but leaves the dragger polygon in world coordinates which isn't what I want. Option 3 seems like the right choice to me but I can't get it to work correctly. The dragger polygon doesn't show up... Anyone have any insight?? I can provide more info for clarification and/or code snippets if anyone needs. Thanks -Brad ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] MFC SDI Example
Umit, Thank you very much. I am reviewing it now. -Brad From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Ümit Uzun Sent: Tuesday, January 13, 2009 6:59 PM To: OpenSceneGraph Users Subject: Re: [osg-users] MFC SDI Example Hi Brad, I want to show you how to creating MFC SDI example, I developed simple SDI MFC example. It would be really help you. And if you love this example we can push it in to OSG examples by the Robert's courtesy. Best Regards. 2009/1/13 Brad Huber br...@procerusuav.com I have noticed the following strange behaviors with MFC: 1. Using the MDI example included in the osg repository it general works but does report lots of (inaccurate?) memory leaks) 2. I created a simple SDI app using the MDI example as a reference. If I load an .osg file on startup the program tends to crash on exit. If I load the .osg sometime after the app is fully up it tends to exit about the same as the MDI example above. 3. I created a dialog based app and it seems to work about as well as the MDI example above. Thoughts? I'm not sure where to start to get the SDI app fixed and to get MFC in general working robustly with OSG. I would still love an example SDI app if anyone has one anywhere. Thanks -Brad -Original Message- From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Brad Huber Sent: Friday, January 09, 2009 1:54 PM To: 'OpenSceneGraph Users' Subject: Re: [osg-users] MFC SDI Example FYI, Setting mViewer-setThreadingModel(osgViewer::Viewer::ThreadingModel::SingleThreaded ) doesn't help. Not sure if that is telling or not. -Brad -Original Message- From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Brad Huber Sent: Friday, January 09, 2009 1:47 PM To: 'OpenSceneGraph Users' Subject: Re: [osg-users] MFC SDI Example The OSG MFC example does not assert/unhandled exception for me. It does have the memory leaks that people have talked about. I'm not quite sure how to use the setUpViewerAsEmbeddedInWindow because the mfc example passes an dc to the camera whereas setUpViewerAsEmbeddedInWindow passes in a different dc... -Brad -Original Message- From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Simon Hammett Sent: Friday, January 09, 2009 2:21 AM To: OpenSceneGraph Users Subject: Re: [osg-users] MFC SDI Example The MDI mfc version has the same problems last time I tried it. Try calling setUpViewerAsEmbeddedInWindow on your viewer. If you problems go away you're hitting threading issues. 2009/1/8 Brad Huber br...@procerusuav.com: Umit, Thanks. The SDI application that I have created so far is very simple and does nothing more than what the MDI example app does. As far as I can tell there is no difference in the way the example creates/uses/deletes the cOSG object and the way I am doing it, yet I get assertions or exceptions on exit. Anyone else? Thanks -Brad From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Ümit Uzun Sent: Thursday, January 08, 2009 2:08 PM To: OpenSceneGraph Users Subject: Re: [osg-users] MFC SDI Example Hi Brad, I created SDI MFC project in OSG. But this was commercial and complicated to understand you very well. Because it was SDI dll to call from anywhere you need and you then delete it if you don't need to much. I haven't understood the assertion faults very well but you should only understand the cOSG class creation style. You will use it in your SDI project and be careful to delete everything while you are destroying your dialog. And be careful about the threads sleeping time to be activeted. Because sometimes sleeping times can't be enough to be threads get activated, so it may create assertion fault as you say. Hope this helps. Regards. 2009/1/8 Brad Huber br...@procerusuav.com Hello all, Does anyone know where one might find an example project of using MFC/OSG/SDI? If anyone has one sitting around on their machine I would be interested if you can email it to me as well. I've already tried adapting the MFC MDI example to an SDI project but I seem to be hitting some snags where the app won't exit properly. It either asserts the window as being still valid when it shouldn't be [CWnd::WalkPreTranslateTree's ASSERT(hWndStop == NULL || ::IsWindow(hWndStop))] or it get's The activation context being deactivated is not the most recently activated one exception within osg53-osgGAd.dll after I've deleted all osg items. I'm a little bit baffled why I'm getting this. Anyway does anyone have any SDI examples? Thanks -Brad ___ osg-users mailing list osg-users@lists.openscenegraph.org http
Re: [osg-users] MFC SDI Example
Ümit, The example you send me is actually a Dialog based MFC app. Not an SDI. Still looking for an SDI example if anyone has one. I do appreciate any MFC examples (MDI, SDI, or Dialog) as well. Thanks Again -Brad From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Ümit Uzun Sent: Tuesday, January 13, 2009 6:59 PM To: OpenSceneGraph Users Subject: Re: [osg-users] MFC SDI Example Hi Brad, I want to show you how to creating MFC SDI example, I developed simple SDI MFC example. It would be really help you. And if you love this example we can push it in to OSG examples by the Robert's courtesy. Best Regards. 2009/1/13 Brad Huber br...@procerusuav.com I have noticed the following strange behaviors with MFC: 1. Using the MDI example included in the osg repository it general works but does report lots of (inaccurate?) memory leaks) 2. I created a simple SDI app using the MDI example as a reference. If I load an .osg file on startup the program tends to crash on exit. If I load the .osg sometime after the app is fully up it tends to exit about the same as the MDI example above. 3. I created a dialog based app and it seems to work about as well as the MDI example above. Thoughts? I'm not sure where to start to get the SDI app fixed and to get MFC in general working robustly with OSG. I would still love an example SDI app if anyone has one anywhere. Thanks -Brad -Original Message- From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Brad Huber Sent: Friday, January 09, 2009 1:54 PM To: 'OpenSceneGraph Users' Subject: Re: [osg-users] MFC SDI Example FYI, Setting mViewer-setThreadingModel(osgViewer::Viewer::ThreadingModel::SingleThreaded ) doesn't help. Not sure if that is telling or not. -Brad -Original Message- From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Brad Huber Sent: Friday, January 09, 2009 1:47 PM To: 'OpenSceneGraph Users' Subject: Re: [osg-users] MFC SDI Example The OSG MFC example does not assert/unhandled exception for me. It does have the memory leaks that people have talked about. I'm not quite sure how to use the setUpViewerAsEmbeddedInWindow because the mfc example passes an dc to the camera whereas setUpViewerAsEmbeddedInWindow passes in a different dc... -Brad -Original Message- From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Simon Hammett Sent: Friday, January 09, 2009 2:21 AM To: OpenSceneGraph Users Subject: Re: [osg-users] MFC SDI Example The MDI mfc version has the same problems last time I tried it. Try calling setUpViewerAsEmbeddedInWindow on your viewer. If you problems go away you're hitting threading issues. 2009/1/8 Brad Huber br...@procerusuav.com: Umit, Thanks. The SDI application that I have created so far is very simple and does nothing more than what the MDI example app does. As far as I can tell there is no difference in the way the example creates/uses/deletes the cOSG object and the way I am doing it, yet I get assertions or exceptions on exit. Anyone else? Thanks -Brad From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Ümit Uzun Sent: Thursday, January 08, 2009 2:08 PM To: OpenSceneGraph Users Subject: Re: [osg-users] MFC SDI Example Hi Brad, I created SDI MFC project in OSG. But this was commercial and complicated to understand you very well. Because it was SDI dll to call from anywhere you need and you then delete it if you don't need to much. I haven't understood the assertion faults very well but you should only understand the cOSG class creation style. You will use it in your SDI project and be careful to delete everything while you are destroying your dialog. And be careful about the threads sleeping time to be activeted. Because sometimes sleeping times can't be enough to be threads get activated, so it may create assertion fault as you say. Hope this helps. Regards. 2009/1/8 Brad Huber br...@procerusuav.com Hello all, Does anyone know where one might find an example project of using MFC/OSG/SDI? If anyone has one sitting around on their machine I would be interested if you can email it to me as well. I've already tried adapting the MFC MDI example to an SDI project but I seem to be hitting some snags where the app won't exit properly. It either asserts the window as being still valid when it shouldn't be [CWnd::WalkPreTranslateTree's ASSERT(hWndStop == NULL || ::IsWindow(hWndStop))] or it get's The activation context being deactivated is not the most recently activated one exception within osg53-osgGAd.dll after I've deleted all osg items. I'm a little bit baffled why I'm getting this. Anyway does
[osg-users] Problem/bug with StatsHandler in OSG 2.7.8
While using the unmodified stats handler in OSG I have notice a fairly
consistent debug assertion on my Windows machine. The assertion has to do
with stl vectors and occurs when I have the stat handler showing the number
of vertices rendered. This is the assertion:
Here is the call stack:
msvcp80d.dll!std::_Debug_message(const wchar_t *
message=0x013c8c48, const wchar_t * file=0x013c75b8, unsigned int line=99)
Line 24 C++
osg53-osgTextd.dll!std::_Vector_const_iteratorosg::Vec3f,std::allocatorosg
::Vec3f ::operator*() Line 99 + 0x14 bytes C++
osg53-osgTextd.dll!std::vectorosg::Vec3f,std::allocatorosg::Vec3f
::front() Line 772 + 0x24 bytes C++
osg53-osgTextd.dll!osgText::Text::accept(osg::PrimitiveFunctor pf={...})
Line 1438 + 0x14 bytes C++
osg53-osgUtild.dll!osgUtil::RenderBin::getStats(osgUtil::Statistics
stats={...}) Line 506 + 0x13 bytes C++
osg53-osgUtild.dll!osgUtil::RenderBin::getStats(osgUtil::Statistics
stats={...}) Line 538 + 0x1d bytes C++
osg53-osgUtild.dll!osgUtil::RenderBin::getStats(osgUtil::Statistics
stats={...}) Line 538 + 0x1d bytes C++
osg53-osgUtild.dll!osgUtil::RenderStage::getStats(osgUtil::Statistics
stats={...}) Line 1296 + 0xc bytes C++
osg53-osgUtild.dll!osgUtil::RenderStage::getStats(osgUtil::Statistics
stats={...}) Line 1290 + 0x1d bytes C++
osg53-osgUtild.dll!osgUtil::SceneView::getStats(osgUtil::Statistics
stats={...}) Line 1694C++
osg53-osgViewerd.dll!osgViewer::CameraSceneStatsTextDrawCallback::drawImplem
entation(osg::RenderInfo renderInfo={...}, const osg::Drawable *
drawable=0x0767fb38) Line 355 + 0x1e bytesC++
osg53-osgd.dll!osg::Drawable::draw(osg::RenderInfo
renderInfo={...}) Line 896 + 0x27 bytes C++
osg53-osgUtild.dll!osgUtil::RenderLeaf::render(osg::RenderInfo
renderInfo={...}, osgUtil::RenderLeaf * previous=0x07696260) Line 60 + 0x19
bytesC++
osg53-osgUtild.dll!osgUtil::RenderBin::drawImplementation(osg::RenderInfo
renderInfo={...}, osgUtil::RenderLeaf * previous=0x07696260) Line 419 +
0x19 bytes C++
osg53-osgUtild.dll!osgUtil::RenderBin::draw(osg::RenderInfo
renderInfo={...}, osgUtil::RenderLeaf * previous=0x07696260) Line 384 +
0x17 bytes C++
osg53-osgUtild.dll!osgUtil::RenderBin::drawImplementation(osg::RenderInfo
renderInfo={...}, osgUtil::RenderLeaf * previous=0x07696260) Line 469 +
0x35 bytes C++
osg53-osgUtild.dll!osgUtil::RenderStage::drawImplementation(osg::RenderInfo
renderInfo={...}, osgUtil::RenderLeaf * previous=0x07696260) Line 1253
C++
osg53-osgUtild.dll!osgUtil::RenderBin::draw(osg::RenderInfo
renderInfo={...}, osgUtil::RenderLeaf * previous=0x07696260) Line 384 +
0x17 bytes C++
osg53-osgUtild.dll!osgUtil::RenderStage::drawInner(osg::RenderInfo
renderInfo={...}, osgUtil::RenderLeaf * previous=0x07696260, bool
doCopyTexture=false) Line 848C++
osg53-osgUtild.dll!osgUtil::RenderStage::draw(osg::RenderInfo
renderInfo={...}, osgUtil::RenderLeaf * previous=0x07696260) Line 1108 +
0x1b bytes C++
osg53-osgUtild.dll!osgUtil::SceneView::draw() Line 1504 +
0x37 bytesC++
osg53-osgViewerd.dll!osgViewer::Renderer::cull_draw() Line
545 + 0xf bytesC++
osg53-osgViewerd.dll!osgViewer::Renderer::operator()(osg::GraphicsContext *
context=0x02e16b40) Line 646 + 0xf bytes C++
osg53-osgd.dll!osg::GraphicsContext::runOperations() Line
688 + 0x33 bytes C++
osg53-osgd.dll!osg::RunOperations::operator()(osg::GraphicsContext *
context=0x02e16b40) Line 135 C++
osg53-osgd.dll!osg::GraphicsOperation::operator()(osg::Object *
object=0x02e16b40) Line 50 + 0x19 bytesC++
osg53-osgd.dll!osg::OperationThread::run() Line 413 + 0x26
bytes C++
osg53-osgd.dll!osg::GraphicsThread::run() Line 40
C++
ot11-OpenThreadsd.dll!OpenThreads::ThreadPrivateActions::StartThread(void *
data=0x050383c8) Line 113 + 0xf bytes C++
msvcr80d.dll!_callthreadstartex() Line 348 + 0xf bytes C
msvcr80d.dll!_threadstartex(void * ptd=0x0503b600) Line 331
C
kernel32.dll!7610e3f3()
[Frames below may be incorrect and/or missing, no symbols
loaded for kernel32.dll]
ntdll.dll!___rtluserthreadst...@8() + 0x23 bytes
ntdll.dll!__rtluserthreadst...@8() + 0x1b bytes
Has anyone seen this? Does anyone know why this is or what it relates to?
Solution?
Thanks
-Brad
image001.png___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] MFC SDI Example
I have noticed the following strange behaviors with MFC: 1. Using the MDI example included in the osg repository it general works but does report lots of (inaccurate?) memory leaks) 2. I created a simple SDI app using the MDI example as a reference. If I load an .osg file on startup the program tends to crash on exit. If I load the .osg sometime after the app is fully up it tends to exit about the same as the MDI example above. 3. I created a dialog based app and it seems to work about as well as the MDI example above. Thoughts? I'm not sure where to start to get the SDI app fixed and to get MFC in general working robustly with OSG. I would still love an example SDI app if anyone has one anywhere. Thanks -Brad -Original Message- From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Brad Huber Sent: Friday, January 09, 2009 1:54 PM To: 'OpenSceneGraph Users' Subject: Re: [osg-users] MFC SDI Example FYI, Setting mViewer-setThreadingModel(osgViewer::Viewer::ThreadingModel::SingleThreaded ) doesn't help. Not sure if that is telling or not. -Brad -Original Message- From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Brad Huber Sent: Friday, January 09, 2009 1:47 PM To: 'OpenSceneGraph Users' Subject: Re: [osg-users] MFC SDI Example The OSG MFC example does not assert/unhandled exception for me. It does have the memory leaks that people have talked about. I'm not quite sure how to use the setUpViewerAsEmbeddedInWindow because the mfc example passes an dc to the camera whereas setUpViewerAsEmbeddedInWindow passes in a different dc... -Brad -Original Message- From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Simon Hammett Sent: Friday, January 09, 2009 2:21 AM To: OpenSceneGraph Users Subject: Re: [osg-users] MFC SDI Example The MDI mfc version has the same problems last time I tried it. Try calling setUpViewerAsEmbeddedInWindow on your viewer. If you problems go away you're hitting threading issues. 2009/1/8 Brad Huber br...@procerusuav.com: Umit, Thanks. The SDI application that I have created so far is very simple and does nothing more than what the MDI example app does. As far as I can tell there is no difference in the way the example creates/uses/deletes the cOSG object and the way I am doing it, yet I get assertions or exceptions on exit. Anyone else? Thanks -Brad From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Ümit Uzun Sent: Thursday, January 08, 2009 2:08 PM To: OpenSceneGraph Users Subject: Re: [osg-users] MFC SDI Example Hi Brad, I created SDI MFC project in OSG. But this was commercial and complicated to understand you very well. Because it was SDI dll to call from anywhere you need and you then delete it if you don't need to much. I haven't understood the assertion faults very well but you should only understand the cOSG class creation style. You will use it in your SDI project and be careful to delete everything while you are destroying your dialog. And be careful about the threads sleeping time to be activeted. Because sometimes sleeping times can't be enough to be threads get activated, so it may create assertion fault as you say. Hope this helps. Regards. 2009/1/8 Brad Huber br...@procerusuav.com Hello all, Does anyone know where one might find an example project of using MFC/OSG/SDI? If anyone has one sitting around on their machine I would be interested if you can email it to me as well. I've already tried adapting the MFC MDI example to an SDI project but I seem to be hitting some snags where the app won't exit properly. It either asserts the window as being still valid when it shouldn't be [CWnd::WalkPreTranslateTree's ASSERT(hWndStop == NULL || ::IsWindow(hWndStop))] or it get's The activation context being deactivated is not the most recently activated one exception within osg53-osgGAd.dll after I've deleted all osg items. I'm a little bit baffled why I'm getting this. Anyway does anyone have any SDI examples? Thanks -Brad ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- Ümit Uzun ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- The truth is out there. Usually in header files. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg
Re: [osg-users] MFC SDI Example
The OSG MFC example does not assert/unhandled exception for me. It does have the memory leaks that people have talked about. I'm not quite sure how to use the setUpViewerAsEmbeddedInWindow because the mfc example passes an dc to the camera whereas setUpViewerAsEmbeddedInWindow passes in a different dc... -Brad -Original Message- From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Simon Hammett Sent: Friday, January 09, 2009 2:21 AM To: OpenSceneGraph Users Subject: Re: [osg-users] MFC SDI Example The MDI mfc version has the same problems last time I tried it. Try calling setUpViewerAsEmbeddedInWindow on your viewer. If you problems go away you're hitting threading issues. 2009/1/8 Brad Huber br...@procerusuav.com: Umit, Thanks. The SDI application that I have created so far is very simple and does nothing more than what the MDI example app does. As far as I can tell there is no difference in the way the example creates/uses/deletes the cOSG object and the way I am doing it, yet I get assertions or exceptions on exit. Anyone else? Thanks -Brad From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Ümit Uzun Sent: Thursday, January 08, 2009 2:08 PM To: OpenSceneGraph Users Subject: Re: [osg-users] MFC SDI Example Hi Brad, I created SDI MFC project in OSG. But this was commercial and complicated to understand you very well. Because it was SDI dll to call from anywhere you need and you then delete it if you don't need to much. I haven't understood the assertion faults very well but you should only understand the cOSG class creation style. You will use it in your SDI project and be careful to delete everything while you are destroying your dialog. And be careful about the threads sleeping time to be activeted. Because sometimes sleeping times can't be enough to be threads get activated, so it may create assertion fault as you say. Hope this helps. Regards. 2009/1/8 Brad Huber br...@procerusuav.com Hello all, Does anyone know where one might find an example project of using MFC/OSG/SDI? If anyone has one sitting around on their machine I would be interested if you can email it to me as well. I've already tried adapting the MFC MDI example to an SDI project but I seem to be hitting some snags where the app won't exit properly. It either asserts the window as being still valid when it shouldn't be [CWnd::WalkPreTranslateTree's ASSERT(hWndStop == NULL || ::IsWindow(hWndStop))] or it get's The activation context being deactivated is not the most recently activated one exception within osg53-osgGAd.dll after I've deleted all osg items. I'm a little bit baffled why I'm getting this. Anyway does anyone have any SDI examples? Thanks -Brad ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- Ümit Uzun ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- The truth is out there. Usually in header files. ___ 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] MFC SDI Example
FYI, Setting mViewer-setThreadingModel(osgViewer::Viewer::ThreadingModel::SingleThreaded ) doesn't help. Not sure if that is telling or not. -Brad -Original Message- From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Brad Huber Sent: Friday, January 09, 2009 1:47 PM To: 'OpenSceneGraph Users' Subject: Re: [osg-users] MFC SDI Example The OSG MFC example does not assert/unhandled exception for me. It does have the memory leaks that people have talked about. I'm not quite sure how to use the setUpViewerAsEmbeddedInWindow because the mfc example passes an dc to the camera whereas setUpViewerAsEmbeddedInWindow passes in a different dc... -Brad -Original Message- From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Simon Hammett Sent: Friday, January 09, 2009 2:21 AM To: OpenSceneGraph Users Subject: Re: [osg-users] MFC SDI Example The MDI mfc version has the same problems last time I tried it. Try calling setUpViewerAsEmbeddedInWindow on your viewer. If you problems go away you're hitting threading issues. 2009/1/8 Brad Huber br...@procerusuav.com: Umit, Thanks. The SDI application that I have created so far is very simple and does nothing more than what the MDI example app does. As far as I can tell there is no difference in the way the example creates/uses/deletes the cOSG object and the way I am doing it, yet I get assertions or exceptions on exit. Anyone else? Thanks -Brad From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Ümit Uzun Sent: Thursday, January 08, 2009 2:08 PM To: OpenSceneGraph Users Subject: Re: [osg-users] MFC SDI Example Hi Brad, I created SDI MFC project in OSG. But this was commercial and complicated to understand you very well. Because it was SDI dll to call from anywhere you need and you then delete it if you don't need to much. I haven't understood the assertion faults very well but you should only understand the cOSG class creation style. You will use it in your SDI project and be careful to delete everything while you are destroying your dialog. And be careful about the threads sleeping time to be activeted. Because sometimes sleeping times can't be enough to be threads get activated, so it may create assertion fault as you say. Hope this helps. Regards. 2009/1/8 Brad Huber br...@procerusuav.com Hello all, Does anyone know where one might find an example project of using MFC/OSG/SDI? If anyone has one sitting around on their machine I would be interested if you can email it to me as well. I've already tried adapting the MFC MDI example to an SDI project but I seem to be hitting some snags where the app won't exit properly. It either asserts the window as being still valid when it shouldn't be [CWnd::WalkPreTranslateTree's ASSERT(hWndStop == NULL || ::IsWindow(hWndStop))] or it get's The activation context being deactivated is not the most recently activated one exception within osg53-osgGAd.dll after I've deleted all osg items. I'm a little bit baffled why I'm getting this. Anyway does anyone have any SDI examples? Thanks -Brad ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- Ümit Uzun ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- The truth is out there. Usually in header files. ___ 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 mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] MFC SDI Example
Hello all, Does anyone know where one might find an example project of using MFC/OSG/SDI? If anyone has one sitting around on their machine I would be interested if you can email it to me as well. I've already tried adapting the MFC MDI example to an SDI project but I seem to be hitting some snags where the app won't exit properly. It either asserts the window as being still valid when it shouldn't be [CWnd::WalkPreTranslateTree's ASSERT(hWndStop == NULL || ::IsWindow(hWndStop))] or it get's The activation context being deactivated is not the most recently activated one exception within osg53-osgGAd.dll after I've deleted all osg items. I'm a little bit baffled why I'm getting this. Anyway does anyone have any SDI examples? Thanks -Brad ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] MFC SDI Example
Umit, Thanks. The SDI application that I have created so far is very simple and does nothing more than what the MDI example app does. As far as I can tell there is no difference in the way the example creates/uses/deletes the cOSG object and the way I am doing it, yet I get assertions or exceptions on exit. Anyone else? Thanks -Brad From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Ümit Uzun Sent: Thursday, January 08, 2009 2:08 PM To: OpenSceneGraph Users Subject: Re: [osg-users] MFC SDI Example Hi Brad, I created SDI MFC project in OSG. But this was commercial and complicated to understand you very well. Because it was SDI dll to call from anywhere you need and you then delete it if you don't need to much. I haven't understood the assertion faults very well but you should only understand the cOSG class creation style. You will use it in your SDI project and be careful to delete everything while you are destroying your dialog. And be careful about the threads sleeping time to be activeted. Because sometimes sleeping times can't be enough to be threads get activated, so it may create assertion fault as you say. Hope this helps. Regards. 2009/1/8 Brad Huber br...@procerusuav.com Hello all, Does anyone know where one might find an example project of using MFC/OSG/SDI? If anyone has one sitting around on their machine I would be interested if you can email it to me as well. I've already tried adapting the MFC MDI example to an SDI project but I seem to be hitting some snags where the app won't exit properly. It either asserts the window as being still valid when it shouldn't be [CWnd::WalkPreTranslateTree's ASSERT(hWndStop == NULL || ::IsWindow(hWndStop))] or it get's The activation context being deactivated is not the most recently activated one exception within osg53-osgGAd.dll after I've deleted all osg items. I'm a little bit baffled why I'm getting this. Anyway does anyone have any SDI examples? Thanks -Brad ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- Ümit Uzun ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] VirtualPlanetBuilder: Adding to an existing database
My coworker recently posted a similar question but I haven't seen any response yet. We are interested in whether you could have a whole planet database (perhaps earth.ive?) and add imagery to it. As in generate the scene graph for the whole world once. Then later come and add high resolution insets of particular areas without having to do a complete rebuild. Thoughts? Thanks -Brad ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
