Let me ask a slightly different question... Why do I only get half a cow (see attachment on my original post) even when I run on just a local machine. Seems I get more "cow" showing when I decrease the resolution of my video display...
Paul P. ----- Original Message ---- From: "[email protected]" <[email protected]> To: OpenSceneGraph Users <[email protected]> Sent: Friday, May 22, 2009 8:03:36 AM Subject: Re: [osg-users] Remote execution and OSG Let me also add that I see the same problem (program seg faults when running on a LINUX machine and shooting the display to a PC using Hummingbird Exceed 3D) when running: % osgviewerQT --QOSGWidget cow.osg with OSG 2.9.3 and 2.8. It also produces the following X error: X Error: BadMatch (invalid parameter attributes) 8 Extension: 134 (Uknown extension) Minor opcode: 5 (Unknown request) Resource id: 0x2c00001 In addition, when I run this command on a (single) LINUX machine, I only get half a cow... Is this a problem with OSG or is this an Exceed 3D problem? I know another person recently resolved a crash on the same example by updating the video driver. I assume this isn't my problem here. Paul P. ----- Original Message ---- From: "[email protected]" <[email protected]> To: OpenSceneGraph Users <[email protected]> Sent: Thursday, May 21, 2009 7:17:36 PM Subject: Re: [osg-users] Remote execution and OSG Thanks Robert.. That helped... But I'm having way too much fun interfacing OSG to Qt to stop there:-). I seem to be able to get it to work now but I'm having trouble running on a LINUX machine but shooting my display to a PC running Hummingbird Exceed 3D (my actual requirement). I'm logged into the PC and then use exceed to remotely login to a LINUX machine. I seem to have trouble switching to a valid Graphics Context (i.e. glGetString(GL_VERSION) returns null string within OSG) and causes OSG to seg fault... Logging remotely into a LINUX machine and shooting the display to another LINUX machine works fine. Am I setting up my graphics context incorrectly? I'm not using the AdapterWidget from the example. I'm also having trouble getting GraphicsWindowEmbedded to work... So, here is what I'm doing: myViewer::myViewer(void) { mViewer = new osgViewer::Viewer; mViewer->setThreadingModel(osgViewer::Viewer::SingleThreaded); mViewer->setCameraManipulator(new osgGA::TrackballManipulator); mCamera = mViewer->getCamera(); } void myViewer::initialize(int height, int width) { osg::ref_ptr<osg::GraphicsContext::Traits> traits = new osg::GraphicsContext::Traits; traits->readDISPLAY(); traits->doubleBuffer = true; traits->useCursor = false; traits->x = 0; traits->y = 0; traits->width = width; traits->height = height; osg::ref_ptr<osg::Referenced> windata = new osgViewer::GraphicsWindowX11::WindowData(mGLWindow); traits->inheritedWindowData = windata; osg::GraphicsContext* gc; gc = osg::GraphicsContext::createGraphicsContext(traits.get()); mCamera->setGraphicsContext(gc); mCamera->setClearColor(osg::Vec4(0.5235, 0.8745, 1.0, 1.0)); mCamera->setViewport(traits->x, traits->y, traits->width, traits->height); mViewer->setCamera(mCamera.get()); mViewer->setSceneData(osgDB::readNodeFile("cow.osg")); } I am calling the myViewer->initialize() method in another class derived from a QGLWidget and where it is called in its first paintGL callback. I'm also calling the myViewer->frame() call in this callback which simply calls mViewer->frame(). I'm using Qt's QGLWidget's window ID (i.e. winId() stored in mGLWindow) to set the inheritedWindowData. Is this okay to do it? If I don't do this initialization of the inheritedWindowData data, my widget DOES appear (in all cases) except it is detached from my Qt application. I'm not sure if this is my programming problem, an Hummingbird Exceed problem or a Qt problem. Can anybody help? I've been working on this for weeks... Thanks, Paul P. ----- Original Message ---- From: Robert Osfield <[email protected]> To: OpenSceneGraph Users <[email protected]> Sent: Friday, May 15, 2009 4:24:08 AM Subject: Re: [osg-users] Remote execution and OSG HI Paul, J.P, et. al, On Fri, May 15, 2009 at 8:56 AM, J.P. Delport <[email protected]> wrote: > Not sure, but it looks like some code ignores the $DISPLAY setting and just > tries to open :0.0. > > I can confirm that I get the same behaviour between two Debian machines: > osgviewer cow.osg runs at a staggering 2fps > > osgkeyboardmouse fails with: > No protocol specified > Error: Unable to open display ":0.0". > Error: unable to create graphics window. The GraphicsContext::Traits structure is used to control how the graphics window is created, and in it's default state the display and screen settings (see osg::GraphicsContext::ScreenIndentifier) are 0:0. To override this default one needs to explictly call readDISPLAY() which reads the DISPLAY env variable to set the display and screen number. Now the osgView::setUpView*() methods all call readDISPLAY(), but if the example does use on of these methods, and instead creates the GraphicsWindow it requires directly use GraphicsContext::Traits without calling the readDISPLAY then it won't pick up your settings of this variable, so you'll get different behavior. Robert. _______________________________________________ osg-users mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org _______________________________________________ osg-users mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org _______________________________________________ osg-users mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
