-----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
[email protected]
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
