Re: [osg-users] deadlock loading io plugin?

2008-11-04 Thread Max Pfingsthorn
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?

2008-11-04 Thread Max Pfingsthorn
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?

2008-11-04 Thread Max Pfingsthorn
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?

2008-11-04 Thread Max Pfingsthorn
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?

2008-11-04 Thread Max Pfingsthorn
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

2008-11-04 Thread Max Pfingsthorn
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?

2008-11-04 Thread Max Pfingsthorn
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?

2008-11-03 Thread Max Pfingsthorn
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?

2008-11-03 Thread Max Pfingsthorn
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

2008-10-24 Thread Max Pfingsthorn
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

2008-10-20 Thread Max Pfingsthorn
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)

2008-10-09 Thread Max Pfingsthorn
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

2008-09-05 Thread Max Pfingsthorn

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