Re: [osg-users] running vrml plugin on 2.0
Hi Jan, On 8/16/07, Jan Ciger [EMAIL PROTECTED] wrote: Robert, I think that there may be indeed some threading bug in the osgViewer. I have tested the files from Joan and if I view them using osgViewer, it starts up (no black screen) but hangs right away after displaying the first few frames or when I try to move the camera. This happens for all of the models here. What threading model is being used? Which version of the OSG? Try forcing different threading models by using the OSG_THREADING env var, or setting it on the command line. See osgviewer --help and osgviewer --help-env for details. If I do the same with osgproducerviewer, everything works and I am getting decent frame rates even - few hundreds FPS, even up to 1000 sometimes on my two 6800GS. The models are not that big, the largest has 117693 polygons and I am still getting 1000+ FPS with it with Producer. I have also checked the data files and the VRML files contain several meshes, few thousands triangles/quads each. Nothing extraordinary. I have experienced the hangs with osgViewer in our own application recently as well, but I couldn't reproduce them with the plain osgviewer binary, so I have ascribed it to some race condition in my code. Now these datafiles trigger it with plain viewer 100% each time on my PC. I am running a dual core Athlon (SMP machine) and the cards are configured using SLI, alternative frame rendering (AFR). Do the hangs always happen at start up? Or any point during rendering? If you could provide a datasets then I could try it out on my system. I have a dual core Althon system and a new quad core Intel system, both right now just have a single card in but I can swap things around. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] running vrml plugin on 2.0
Hi Jan, Thanks for the stack traces, this gives us much more of an idea what might be up.These are just standard blocks/mutexes so not directly related to OpenGL, and also by the same token unlikely to be related directly to the model being rendered. The face that the hang happens in the same place for DrawThreadPerContext as well as CullThreadPerCameraDrawThreadPerContext is probably down to them being effectively the same thing when there is one one graphics camera. The nature of the lock suggests that the double buffering mechanism has got out of sequence in Renderer, if this just happened always on the first frame I'd suggest that this was an uninitialized variable problem, but the fact that it happens later suggests some else amiss in the mechanism. Since I can reproduce the problem CullThreadPerCameraDrawThreadPerContext on my quad core machine I will have a bash at fixing this and hope that the DrawThreadPerContext issue might drop out too, but first I 2.1.6 to do, some admin work, and some work for clients... Robert. On 8/19/07, Jan Ciger [EMAIL PROTECTED] wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello Robert, I have new information regarding the hangs. I have finally managed to get my gdb to produce a meaningful backtrace when the viewer hangs and this is the result. For DrawThreadPerContext, it is blocked at: Thread 1: #0 0xb7f507f2 in _dl_sysinfo_int80 () at rtld.c:788 #1 0xb7a83206 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/i686/libpthread.so.0 #2 0xb7ab50a8 in OpenThreads::Condition::wait (this=0x8128d88, mutex=0x8128d80) at /media/backup/osg/OpenSceneGraph/src/OpenThreads/pthreads/PThreadCondition.c++:130 #3 0xb7b3ac91 in osgViewer::Viewer::renderingTraversals (this=0xbfdb968c) at /media/backup/osg/OpenSceneGraph/include/OpenThreads/Block:133 #4 0xb7b3b9e3 in osgViewer::Viewer::frame (this=0xbfdb968c, simulationTime=1.7976931348623157e+308) at /media/backup/osg/OpenSceneGraph/src/osgViewer/Viewer.cpp:983 #5 0xb7b3bb3a in osgViewer::Viewer::run (this=0xbfdb968c) at /media/backup/osg/OpenSceneGraph/src/osgViewer/Viewer.cpp:195 #6 0x0804b069 in main (argc=Cannot access memory at address 0x0 ) at /media/backup/osg/OpenSceneGraph/applications/osgviewer/osgviewer.cpp:148 Thread 2: #0 0xb7f507f2 in _dl_sysinfo_int80 () at rtld.c:788 #1 0xb7a8591e in __lll_mutex_lock_wait () from /lib/i686/libpthread.so.0 #2 0xb7a8184e in _L_mutex_lock_80 () from /lib/i686/libpthread.so.0 #3 0xb7a8139d in pthread_mutex_lock () from /lib/i686/libpthread.so.0 #4 0xb7ab5273 in OpenThreads::Mutex::lock (this=0x8058f74) at /media/backup/osg/OpenSceneGraph/src/OpenThreads/pthreads/PThreadMutex.c++:122 #5 0xb7b1a52e in osgViewer::Renderer::draw (this=0x8058f20) at /media/backup/osg/OpenSceneGraph/include/OpenThreads/ScopedLock:31 #6 0xb7b1af58 in osgViewer::Renderer::operator() (this=0xfe00, context=0x812dd70) at /media/backup/osg/OpenSceneGraph/src/osgViewer/Renderer.cpp:548 #7 0xb7e4d45f in osg::GraphicsContext::runOperations (this=0x812dd70) at /media/backup/osg/OpenSceneGraph/src/osg/GraphicsContext.cpp:654 #8 0xb7e538dd in osg::RunOperations::operator() (this=0x8129278, context=0x812dd70) at /media/backup/osg/OpenSceneGraph/src/osg/GraphicsThread.cpp:134 #9 0xb7e53947 in osg::GraphicsOperation::operator() (this=0x8129278, object=0x812dd70) at /media/backup/osg/OpenSceneGraph/src/osg/GraphicsThread.cpp:50 #10 0xb7e7c627 in osg::OperationThread::run (this=0x8128f78) at /media/backup/osg/OpenSceneGraph/src/osg/OperationThread.cpp:413 #11 0xb7e53a89 in osg::GraphicsThread::run (this=0x8128f78) at /media/backup/osg/OpenSceneGraph/src/osg/GraphicsThread.cpp:38 #12 0xb7ab47e4 in OpenThreads::ThreadPrivateActions::StartThread (data=0x8128f88) at /media/backup/osg/OpenSceneGraph/src/OpenThreads/pthreads/PThread.c++:158 #13 0xb7a7f462 in start_thread () from /lib/i686/libpthread.so.0 #14 0xb769c82e in clone () from /lib/i686/libc.so.6 For CullThreaPerCameraDrawThreadPerContext I get the hang in: Thread 1: #0 0xb7f807f2 in _dl_sysinfo_int80 () at rtld.c:788 #1 0xb7ab3206 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/i686/libpthread.so.0 #2 0xb7ae50a8 in OpenThreads::Condition::wait (this=0x8128d88, mutex=0x8128d80) at /media/backup/osg/OpenSceneGraph/src/OpenThreads/pthreads/PThreadCondition.c++:130 #3 0xb7b6ac91 in osgViewer::Viewer::renderingTraversals (this=0xbfc66d0c) at /media/backup/osg/OpenSceneGraph/include/OpenThreads/Block:133 #4 0xb7b6b9e3 in osgViewer::Viewer::frame (this=0xbfc66d0c, simulationTime=1.7976931348623157e+308) at /media/backup/osg/OpenSceneGraph/src/osgViewer/Viewer.cpp:983 #5 0xb7b6bb3a in osgViewer::Viewer::run (this=0xbfc66d0c) at /media/backup/osg/OpenSceneGraph/src/osgViewer/Viewer.cpp:195 #6 0x0804b069 in main (argc=Cannot access memory at address 0x0 ) at /media/backup/osg/OpenSceneGraph/applications/osgviewer/osgviewer.cpp:148 Thread 2: #0 0xb7f807f2 in
Re: [osg-users] running vrml plugin on 2.0
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello, Joan Slottow wrote: The isos2_2 and vectors datasets I generated using a user's data. He has been gone from UCLA for many years however, and I cannot ask for his permission. Therefore, I really don't want it to be widely disseminated. However, it's Ok if you use it for testing purposes. The waves and sigmoid data come from data sets that I myself generated for two other users. So, I don't care about those. Anyone can have those. Joan Could you, please, add your data (one or two zipped files) here: http://www.openscenegraph.org/projects/osg/wiki/Support/PlatformSpecifics/VisualStudio/VisualStudioPlugins It would help others to test the plugin. Regards, Jan -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Mandriva - http://enigmail.mozdev.org iD8DBQFGycWWn11XseNj94gRAt+iAKDAFQNR1WOs32fM5uxQrZdQyTlHgwCffirP XRPuuGANgmVbhp8grdrVsds= =WGhA -END PGP SIGNATURE- ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] running vrml plugin on 2.0
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello Robert, I have new information regarding the hangs. I have finally managed to get my gdb to produce a meaningful backtrace when the viewer hangs and this is the result. For DrawThreadPerContext, it is blocked at: Thread 1: #0 0xb7f507f2 in _dl_sysinfo_int80 () at rtld.c:788 #1 0xb7a83206 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/i686/libpthread.so.0 #2 0xb7ab50a8 in OpenThreads::Condition::wait (this=0x8128d88, mutex=0x8128d80) at /media/backup/osg/OpenSceneGraph/src/OpenThreads/pthreads/PThreadCondition.c++:130 #3 0xb7b3ac91 in osgViewer::Viewer::renderingTraversals (this=0xbfdb968c) at /media/backup/osg/OpenSceneGraph/include/OpenThreads/Block:133 #4 0xb7b3b9e3 in osgViewer::Viewer::frame (this=0xbfdb968c, simulationTime=1.7976931348623157e+308) at /media/backup/osg/OpenSceneGraph/src/osgViewer/Viewer.cpp:983 #5 0xb7b3bb3a in osgViewer::Viewer::run (this=0xbfdb968c) at /media/backup/osg/OpenSceneGraph/src/osgViewer/Viewer.cpp:195 #6 0x0804b069 in main (argc=Cannot access memory at address 0x0 ) at /media/backup/osg/OpenSceneGraph/applications/osgviewer/osgviewer.cpp:148 Thread 2: #0 0xb7f507f2 in _dl_sysinfo_int80 () at rtld.c:788 #1 0xb7a8591e in __lll_mutex_lock_wait () from /lib/i686/libpthread.so.0 #2 0xb7a8184e in _L_mutex_lock_80 () from /lib/i686/libpthread.so.0 #3 0xb7a8139d in pthread_mutex_lock () from /lib/i686/libpthread.so.0 #4 0xb7ab5273 in OpenThreads::Mutex::lock (this=0x8058f74) at /media/backup/osg/OpenSceneGraph/src/OpenThreads/pthreads/PThreadMutex.c++:122 #5 0xb7b1a52e in osgViewer::Renderer::draw (this=0x8058f20) at /media/backup/osg/OpenSceneGraph/include/OpenThreads/ScopedLock:31 #6 0xb7b1af58 in osgViewer::Renderer::operator() (this=0xfe00, context=0x812dd70) at /media/backup/osg/OpenSceneGraph/src/osgViewer/Renderer.cpp:548 #7 0xb7e4d45f in osg::GraphicsContext::runOperations (this=0x812dd70) at /media/backup/osg/OpenSceneGraph/src/osg/GraphicsContext.cpp:654 #8 0xb7e538dd in osg::RunOperations::operator() (this=0x8129278, context=0x812dd70) at /media/backup/osg/OpenSceneGraph/src/osg/GraphicsThread.cpp:134 #9 0xb7e53947 in osg::GraphicsOperation::operator() (this=0x8129278, object=0x812dd70) at /media/backup/osg/OpenSceneGraph/src/osg/GraphicsThread.cpp:50 #10 0xb7e7c627 in osg::OperationThread::run (this=0x8128f78) at /media/backup/osg/OpenSceneGraph/src/osg/OperationThread.cpp:413 #11 0xb7e53a89 in osg::GraphicsThread::run (this=0x8128f78) at /media/backup/osg/OpenSceneGraph/src/osg/GraphicsThread.cpp:38 #12 0xb7ab47e4 in OpenThreads::ThreadPrivateActions::StartThread (data=0x8128f88) at /media/backup/osg/OpenSceneGraph/src/OpenThreads/pthreads/PThread.c++:158 #13 0xb7a7f462 in start_thread () from /lib/i686/libpthread.so.0 #14 0xb769c82e in clone () from /lib/i686/libc.so.6 For CullThreaPerCameraDrawThreadPerContext I get the hang in: Thread 1: #0 0xb7f807f2 in _dl_sysinfo_int80 () at rtld.c:788 #1 0xb7ab3206 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/i686/libpthread.so.0 #2 0xb7ae50a8 in OpenThreads::Condition::wait (this=0x8128d88, mutex=0x8128d80) at /media/backup/osg/OpenSceneGraph/src/OpenThreads/pthreads/PThreadCondition.c++:130 #3 0xb7b6ac91 in osgViewer::Viewer::renderingTraversals (this=0xbfc66d0c) at /media/backup/osg/OpenSceneGraph/include/OpenThreads/Block:133 #4 0xb7b6b9e3 in osgViewer::Viewer::frame (this=0xbfc66d0c, simulationTime=1.7976931348623157e+308) at /media/backup/osg/OpenSceneGraph/src/osgViewer/Viewer.cpp:983 #5 0xb7b6bb3a in osgViewer::Viewer::run (this=0xbfc66d0c) at /media/backup/osg/OpenSceneGraph/src/osgViewer/Viewer.cpp:195 #6 0x0804b069 in main (argc=Cannot access memory at address 0x0 ) at /media/backup/osg/OpenSceneGraph/applications/osgviewer/osgviewer.cpp:148 Thread 2: #0 0xb7f807f2 in _dl_sysinfo_int80 () at rtld.c:788 #1 0xb7ab591e in __lll_mutex_lock_wait () from /lib/i686/libpthread.so.0 #2 0xb7ab184e in _L_mutex_lock_80 () from /lib/i686/libpthread.so.0 #3 0xb7ab139d in pthread_mutex_lock () from /lib/i686/libpthread.so.0 #4 0xb7ae5273 in OpenThreads::Mutex::lock (this=0x8058f6c) at /media/backup/osg/OpenSceneGraph/src/OpenThreads/pthreads/PThreadMutex.c++:122 #5 0xb7b4a52e in osgViewer::Renderer::draw (this=0x8058f20) at /media/backup/osg/OpenSceneGraph/include/OpenThreads/ScopedLock:31 #6 0xb7b4af58 in osgViewer::Renderer::operator() (this=0xfe00, context=0x812dd70) at /media/backup/osg/OpenSceneGraph/src/osgViewer/Renderer.cpp:548 #7 0xb7e7d45f in osg::GraphicsContext::runOperations (this=0x812dd70) at /media/backup/osg/OpenSceneGraph/src/osg/GraphicsContext.cpp:654 #8 0xb7e838dd in osg::RunOperations::operator() (this=0x8129278, context=0x812dd70) at /media/backup/osg/OpenSceneGraph/src/osg/GraphicsThread.cpp:134 #9 0xb7e83947 in osg::GraphicsOperation::operator() (this=0x8129278, object=0x812dd70) at /media/backup/osg/OpenSceneGraph/src/osg/GraphicsThread.cpp:50 #10 0xb7eac627 in osg::OperationThread::run
Re: [osg-users] running vrml plugin on 2.0
Hi Jan,
On 8/17/07, Jan Ciger [EMAIL PROTECTED] wrote:
Try forcing different threading models by using the OSG_THREADING env
var, or setting it on the command line. See osgviewer --help and
osgviewer --help-env for details.
SingleThreaded seems to work, DrawThreadPerContext hangs often,
CullDrawThreadPerContext didn't hang on me yet,
CullThreadPerCameraDrawThreadPerContext hanged. However, as this seems
to be timing-sensitive, take this test with a grain of salt.
CullThreaPerCameraDrawThreadPerContext hangs on my machine new
machine, so this is something I can reproduce and while I don't know
what the problem is I should be able to fix. DrawThreadPerContext is
100% reliable with my test data/apps on my single core to quad core
systems though which is frustrating as tracking down what problems
might exists become much much harder.
Both CullThreaPerCameraDrawThreadPerContext and DrawThreadPerContext
threading models allow the rendering traversal to run in a parallel
with the update traversal and to do this require the scene graphs
static vs dynamic status to be set appropriately otherwise problems
can occur with objects being modified at the same time as being read.
CullDrawThrreadPerContext is similar to osgProducer/Producer's
ThreadPerCamera when there is one camera per graphics window
(RenderSurface), the general sync of the update vs rendering
traversals is similar, and there is never any overlap between the
rendering traversals and update.
Producer can't handle ThreadPerCamera when there is more than one
camera per graphics window so drops down to SingleThreaded, but in
this case osgViewer's CullDrawThreadPerContext will continue being
multi-threaded so the two will diverge. Also osgProducer when there
is one graphics window will fallback to SingleThreaded automatically
as this typically gives best performance on a single card system.
To get Producer working mult-threaded you need to have multiple
graphics windows each with a single camera, any other combination and
you'll get single threaded. So... in your testing of
osgproducerviewer one your system it might well be just running single
threaded, which is equivalent to osgViewer's running SingleThreaded.
osgViewer is a bit more proactive on threading, and if you have
multiple cores available will opt for DrawThreadPerContext as this
threading model will typically provide the best performance - for my
own tests I get between 20 to 80% performance improvement on big
models. The more CPU limited you are the better the improvement will
be.
Do the hangs always happen at start up? Or any point during rendering?
No, not always at startup. It usually happens after I move the mouse or
rotate the object. Sometimes it works for 10-15 seconds and then it the
motions gets jerky, normal again and the usually hangs.
I wonder if X11 could be the problem. osgViewer manages two
connections per graphics window to the X server, one for the graphics
thread and one for the even thread, this in theory should avoid
conflicts. You could you enable thread safe X11 via XInitThreads. In
src/osgViewer/GraphicsWindowX11.cpp you'll find the follow:
#if 0
if (XInitThreads() == 0)
{
osg::notify(osg::NOTICE) Error: XInitThreads() failed.
Aborting. std::endl;
exit(1);
}
else
{
osg::notify(osg::INFO) X11WindowingSystemInterface,
xInitThreads() multi-threaded X support initialized.\n;
}
#endif
Just re-enable the XInitThreads block and see how you get on. This
*shouldn't* be required thanks to using two connects, but perhaps
there is certain circumstances when the X server/windowmanager is
screwing up, or osgViewer::GraphicsWindowX11 introducing the problem.
If you could provide a datasets then I could try it out on my system.
I have a dual core Althon system and a new quad core Intel system,
both right now just have a single card in but I can swap things
around.
I can send you the ones I have got from Joan off-list, I hope she is OK
with that.
I'll download load OpenVRML and test it out.
Robert.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] running vrml plugin on 2.0
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello, Robert Osfield wrote: CullThreaPerCameraDrawThreadPerContext hangs on my machine new machine, so this is something I can reproduce and while I don't know what the problem is I should be able to fix. DrawThreadPerContext is 100% reliable with my test data/apps on my single core to quad core systems though which is frustrating as tracking down what problems might exists become much much harder. CullThreaPerCameraDrawThreadPerContext was always hanging for me, I believe that it may not be related to the problems I am seeing right now. I will try to track the deadlock down from my side. If you cannot reproduce it, it is impossible to fix it. Both CullThreaPerCameraDrawThreadPerContext and DrawThreadPerContext threading models allow the rendering traversal to run in a parallel with the update traversal and to do this require the scene graphs static vs dynamic status to be set appropriately otherwise problems can occur with objects being modified at the same time as being read. I am not setting this. Isn't the dynamic status the default one? But even if it wasn't, I am getting hangs with pure viewer too where nothing is being modified. CullDrawThrreadPerContext is similar to osgProducer/Producer's ThreadPerCamera when there is one camera per graphics window (RenderSurface), the general sync of the update vs rendering traversals is similar, and there is never any overlap between the rendering traversals and update. OK. So... in your testing of osgproducerviewer one your system it might well be just running single threaded, which is equivalent to osgViewer's running SingleThreaded. That is possible, and then it means that there is a race condition somewhere. osgViewer is a bit more proactive on threading, and if you have multiple cores available will opt for DrawThreadPerContext as this threading model will typically provide the best performance - for my own tests I get between 20 to 80% performance improvement on big models. The more CPU limited you are the better the improvement will be. Yes, that is what I see here too. This mode is the default for me. I wonder if X11 could be the problem. osgViewer manages two connections per graphics window to the X server, one for the graphics thread and one for the even thread, this in theory should avoid conflicts. You could you enable thread safe X11 via XInitThreads. In src/osgViewer/GraphicsWindowX11.cpp you'll find the follow: ... Just re-enable the XInitThreads block and see how you get on. This *shouldn't* be required thanks to using two connects, but perhaps there is certain circumstances when the X server/windowmanager is screwing up, or osgViewer::GraphicsWindowX11 introducing the problem. Thanks for the tip, I am going to test it. Regards, Jan -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Mandriva - http://enigmail.mozdev.org iD8DBQFGxykan11XseNj94gRAmMxAJ9RWQHxYR4l+fdOjHBzJual6rDnCACeI1vb rVP7qbshRGI4jvfyY15YcqQ= =AojA -END PGP SIGNATURE- ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] running vrml plugin on 2.0
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Robert Osfield wrote:
#if 0
if (XInitThreads() == 0)
{
osg::notify(osg::NOTICE) Error: XInitThreads() failed.
Aborting. std::endl;
exit(1);
}
else
{
osg::notify(osg::INFO) X11WindowingSystemInterface,
xInitThreads() multi-threaded X support initialized.\n;
}
#endif
Just re-enable the XInitThreads block and see how you get on. This
*shouldn't* be required thanks to using two connects, but perhaps
there is certain circumstances when the X server/windowmanager is
screwing up, or osgViewer::GraphicsWindowX11 introducing the problem.
I have tried this and I still do get hangs. Both
- --CullThreadPerCameraDrawThreadPerContext and --DrawThreadPerContext
hang for me after a while. Single threaded and
- --CullDrawThreadPerContext are OK.
To me it looks like something hanging on a mutex in some library without
debug symbols because all I get in gdb are question marks instead of
function names.
It is not likely a driver issue, I am running version 100.14.11 and have
tried also 1.0-9639, both with same results. I have kernel 2.6.22.
Regards,
Jan
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: Using GnuPG with Mandriva - http://enigmail.mozdev.org
iD8DBQFGx6Tun11XseNj94gRApYgAJ9kHE53DAhptuN0shQ91Vod1hfEXwCg5YZo
8otXnIRA8Qr9Xs5s8Y7JwnM=
=4ghG
-END PGP SIGNATURE-
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] running vrml plugin on 2.0
Hi Joan, The problems you describe look to most likely to be issues with display listing of the geometries. It could be that they are just poorly conditioned datasets - one triangle per geometry is certainly very very badly condidtioned and needs fixing to be able expect any sensible performance level, or it could be that the models are simply to big for the hardware/OGL driver to cope with. There might also be possibility of error in the data such as a primitive index that is invalid. This is also just speculation though... Robert. On 8/16/07, Joan Slottow [EMAIL PROTECTED] wrote: Jan I tested the latest vrml plugin on some larger files, real vrml files rather than the little test files that I sent you before. I tested them with both osgviewer and vrNav2, my own program. First, the problem with osgUtil::SceneView crashing in draw( ) that I had before when I loaded the vrml files with vrNav2 is now gone, so that's good. I notice, from looking at the resultant .osg files, that the vrml translation is introducing a rotation to turn the z of the model up. vrNav2 already does that for all models so I added a test there not to do it for .wrl models it loads. The first few models that I loaded worked fine. Then I ran into a problem. The problem seems to be related to the size or the number of Shapes in the vrml file. Also, it may be some kind of timing problem (in it taking too long to load the model). The problem manifests itself as follows: in osgviewr, the graphics screen comes up as a black screen and then turns into a screen with a blue background and the model appears. With the ones that don't work, the screen remains black and you don't see the model. With vrNav2, vrjuggler is opening for me (using X Windows calls) a black graphics screen of size 640 by 480. With the ones that don't work, I get a black graphics screen that fills the whole screen (not 640 x 480) and no model. When it works, I get my 640 x 480 graphics screen. vrNav2 writes out the model's bounding box dimensions immediately after loading the model and this always happens. Also, if I change the vrNav2 code so that immediately after loading the model it writes out the model in .osg format, the problem is gone and the program work and the problem. But if immediately after loading the model, I just add some sleep, I am back to it not working. If I take a model that doesnt work but which has multiple Shapes, and divide it into .wrl files each with a single shape and load just a single Shape, it always works. I can also take subsets of the Shapes and have it work. Here are 4 models: waves.wrl with 3 Shapes 3406099 bytes isos2_2.wrl with 2 Shapes 883264 bytes sigmoid.wrl with 6 Shapes 326260 bytes vectors.wrl with 8 Shapes 3234335 bytes From them I constructed the following: sigmoid1.wrl the first Shape from sigmoid.wrl, sigmoid2.wrl the second Shape, ... sigmoid6.wrl the sixth Shape, sigmoid1-3.wrl the first three Shapes, sigmoid1-4.wrl the first 4 shapes, sigmoid1-5.wrl the first 5 Shapes. vectors1-4.wrl the first 4 Shapes from vectors.wrl, vectors1-5.wrl and vectors5-8.wrl etc. waves1.wrl the first Shape from waves.wrl, also waves2.wrl, waves3.wrl and waves1-2.wrl. Here are the results: model vrNav osgviewer sigmoid black screenblack screen any of sigmoid1 through sigmoid6works works sigmoid1-3works works sigmoid1-4works black screen sigmoid1-5black screenblack screen isos2_2 works works waves black screenworks waves1black screenworks waves2works works waves3works works waves1-2 black screenblack screen vectors black screenworks vectors1-4works works vectors1-5black screenworks vectors5-8works works Anyway, I am not unhappy with this situation. My goal is to be able to take vrml 2.0 files output by scientific visualization programs and turn them into models that can be loaded. I can easily do this by following this procedure: osconv whatever.wrl whatever.osg edit whatever.osg and remove the matrix transform at the top osconv whatever.osg whatever.ive Then I load the .ive file and that always works. I also tried writing a vrml 2.0 file from VMD a popular program used to visualize chemistry molecules. That program wrote out an absolutely huge file with one Shape per triangle. That file can't be loaded. However, I can write a program to read in the vrml file as output by VMD and convert it to a more
Re: [osg-users] running vrml plugin on 2.0
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Robert Osfield wrote: Hi Joan, The problems you describe look to most likely to be issues with display listing of the geometries. It could be that they are just poorly conditioned datasets - one triangle per geometry is certainly very very badly condidtioned and needs fixing to be able expect any sensible performance level, or it could be that the models are simply to big for the hardware/OGL driver to cope with. There might also be possibility of error in the data such as a primitive index that is invalid. This is also just speculation though... Robert. Robert, I think that there may be indeed some threading bug in the osgViewer. I have tested the files from Joan and if I view them using osgViewer, it starts up (no black screen) but hangs right away after displaying the first few frames or when I try to move the camera. This happens for all of the models here. If I do the same with osgproducerviewer, everything works and I am getting decent frame rates even - few hundreds FPS, even up to 1000 sometimes on my two 6800GS. The models are not that big, the largest has 117693 polygons and I am still getting 1000+ FPS with it with Producer. I have also checked the data files and the VRML files contain several meshes, few thousands triangles/quads each. Nothing extraordinary. I have experienced the hangs with osgViewer in our own application recently as well, but I couldn't reproduce them with the plain osgviewer binary, so I have ascribed it to some race condition in my code. Now these datafiles trigger it with plain viewer 100% each time on my PC. I am running a dual core Athlon (SMP machine) and the cards are configured using SLI, alternative frame rendering (AFR). Regards, Jan -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Mandriva - http://enigmail.mozdev.org iD8DBQFGxJomn11XseNj94gRAqtPAKCz0RKZOA2BXaq6FU9yLVAOorEK8ACff8RU Uwh0Ezf1pHDeaHDDKA8jmb0= =P9SG -END PGP SIGNATURE- ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] running vrml plugin on 2.0
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello, Joan Slottow wrote: Jan ... I notice, from looking at the resultant .osg files, that the vrml translation is introducing a rotation to turn the z of the model up. Yes, this is done to make the viewing more convenient, the standard OSG coordinate system is z-up, not y-up as VRML. vrNav2 already does that for all models so I added a test there not to do it for .wrl models it loads. The first few models that I loaded worked fine. Then I ran into a problem. The problem seems to be related to the size or the number of Shapes in the vrml file. Also, it may be some kind of timing problem (in it taking too long to load the model). Please, see my reply to Robert - I think that you may have hit a bug in osgViewer. For me the viewer hangs completely after loading your data, however, the old osgproducerviewer displays everything fine. The problem thus cannot be in the plugin nor data (both viewers use the same). Moreover, I have seen these hangs with other (non-vrml data) recently too. I guess a threading bug was introduced in the renderer when Robert did some recent changes. BTW, I would be grateful if you could spare one or two of your files and add them to my test file on the OSG web site (zipped, please!). It would be a good test case with realistic data where people can verify that their installation of the plugin works OK. ... I also tried writing a vrml 2.0 file from VMD a popular program used to visualize chemistry molecules. That program wrote out an absolutely huge file with one Shape per triangle. That file can't be loaded. However, I can write a program to read in the vrml file as output by VMD and convert it to a more reasonable one that looks like the vrml files output by OpenDX. I did some playing around with that and that will also work. Of course, if you have a shape per triangle, the loading will be incredibly slow - that means you will have over 100k+ shapes in the largest file! And every shape is potentially a state change in the pipeline, that has to completely kill the performance. I think that your data are OK, there is a problem somewhere in the viewer at this point. I have ltrace on the program (gdb doesn't give me a meaningful stack) and I have found that it hangs on a mutex here: SYS_write(3, cull()\n, 7) = 7 SYS_gettimeofday(0xbfdef484, 0, 0xb7fb04cc, 0x8059530, 0x80593a8) = 0 SYS_gettimeofday(0xbfdef484, 0, 0xb7fb04cc, 0x8059530, 0x80593a8) = 0 SYS_futex(0x805900c, 1, 1, 0x8058f20, 0x805900c) = 0 SYS_write(3, end cull() 0x8058f20\n, 21) = 21 SYS_futex(0x80fda10, 0, 61, 0, 61 There is output to standard error output (probably debug message) and right away it gets blocked on a futex. It is very timing specific - in strace/ltrace I have managed to avoid the deadlock if I have enabled more printing - slowing the viewer down. Regards, Jan -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Mandriva - http://enigmail.mozdev.org iD8DBQFGxJwJn11XseNj94gRAgrUAJ9WjidpOadY+3lvw/ylengHC+z5dACeML89 0fVrNXhEVA1HOJ8M2CAj92E= =7lgh -END PGP SIGNATURE- ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] running vrml plugin on 2.0
Hi Jan
I tried sending this to you on July 26 but somehow it went out without a
subject and then I have been away on vacation.
Joan
Jan
Here are three files: test2_dx.wrl is the original .wrl file as output from
OpenDX. test2.wrl is the .wrl file that runs fine in osgviewer (minus the per
vertex colors) after:
Group {
children [
]
}
are removed from top and bottom respectively.
test3_dx.wrl is the same thing but with two Shape's instead of 1. This one
doesnt work when Group and children are removed. At least I cant see anything.
Joan
wrl_tests.tar.gz
Description: wrl_tests.tar.gz
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] running vrml plugin on 2.0
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hello,
Joan Slottow wrote:
Hi Jan
I tried sending this to you on July 26 but somehow it went out
without a subject and then I have been away on vacation.
Aha, I see. I didn't receive anything from you.
Jan
Here are three files: test2_dx.wrl is the original .wrl file as
output from OpenDX. test2.wrl is the .wrl file that runs fine in
osgviewer (minus the per vertex colors) after:
Group { children [
] }
are removed from top and bottom respectively. test3_dx.wrl is the
same thing but with two Shape's instead of 1. This one doesnt work
when Group and children are removed. At least I cant see anything.
Joan
OK, I will give it a shot and see what I can do.
Regards,
Jan
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: Using GnuPG with Mandriva - http://enigmail.mozdev.org
iD8DBQFGufEVn11XseNj94gRAmZsAJ4uRt8BIsVjT4eMzSwc0KudFlBDggCeMCgU
nrkZcCI97AP861SPKRWVDRY=
=NqGZ
-END PGP SIGNATURE-
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [Osg-Users] running vrml plugin on 2.0
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hello Joan,
I have checked the code of the plugin as I promised.
Joan Slottow wrote:
3) I wrote out a version of it with much less geometry. I was able to
load it in both osgviewer and in my program when I got rid of:
Group { children [ here is the whole vrml file ] }
which was around the whole thing.
This is caused by the plugin not handling a Group node. At the moment it
handles only Transforms, Shapes and Appearance, nothing else. A Group
node could be added easily, though.
Unfortunately a proper implementation of the scene graph translation
would require a significant coding effort - there are simply way too
many types of VRML nodes to be handled if you want to load scenes of any
significant complexity. I do not have time to do that at right now,
however you are welcome to contribute a patch. On the other hand, that
was not even the goal of this plugin - it is only a quick hack to be
able to import textured VRML meshes into OSG. If you need a complex
scene support, try the Coin3D plugin. That will probably work better for
your needs.
4) However, my vrml files has:
color Color { color [ 0.00 0.304099 0.989031, 0.00 0.315067
1.00, 0.00 0.315067 1.00, 0.00 0.315067 1.00,
0.00 0.315067 1.00, 0.00 0.315067 1.00, 0.00
0.315067 1.00, 0.00 0.315067 1.00, ] } colorPerVertex
TRUE
And after it loads it the color is gone. I wrote out the scene graph
in .osg format immediately after loading the file and then looked at
it. I should see something like:
Could you provide me with an example file of the data you want to load?
The implementation of the vertex colours is trivial, but I do not have
means to author VRML here. I will need to test it.
Regards,
Jan
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: Using GnuPG with Mandriva - http://enigmail.mozdev.org
iD8DBQFGr9Xbn11XseNj94gRAgk0AKDVS5ulQt+fjgJII7ZcMHS1x1fd3gCffdk+
1LyfxCqsv973L+ElECUuauE=
=SnkW
-END PGP SIGNATURE-
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
