From: Daniele V. <dan...@gm...> - 2010-01-09 23:12:03
|
Hello, collision detection doesn't work with PyODE checked out from CVS HEAD and ODE 0.11. The collision callback is never called. This can be tested with tutorial3.py or with the script in http://monsterden.net/software/ragdoll-pyode-tutorial: the objects don't meet the plane and keep falling forever. The same scripts using PyODE 1.2 and ODE 0.8 work correctly. ODE and PyODE are new for me, so I wouldn't know where to start from to create a patch, sorry. I took a quick diff of the files space.pyx and ode.pyx between versions 1.2 and HEAD but I spotted nothing obviously wrong. -- Daniele |
From: Ethan Glasser-C. <gl...@cs...> - 2010-01-10 05:33:11
|
Daniele Varrazzo wrote: > collision detection doesn't work with PyODE checked out from CVS HEAD > and ODE 0.11. The collision callback is never called. This can be > tested with tutorial3.py or with the script in > http://monsterden.net/software/ragdoll-pyode-tutorial: the objects > don't meet the plane and keep falling forever. Yikes! I just built pyode from CVS on my work laptop against libode 0.11. Then I ran examples/tutorial3 and it ran successfully (well, OpenGL artifacts, but collision detection worked). Can you give me more details on your setup? 32-/64-bit machine? OS? Ethan |
From: Daniele V. <dan...@gm...> - 2010-01-10 16:23:54
|
On Sun, Jan 10, 2010 at 5:14 AM, Ethan Glasser-Camp <gl...@cs...> wrote: > Daniele Varrazzo wrote: >> collision detection doesn't work with PyODE checked out from CVS HEAD >> and ODE 0.11. The collision callback is never called. This can be >> tested with tutorial3.py or with the script in >> http://monsterden.net/software/ragdoll-pyode-tutorial: the objects >> don't meet the plane and keep falling forever. > > Yikes! > > I just built pyode from CVS on my work laptop against libode 0.11. Then > I ran examples/tutorial3 and it ran successfully (well, OpenGL > artifacts, but collision detection worked). Can you give me more details > on your setup? 32-/64-bit machine? OS? It is a fairly standard 32 bit Ubuntu Karmic, using the ode library packaged with the OS (packages libode-dev (2:0.11-4), libode1 (2:0.11-4)). Python version 2.6 (the system version). Pyrex version 0.9.8.5. I built the module regularly (python setup.py build/install), against the correct library (checked with ldd). Tutorials 1 and 2 run perfectly, in 3 the pieces fall without meeting the plane. I also made the explosion happen earlier to make the falling pieces hit each other, and there is no contact between them either. A print in the callback function confirms it gets never called. I've done other tests and I confirm the bug on my box also with ode 0.11 and 0.11.1 compiled from source, against the PyODE code just checked out from the head. The same tutorial3 script works fine with PyODE 1.2.0 compiled against ode 0.8 (modulo adding import OpenGL OpenGL.ERROR_CHECKING = False before importing the other opengl stuff to avoid a segfault in the current PyOpenGL... bleah). Tell me if you need other details. Thank you very much for your efforts. -- Daniele |
From: Ethan Glasser-C. <gl...@cs...> - 2010-01-10 19:23:10
|
Daniele Varrazzo wrote: > It is a fairly standard 32 bit Ubuntu Karmic, using the ode library > packaged with the OS (packages libode-dev (2:0.11-4), libode1 > (2:0.11-4)). Python version 2.6 (the system version). Pyrex version > 0.9.8.5. > > I built the module regularly (python setup.py build/install), against > the correct library (checked with ldd). Tutorials 1 and 2 run > perfectly, in 3 the pieces fall without meeting the plane. I also made > the explosion happen earlier to make the falling pieces hit each > other, and there is no contact between them either. A print in the > callback function confirms it gets never called. > > Tell me if you need other details. Thank you very much for your efforts. I'm kind of grasping at straws here, since I can't reproduce it. I've tried on my 64-bit Karmic machine, running the same packages you are, and now I just tried on my 32-bit Debian machine (which is sorta running whatever). The only thing that strikes me as likely to be different is that instead of doing "python setup.py install", I ran: PYTHONPATH=build/lib.linux-i686-2.5/ python examples/tutorial3.py (Or whatever -- substitute the correct build directory on your machine.) I guess one thing I'd suggest is doing: import ode print ode.__file__ to make sure you're running the just-built version. I suspect you are -- if you weren't, I think you'd probably be seeing more severe problems. If that doesn't help, I'd start putting print statements in Space.collide (defined in src/space.pyx) to make sure that was getting called successfully, and if that didn't help I'd do the same thing in the ODE library (which I don't know that well -- sorry). Ethan |
From: Daniele V. <dan...@gm...> - 2010-01-10 23:06:04
|
On Sun, Jan 10, 2010 at 7:19 PM, Ethan Glasser-Camp <gl...@cs...> wrote: > whatever). The only thing that strikes me as likely to be different is > that instead of doing "python setup.py install", I ran: > > PYTHONPATH=build/lib.linux-i686-2.5/ python examples/tutorial3.py > > (Or whatever -- substitute the correct build directory on your machine.) Well, I skipped over the details of my setup, but I am using a virtualenv and putting the python library in a private non-system directory. For ode I am using instead the /usr/local tree, taking care to keep a single version of the library at time, cleaning things up before "make install" of the new one I want to test. I have done some steps ahead: I've noticed that space.getNumGeoms() = 31 in the working demo runtime (30 boxes and the floor), but in the buggy one is always 1: this means that boxes geoms are not retained in the space collection. Further analysis shows that space.getNumGeoms() goes to 2 just after the addiction to the space (i.e. geom = ode.GeomBox(space, lengths=body.boxsize)), but when the function ends and the python "geom" variable goes out of scope, the count goes back to 1. As a test I added a global list of geoms appending the box geoms to it before they go out of scope: with this fix the demo works correctly. So, it looks like a structures ownership issue: as the head works, as soon as the python object goes, so it does the wrapped C geom, also when it is part of other structures (the space). This is a counterintuitive behaviour from a Python P.o.V., because "well behaved" python object are kept alive when another structure points to them (while instead the association space ->geom seems more a weakref now). Also the different outcome between my box and yours doesn't seem a sign of robustness. I already had an experience of writing a Pyrex wrapper around C structures that could have either lived alone or been part of other structures: to make everything work without leaks and dangling pointers, I used an explicit flag on every wrapper, saying if the wrapper was the "owner" of the structure (and this the structure had to be deleted together with the python object) or if the wrapper was just a view of a structure and some other object was in charge to delete it (e.g. when doing some "foo.bar.baz": the object returned by the "bar" attribute allowed a temporarily access to the underlying structure, but the latter is not destroyed with the short-lived wrapper: it is still "foo" to have its ownership). I don't know much about the life cycle of the ODE structures (e.g. who is in charge to free a geom when it is part of a space) but I suspect the bug I am experimenting is caused by a mismatch with the life cycle imposed by the pyrex wrappers and the Python runtime. Cheers -- Daniele |
From: Ethan Glasser-C. <gl...@cs...> - 2010-01-11 03:41:40
|
Daniele Varrazzo wrote: > So, it looks like a structures ownership issue: as the head works, as > soon as the python object goes, so it does the wrapped C geom, also > when it is part of other structures (the space). This is a > counterintuitive behaviour from a Python P.o.V., because "well > behaved" python object are kept alive when another structure points to > them (while instead the association space ->geom seems more a weakref > now). Also the different outcome between my box and yours doesn't seem > a sign of robustness. Oh, crap, this is because you're running tutorial3 from the site, which hasn't been updated in a while. Boy, is my face red. There was a change a while back that made geoms get deallocated, and I updated tutorial3 in CVS but not on the site. I'm looking to see if I can do that now. It's true that the relationship space->geom behaves like a weakref, and so does the relationship world->body. I don't think there's any technical reason for this. It looks like at one point someone wanted to make geoms keep a reference to spaces they were in, but it doesn't look like that functionality got implemented. I think you're probably right, that spaces should keep references to their geoms, but not the other way around. I'll try to make that change this week. Ethan |