Re: [osg-users] deadlock loading io plugin?
Hi Robert, yes, that modified PThread.c++ seems to work for me without having to put the init into my main. Thanks for the help! Bye, max On Tue, Nov 4, 2008 at 3:48 PM, Robert Osfield <[EMAIL PROTECTED]> wrote: > On Tue, Nov 4, 2008 at 2:06 PM, Max Pfingsthorn > <[EMAIL PROTECTED]> wrote: >> Hi Robert, >> >> On Tue, Nov 4, 2008 at 2:36 PM, Robert Osfield <[EMAIL PROTECTED]> wrote: >>> Could you try adding a: >>> >>>Thread::Init(); >>> >>> To the start of your main and see if that makes a difference. >> >> Yes, that did it. Before, OSG 2.6.1 and 2.5.5 finished compiling and >> *both* worked without OpenThreads::Thread::init(); in my main. That >> seems weird.. Did something change for 2.7 in terms of OpenThreads? > > There haven't been any significant changes to OpenThreads, just > changes to Atmic codes but I wouldn't have thought this would cause > problems. > > Did you try my modified Thread.c++? If this works then I'll check it in. > > 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] deadlock loading io plugin?
Hi Robert, On Tue, Nov 4, 2008 at 2:36 PM, Robert Osfield <[EMAIL PROTECTED]> wrote: > Could you try adding a: > >Thread::Init(); > > To the start of your main and see if that makes a difference. Yes, that did it. Before, OSG 2.6.1 and 2.5.5 finished compiling and *both* worked without OpenThreads::Thread::init(); in my main. That seems weird.. Did something change for 2.7 in terms of OpenThreads? Cheers, max ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] deadlock loading io plugin?
Hi Robert, On Tue, Nov 4, 2008 at 1:40 PM, Robert Osfield <[EMAIL PROTECTED]> wrote: > As another datapoint for your testing - I modified my > Thread::CurrentThread method to return 0 and the test code worked > without deadlocks. Hmm, ok. Thanks. I noticed that with the Ubuntu OSG package, CurrentThread is non-zero only after readNodeFiles was called, not before. This is different to your output, which was always non-zero. Can or should I somehow initialize OpenThreads? > Do you have any other machines that you could try? Unfortunately, I don't. I could try my PowerBook G4, but I can't get OpenSceneGraph to compile there yet, some missing dependencies I think. I am trying the 2.6.1 and 2.5.5 tags on my Ubuntu machine to see if using those versions makes any difference. They are still compiling... Cheers, max ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] deadlock loading io plugin?
Hi Robert, On Tue, Nov 4, 2008 at 12:01 PM, Robert Osfield <[EMAIL PROTECTED]> wrote: > Which version of the OSG do find problems with? What is the exact > machine/OS combination are you using? I am using OSG trunk (2.7.5) from this morning on Ubuntu 8.04 32bit. The machine is a Intel Pentium D 2.8GHz (basically 2 Pentium 4s on one dice). Compiler is GCC 4.2.4. > As an experiment could you modify the ReentrantMutext() so that the > _threadHoldingMutex member variable is set to something like > 0x. I'll try that and report back soon. I'll also try the Ubuntu OSG package (to make sure its not something with my pthread library). Bye, max ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] deadlock loading io plugin?
Hi Robert, On Tue, Nov 4, 2008 at 10:58 AM, Robert Osfield <[EMAIL PROTECTED]> wrote: >> Any further ideas? I'm pretty sure I'm doing something wrong because >> osgviewer works. > > It might be a long shot, but my only idea right now is that perhaps > the main thread for OpenThreads::Thread::CurrentThread() is returning > 0 one time then another value later on. > > Could you print out the value of OpenThreads::Thread::CurrentThread > as the first thing in your main then after any other operation to see > if it's value does change. As long as the program doesn't hang, it always returns 0. I print it as the very first thing, parse the arguments, print it again, the try to readNodeFiles(arguments), which hangs. -- int main(int argc, char** argv) { cout << "OpenThreads::CurrentThread: " << OpenThreads::Thread::CurrentThread() << endl; osg::ArgumentParser arguments(&argc,argv); cout << "start!" << endl; cout << "OpenThreads::CurrentThread: " << OpenThreads::Thread::CurrentThread() << endl; osg::ref_ptr loadedModel = osgDB::readNodeFiles(arguments); cout << "OpenThreads::CurrentThread: " << OpenThreads::Thread::CurrentThread() << endl; -- The first two show 0, the third print is never reached. The weird thing is, if I install OSG from the Ubuntu repos (2.4), it works just fine. I tried it at home. Cheers, max ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Computing bullet collision models from .3ds files
Hi, there is the Physics Abstraction Library (http://www.adrianboeing.com/pal/index.html , http://pal.sourceforge.net). I'm not sure to what extend that is useful, but it seems to be rather popular. It already abstracts ODE, Bullet, and other, even commercial, engines. Possibly worth a look. I actually plan to use OSG (or Ogre3D, the jury is still out) with PAL for a robotics simulator, which might become the successor of USARSim (http://usarsim.sourceforge.net). Some more direct integration between OSG and some physics abstraction (PAL or homegrown) would be great! Cheers, max On Tue, Nov 4, 2008 at 10:27 AM, Robert Osfield <[EMAIL PROTECTED]> wrote: > Hi Guys, > > It's good to see a number of different users popping with discussion > of their own work on integrating physics with the OSG. I would be > great to have an OSG NodeKit for doing physics, but I'm very wary of > tying to one specific engine as each engine has it's own strengths and > weakness, and I also don't want to steer people away from making > particular physics engine choices including closed source ones - such > as Vortex, users should be able to integrate the best tool for they > job they can afford. > > So I'd like to punt the possibility of having some kind of base > osgPhyics API that makes it easier to bolt on different physics > engines onto the OSG. This would require spotting the commonality > between the different engines and distilling this, for instance the > osgViewer library does this trick to a certain extent with the > different GraphicsWindow implementations. You also don't want to hide > too much of the implementation advanced phyics engine tuning will > probably require users to grapple with the lower level physics engines > settings. While abstracting completely is impracticable it'd be good > to provide the template for the concrete implementations, and also > make it easier for applications to move between different physic > engines at the backend. > > Is such a lib possible or practical? It'll be more wore initially > than just an osgODE, osgBullet or osgVortex library but longer term it > could reduce the cost of maintenance of all these different > variations. The first step in this direction would be to see the > code of various physic engine + OSG integration with a view to > spotting the commonality between them. > > Thoughts? > 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] deadlock loading io plugin?
Hello everyone, I've checked out OSG again, rebuilt it completely with debugging symbols. I checked with ldd which libraries are linked to, and they are the correct ones. First I thought this happened because I still had an old OpenThreads library lying around (from the ubuntu repos), but now that it links with the proper library it still doesn't work. osgviewer(d) still works. Here is some more output that might be interesting: ldd on my executable: linux-gate.so.1 => (0xb7f3d000) libosgd.so.50 => /usr/local/OpenSceneGraph/lib/libosgd.so.50 (0xb7b35000) libosgDBd.so.50 => /usr/local/OpenSceneGraph/lib/libosgDBd.so.50 (0xb7a28000) libosgFXd.so.50 => /usr/local/OpenSceneGraph/lib/libosgFXd.so.50 (0xb79d6000) libosgGAd.so.50 => /usr/local/OpenSceneGraph/lib/libosgGAd.so.50 (0xb7972000) libosgParticled.so.50 => /usr/local/OpenSceneGraph/lib/libosgParticled.so.50 (0xb78e5000) libosgSimd.so.50 => /usr/local/OpenSceneGraph/lib/libosgSimd.so.50 (0xb778c000) libosgTextd.so.50 => /usr/local/OpenSceneGraph/lib/libosgTextd.so.50 (0xb76cb000) libosgUtild.so.50 => /usr/local/OpenSceneGraph/lib/libosgUtild.so.50 (0xb735c000) libosgTerraind.so.50 => /usr/local/OpenSceneGraph/lib/libosgTerraind.so.50 (0xb72f4000) libosgManipulatord.so.50 => /usr/local/OpenSceneGraph/lib/libosgManipulatord.so.50 (0xb727f000) libosgViewerd.so.50 => /usr/local/OpenSceneGraph/lib/libosgViewerd.so.50 (0xb7159000) libosgWidgetd.so.50 => /usr/local/OpenSceneGraph/lib/libosgWidgetd.so.50 (0xb70d) libOpenThreadsd.so.11 => /usr/local/OpenSceneGraph/lib/libOpenThreadsd.so.11 (0xb70c7000) libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0xb6fbf000) libm.so.6 => /lib/tls/i686/cmov/libm.so.6 (0xb6f9a000) libgcc_s.so.1 => /lib/libgcc_s.so.1 (0xb6f8f000) libc.so.6 => /lib/tls/i686/cmov/libc.so.6 (0xb6e3f000) libpthread.so.0 => /lib/tls/i686/cmov/libpthread.so.0 (0xb6e27000) libGLU.so.1 => /usr/lib/libGLU.so.1 (0xb6da4000) libGL.so.1 => /usr/lib/libGL.so.1 (0xb6d42000) libSM.so.6 => /usr/lib/libSM.so.6 (0xb6d3a000) libICE.so.6 => /usr/lib/libICE.so.6 (0xb6d22000) libX11.so.6 => /usr/lib/libX11.so.6 (0xb6c3b000) libXext.so.6 => /usr/lib/libXext.so.6 (0xb6c2c000) /lib/ld-linux.so.2 (0xb7f3e000) libXxf86vm.so.1 => /usr/lib/libXxf86vm.so.1 (0xb6c27000) libXdamage.so.1 => /usr/lib/libXdamage.so.1 (0xb6c24000) libXfixes.so.3 => /usr/lib/libXfixes.so.3 (0xb6c1e000) libdl.so.2 => /lib/tls/i686/cmov/libdl.so.2 (0xb6c1a000) libdrm.so.2 => /usr/lib/libdrm.so.2 (0xb6c1) libxcb-xlib.so.0 => /usr/lib/libxcb-xlib.so.0 (0xb6c0e000) libxcb.so.1 => /usr/lib/libxcb.so.1 (0xb6bf6000) libXau.so.6 => /usr/lib/libXau.so.6 (0xb6bf2000) libXdmcp.so.6 => /usr/lib/libXdmcp.so.6 (0xb6bed000) GDB backtrace: (gdb) bt #0 0xb7f20410 in __kernel_vsyscall () #1 0xb6e16589 in __lll_lock_wait () from /lib/tls/i686/cmov/libpthread.so.0 #2 0xb6e11ba6 in _L_lock_95 () from /lib/tls/i686/cmov/libpthread.so.0 #3 0xb6e1158a in pthread_mutex_lock () from /lib/tls/i686/cmov/libpthread.so.0 #4 0xb6f05ea6 in pthread_mutex_lock () from /lib/tls/i686/cmov/libc.so.6 #5 0xb70afb79 in OpenThreads::Mutex::lock (this=0x805e690) at /home/max/svn/osg/src/OpenThreads/pthreads/PThreadMutex.c++:122 #6 0xb7dac795 in OpenThreads::ReentrantMutex::lock (this=0x805e690) at /home/max/svn/osg/include/OpenThreads/ReentrantMutex:43 #7 0xb7ae03d2 in ScopedLock (this=0xbff2715c, [EMAIL PROTECTED]) at /home/max/svn/osg/include/OpenThreads/ScopedLock:31 #8 0xb7ad03a0 in osgDB::Registry::addReaderWriter (this=0x805e5a8, rw=0x80606e8) at /home/max/svn/osg/src/osgDB/Registry.cpp:539 #9 0xb6b95f0c in RegisterReaderWriterProxy (this=0xb6bcdab8) at /home/max/svn/osg/include/osgDB/Registry:668 #10 0xb6b8ebb4 in __static_initialization_and_destruction_0 (__initialize_p=1, __priority=65535) at /home/max/svn/osg/src/osgPlugins/OpenFlight/ReaderWriterFLT.cpp:510 #11 0xb6b8ebf4 in global constructors keyed to osgdb_OpenFlight () at /home/max/svn/osg/src/osgPlugins/OpenFlight/ReaderWriterFLT.cpp:511 #12 0xb6ba8165 in __do_global_ctors_aux () from /usr/local/OpenSceneGraph/lib/osgPlugins-2.7.5/osgdb_openflightd.so #13 0xb6b2d524 in _init () from /usr/local/OpenSceneGraph/lib/osgPlugins-2.7.5/osgdb_openflightd.so #14 0xb7f2e990 in ?? () from /lib/ld-linux.so.2 #15 0xb7f2eac3 in ?? () from /lib/ld-linux.so.2 #16 0xb7f32774 in ?? () from /lib/ld-linux.so.2 #17 0xb7f2e5c6 in ?? () from /lib/ld-linux.so.2 #18 0xb7f31f4e in ?? () from /lib/ld-linux.so.2 #19 0xb6bfe98d in ?? () from /lib/tls/i686/cmov/libdl.so.2 #20 0xb7f2e5c6 in ?? () from /lib/ld-linux.so.2 #21 0xb6bfe2bc in ?? () from /lib/tls/i686/cmov/libdl.so.2 #22 0xb6bfea0f in dlopen () from /lib/tls/i686/cmov/libdl.so.2 #23 0xb7aadb13 in osgDB::DynamicLibrary::getLibraryHandle ([EMAIL PR
Re: [osg-users] deadlock loading io plugin?
Hi Robert, no, it doesn't seem so. The osgviewer works fine. I did a clean build just before. There is only one thread says "info threads"... I'm stumped. Seems only to happen on apps I compile seperately. Cheers, max Robert Osfield wrote: > Hi Max, > > Do the osg examples fail in a similar way? > > Could you do a clean build of the OSG and your app and try again? > > Robert. > > On Mon, Nov 3, 2008 at 4:08 PM, Max Pfingsthorn > <[EMAIL PROTECTED]> wrote: >> Dear list, >> >> I have a very simple program such as this: >> >> int main(int argc, char** argv) { >>osg::ArgumentParser arguments(&argc,argv); >>cout << "start!" << endl; >> >>osg::ref_ptr loadedModel = osgDB::readNodeFiles(arguments); >> >>if (!loadedModel) >>{ >>cout << argv[0] <<": No data loaded" << endl; >>return 1; >>} >> >>cout << "loaded" << endl; >> } >> >> I'm using the current trunk of OSG (updated 30 mins ago) on Ubuntu >> 8.04. The program hangs on the line with osgDB::readNodeFiles. I have >> no idea why. >> >> This is what GDB says: >> >> #0 0xb7fc8410 in __kernel_vsyscall () >> #1 0xb75c4589 in __lll_lock_wait () from /lib/tls/i686/cmov/libpthread.so.0 >> #2 0xb75bfba6 in _L_lock_95 () from /lib/tls/i686/cmov/libpthread.so.0 >> #3 0xb75bf58a in pthread_mutex_lock () from >> /lib/tls/i686/cmov/libpthread.so.0 >> #4 0xb76b3ea6 in pthread_mutex_lock () from /lib/tls/i686/cmov/libc.so.6 >> #5 0xb785ce43 in OpenThreads::Mutex::lock () from >> /usr/local/OpenSceneGraph/lib/libOpenThreads.so.11 >> #6 0xb7ea30c1 in OpenThreads::ReentrantMutex::lock () from >> /usr/local/OpenSceneGraph/lib/libosg.so.50 >> #7 0xb7d4bcbc in osgDB::Registry::addReaderWriter () from >> /usr/local/OpenSceneGraph/lib/libosgDB.so.50 >> #8 0xb7350e0e in __static_initialization_and_destruction_0 () from >> /usr/local/OpenSceneGraph/lib/osgPlugins-2.7.5/osgdb_openflight.so >> #9 0xb7364325 in __do_global_ctors_aux () from >> /usr/local/OpenSceneGraph/lib/osgPlugins-2.7.5/osgdb_openflight.so >> #10 0xb730bb50 in _init () from >> /usr/local/OpenSceneGraph/lib/osgPlugins-2.7.5/osgdb_openflight.so >> #11 0xb7fd6990 in ?? () from /lib/ld-linux.so.2 >> #12 0xb7fd6ac3 in ?? () from /lib/ld-linux.so.2 >> #13 0xb7fda774 in ?? () from /lib/ld-linux.so.2 >> #14 0xb7fd65c6 in ?? () from /lib/ld-linux.so.2 >> #15 0xb7fd9f4e in ?? () from /lib/ld-linux.so.2 >> #16 0xb73ac98d in ?? () from /lib/tls/i686/cmov/libdl.so.2 >> #17 0xb7fd65c6 in ?? () from /lib/ld-linux.so.2 >> #18 0xb73ac2bc in ?? () from /lib/tls/i686/cmov/libdl.so.2 >> #19 0xb73aca0f in dlopen () from /lib/tls/i686/cmov/libdl.so.2 >> #20 0xb7d26005 in osgDB::DynamicLibrary::getLibraryHandle () from >> /usr/local/OpenSceneGraph/lib/libosgDB.so.50 >> #21 0xb7d262a9 in osgDB::DynamicLibrary::loadLibrary () from >> /usr/local/OpenSceneGraph/lib/libosgDB.so.50 >> #22 0xb7d4875c in osgDB::Registry::loadLibrary () from >> /usr/local/OpenSceneGraph/lib/libosgDB.so.50 >> #23 0xb7d57b25 in osgDB::Registry::read () from >> /usr/local/OpenSceneGraph/lib/libosgDB.so.50 >> #24 0xb7d58d35 in osgDB::Registry::readImplementation () from >> /usr/local/OpenSceneGraph/lib/libosgDB.so.50 >> #25 0xb7d594b4 in osgDB::Registry::readNodeImplementation () from >> /usr/local/OpenSceneGraph/lib/libosgDB.so.50 >> #26 0xb7d44fed in osgDB::readNodeFile () from >> /usr/local/OpenSceneGraph/lib/libosgDB.so.50 >> #27 0xb7d46651 in osgDB::readNodeFiles () from >> /usr/local/OpenSceneGraph/lib/libosgDB.so.50 >> #28 0x080511ab in osgDB::readNodeFiles ([EMAIL PROTECTED]) at >> /usr/local/OpenSceneGraph/include/osgDB/ReadFile:132 >> #29 0x08050df8 in main (argc=2, argv=0xbfc260e4) at src/main.cc:30 >> >> This looks like there is a deadlock somewhere, otherwise >> pthread_mutex_lock() wouldn't block. The same happens with cessna.osg >> file from the sample files, however frames 8-10 are in osgdb_osg.so, >> of course. Any ideas? I've already rebuilt OSG once, no luck. >> >> Thank you! >> max >> ___ >> 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] deadlock loading io plugin?
Dear list, I have a very simple program such as this: int main(int argc, char** argv) { osg::ArgumentParser arguments(&argc,argv); cout << "start!" << endl; osg::ref_ptr loadedModel = osgDB::readNodeFiles(arguments); if (!loadedModel) { cout << argv[0] <<": No data loaded" << endl; return 1; } cout << "loaded" << endl; } I'm using the current trunk of OSG (updated 30 mins ago) on Ubuntu 8.04. The program hangs on the line with osgDB::readNodeFiles. I have no idea why. This is what GDB says: #0 0xb7fc8410 in __kernel_vsyscall () #1 0xb75c4589 in __lll_lock_wait () from /lib/tls/i686/cmov/libpthread.so.0 #2 0xb75bfba6 in _L_lock_95 () from /lib/tls/i686/cmov/libpthread.so.0 #3 0xb75bf58a in pthread_mutex_lock () from /lib/tls/i686/cmov/libpthread.so.0 #4 0xb76b3ea6 in pthread_mutex_lock () from /lib/tls/i686/cmov/libc.so.6 #5 0xb785ce43 in OpenThreads::Mutex::lock () from /usr/local/OpenSceneGraph/lib/libOpenThreads.so.11 #6 0xb7ea30c1 in OpenThreads::ReentrantMutex::lock () from /usr/local/OpenSceneGraph/lib/libosg.so.50 #7 0xb7d4bcbc in osgDB::Registry::addReaderWriter () from /usr/local/OpenSceneGraph/lib/libosgDB.so.50 #8 0xb7350e0e in __static_initialization_and_destruction_0 () from /usr/local/OpenSceneGraph/lib/osgPlugins-2.7.5/osgdb_openflight.so #9 0xb7364325 in __do_global_ctors_aux () from /usr/local/OpenSceneGraph/lib/osgPlugins-2.7.5/osgdb_openflight.so #10 0xb730bb50 in _init () from /usr/local/OpenSceneGraph/lib/osgPlugins-2.7.5/osgdb_openflight.so #11 0xb7fd6990 in ?? () from /lib/ld-linux.so.2 #12 0xb7fd6ac3 in ?? () from /lib/ld-linux.so.2 #13 0xb7fda774 in ?? () from /lib/ld-linux.so.2 #14 0xb7fd65c6 in ?? () from /lib/ld-linux.so.2 #15 0xb7fd9f4e in ?? () from /lib/ld-linux.so.2 #16 0xb73ac98d in ?? () from /lib/tls/i686/cmov/libdl.so.2 #17 0xb7fd65c6 in ?? () from /lib/ld-linux.so.2 #18 0xb73ac2bc in ?? () from /lib/tls/i686/cmov/libdl.so.2 #19 0xb73aca0f in dlopen () from /lib/tls/i686/cmov/libdl.so.2 #20 0xb7d26005 in osgDB::DynamicLibrary::getLibraryHandle () from /usr/local/OpenSceneGraph/lib/libosgDB.so.50 #21 0xb7d262a9 in osgDB::DynamicLibrary::loadLibrary () from /usr/local/OpenSceneGraph/lib/libosgDB.so.50 #22 0xb7d4875c in osgDB::Registry::loadLibrary () from /usr/local/OpenSceneGraph/lib/libosgDB.so.50 #23 0xb7d57b25 in osgDB::Registry::read () from /usr/local/OpenSceneGraph/lib/libosgDB.so.50 #24 0xb7d58d35 in osgDB::Registry::readImplementation () from /usr/local/OpenSceneGraph/lib/libosgDB.so.50 #25 0xb7d594b4 in osgDB::Registry::readNodeImplementation () from /usr/local/OpenSceneGraph/lib/libosgDB.so.50 #26 0xb7d44fed in osgDB::readNodeFile () from /usr/local/OpenSceneGraph/lib/libosgDB.so.50 #27 0xb7d46651 in osgDB::readNodeFiles () from /usr/local/OpenSceneGraph/lib/libosgDB.so.50 #28 0x080511ab in osgDB::readNodeFiles ([EMAIL PROTECTED]) at /usr/local/OpenSceneGraph/include/osgDB/ReadFile:132 #29 0x08050df8 in main (argc=2, argv=0xbfc260e4) at src/main.cc:30 This looks like there is a deadlock somewhere, otherwise pthread_mutex_lock() wouldn't block. The same happens with cessna.osg file from the sample files, however frames 8-10 are in osgdb_osg.so, of course. Any ideas? I've already rebuilt OSG once, no luck. Thank you! max ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Qt 3 problems
Dear all, I have a problem constructing the QOSGWidget from osgviewerQT as a child widget. I'm using Qt 3.3 on Ubuntu 8.04 and OSG trunk. I get the following error: X Error: BadWindow (invalid Window parameter) 3 Major opcode: 3 Minor opcode: 0 Resource id: 0x368 X Error: BadWindow (invalid Window parameter) 3 Major opcode: 18 Minor opcode: 0 Resource id: 0x368 X Error: BadWindow (invalid Window parameter) 3 Major opcode: 18 Minor opcode: 0 Resource id: 0x368 While the window shows up properly, it seems the geometry is rendered on a one pixel wide strip in the middle instead of using the whole width. The same happens with Ubuntu's OSG package, which is 2.4. If I run the QOSGWidget as a top level widget, it works just fine. Any ideas? Cheers, Max Pfingsthorn ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] rendering very simple point cloud
Dear List, I want to render a point cloud (say from a 3D scanner). I use the following code: (pc is a PointCloud which contains three vectors of floats, aScene is a osg::Group) --- osg::PositionAttitudeTransform* trans = new osg::PositionAttitudeTransform(); osg::Geometry* geo = new osg::Geometry; osg::Geode* node = new osg::Geode; node->addDrawable( geo ); trans->addChild( node ); trans->setPosition( osg::Vec3d( x, y, z ) ); trans->setAttitude( osg::Quat( yaw, osg::Vec3d(0,0,1), pitch, osg::Vec3d(0,1,0), roll, osg::Vec3d(1,0,0) ) ); const vector& vx = pc.getX(); const vector& vy = pc.getY(); const vector& vz = pc.getZ(); osg::Vec3Array* points = new osg::Vec3Array; for( unsigned int i=0; i < vx.size(); i++ ) { points->push_back( osg::Vec3( vx[i], vy[i], vz[i] ) ); } geo->setVertexArray( points ); osg::DrawElementsUInt* draw = new osg::DrawElementsUInt(osg::PrimitiveSet::POINTS, 0); for( unsigned int i=0; i < vx.size(); i++ ) { draw->push_back( i ); } geo->addPrimitiveSet( draw ); osg::Vec4Array* colors = new osg::Vec4Array; colors->push_back(osg::Vec4(1.0f, 1.0f, 1.0f, 1.0f) ); geo->setColorArray(colors); geo->setColorBinding(osg::Geometry::BIND_OVERALL); aScene->addChild( trans ); --- It works, but for some reason, the points seem to be less visible from some directions than from others (i.e. I see them from the front but not from the back). Is this by design? How do I make sure the points can be seen from all sides? Thanks for the help! Max Pfingsthorn ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] trunk missing a directory (rev. 9019)
Hello list, dear Robert, I've just checked out the trunk and cmake complains. Looking at the latest changeset, you seem to have forgotten to svn add the "gz" subdirectory of src/osgPlugins/. It's referenced in the CMakeLists.txt but it's not on the svn. Cheers, Max ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Displaying a scene in the background of a QGraphicsView
Hello Robert, Thank you very much for your reply. My thoughts exactly. But how do I save and restore the opengl state in its entirety? I tried pushing/popping the modelview, projection and even the texture matrices around calling viewer->frame(). I also explicitly glGet'ed them and loaded them again after OSG was done in case push/pops were not matched properly inside OSG. What else is there to save in the opengl state? Best regards, Max Pfingsthorn On 5 Sep 2008, at 17:40, "Robert Osfield" <[EMAIL PROTECTED]> wrote: Hi Max, My guess is that Qt is changing OpenGL state which is not being protected, and then you are mixing this with the OSG which assumes that it has complete control over OpenGL state so gets messed up by the QT changes to state, and also Qt OpenGL code is likely to be messed up by the OSG changing state. I don't know enough about the Qt's implementation here to really provide my insight. Personally I'd rather keep Qt doing Windowing and the OSG doing OpenGL. If you want to mix things then you'll need to start playing games with push and popping OpenGL state when entering the Qt OpenGl code path, and also resetting OpenGL state after leaving the OSG section. Robert. On Fri, Sep 5, 2008 at 4:16 PM, Max Pfingsthorn <[EMAIL PROTECTED]> wrote: Dear users, this problem has been with me for a while. I've even tried it with other graphics engines (Ogre) to no avail. As shown in this toy project at Trolltech Labs http://labs.trolltech.com/blogs/2008/06/27/accelerate-your-widgets-with-opengl/ I would like to show a scene in the background of a QGraphicsView and I was very happy that the ViewerQT class already was a QGLWidget. However, there seems to be something scaled wrong after I call viewer->frame (). Attached are a few screenshots and the code I have so far. I'm currently running Ubuntu 8.04.1 and I'm using the OSG 2.2 binaries that came with it. Beware that you need at least Qt 4.4 to compile this code. qt-osg-1.png and -2.png show how far I am at the moment. Number 2 shows the problem with scaling the window. OSG shows the scene fine in the background, but the widget I'd like to overlay is stretched. I believe the OpenGL version of QPainter draws in some normalized coordinates and the bounding box isn't properly updated. qt-osg-ok-1.png and -2.png show the same window sizes without calling viewer->frame(), and the scaling of the widget is ok. Just no scene in the background of course. I've traced the problem to osgViewer::Renderer::cull_draw(). I believe, when the geometry of the view is set, something makes Qt stop drawing correctly. In the function which calls viewer->frame() (in osgGraphicsView::drawBackground), I thought I save any sort of relevant OpenGL state, the projection matrix, model/view matrix, and even the texture matrix. After the call the viewer->frame(), I restore them again. Is there any other state that I might have overlooked which is set in the renderer? Also, do you have any idea why the Qt widget is not drawn entirely sometimes? Could it have something do to with buffer swaps? Thank you all for your help in advance! Best regards, Max Pfingsthorn ___ 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