pyode-user

[Pyode-user] pyODE and PyOSG

[brett h. <bha...@ya...>]

Hello Bernie, Matthias, and Timothy,

I tried last nights CVS, i got a number of errors building it, but it still works (without trimesh
support).  I have ported tutorial2.py and tutorial3.py to use PyOSG as the renderer, i thought
that someone may want to include them in CVS because i think it might be another good example. 
Also attached is the file named tutorial3_osg_segfault.py.  This file will crash when you run it
because it seems that if more than 34 bodies collide at once (at least on the first frame if they
are all intersecting), then pyODE will crash by segmentation fault.  I'm not sure if this is a bug
or just something that should always be avoided.

To run the new tutorials you will need to install OSG (http://openscenegraph.sourceforge.net/) and
PyOSG (http://sourceforge.net/projects/pyosg)

If you are running debian you can easily install them by these commands:
echo "deb http://opart.org/debian/ ./" >> /etc/apt/sources.list
apt-get update
apt-get install libopenscenegraph
apt-get install pyosg


Hope everyone is doing well,
-brett


		
_______________________________
Do you Yahoo!?
Declare Yourself - Register online to vote today!
http://vote.yahoo.com

Re: [Pyode-user] pyODE and PyOSG

[Matthias B. <ba...@ir...>]

brett hartshorn wrote:
> I tried last nights CVS, i got a number of errors building it, but it still works (without trimesh
> support).  I have ported tutorial2.py and tutorial3.py to use PyOSG as the renderer, i thought
> that someone may want to include them in CVS because i think it might be another good example. 

Sounds good! Unfortunately, I couldn't test it (I'm on Windows). Do you 
plan to support Windows as well at some time? Everything seems to be 
tailored to Linux/gcc. I changed the paths in SConstruct and removed the 
gcc specific options but gave up as some file wanted to include X11 
headers...

By the way, I noticed you also packaged the *.ncb file in the Visual 
Studio directory (which is 7.5MB). This file is not necessary for 
compiling, it just contains information the IDE is using and will be 
created by the IDE on demand.

- Matthias -

Re: [Pyode-user] pyODE and PyOSG

[Chris B. <c.j...@ed...>]

On Saturday 02 October 2004 21:33, brett hartshorn wrote:
>  i thought
> that someone may want to include them in CVS because i think it might be
> another good example.

Hi, I also wrote a small example. Mine uses pyqt and pyode, the GUI was made 
in qtdesigner. You can download it from 
http://europa.dcs.ed.ac.uk:1234/~chrb/pub/swing_pyode_pyqt_demo.tar.bz2. 
Please consider it for inclusion as an example as well. It's well commented, 
has interaction between the qt buttons and ode simulation, and allows 
rotation and movement with the mouse.

Re: [Pyode-user] pyODE and PyOSG

[brett h. <bha...@ya...>]

Hi Chris,

I tried swing_pyode_pyqt_demo but i get the following error:
brett@chitwan:~/pyode_cvs/swing$ ./test.py
init physics
ANCHOR at (0.0, 0.0, 3.0)
We have OpenGL support
TestWidget init
Unable to resolve Xmu symbols - please check your Xmu library installation.

I think i have everything installed correctly, but i may be missing some libs?  I have already
installed libxmuu-dev and libxmu-dev

-brett


		
_______________________________
Do you Yahoo!?
Declare Yourself - Register online to vote today!
http://vote.yahoo.com

Re: [Pyode-user] pyODE and PyOSG

[Chris B. <C.J...@ed...>]

On Wednesday 06 October 2004 06:06, brett hartshorn wrote:
> Hi Chris,
>
> I tried swing_pyode_pyqt_demo but i get the following error:
> brett@chitwan:~/pyode_cvs/swing$ ./test.py
> init physics
> ANCHOR at (0.0, 0.0, 3.0)
> We have OpenGL support
> TestWidget init
> Unable to resolve Xmu symbols - please check your Xmu library installation.
>
> I think i have everything installed correctly, but i may be missing some
> libs?  I have already installed libxmuu-dev and libxmu-dev
>
> -brett

Looks like its probably failing in QGLWidget.__init__(self,parent,name). Maybe 
there is some dependency problem with your QT/OpenGL libraries? 

Re: [Pyode-user] pyODE and PyOSG

[Timothy S. <ti...@st...>]

On Sat, 2004-10-02 at 22:33, brett hartshorn wrote:
> I tried last nights CVS, i got a number of errors building it,

I also get these warnings when building. They first appeared when I
upgraded to GCC 3.3.3. What version of GCC do you have? I will contact
the Pyrex author about it.

> I have ported tutorial2.py and tutorial3.py to use PyOSG as the
> renderer, i thought that someone may want to include them in CVS
> because i think it might be another good example.=20

Sounds cool!

> This file will crash when you run it because it seems that if more than 3=
4 bodies collide
> at once (at least on the first frame if they are all intersecting), then =
pyODE will crash
> by segmentation fault.  I'm not sure if this is a bug or just something t=
hat should always
> be avoided.

I'm pretty sure it's a bug but I can't check (or try any of your
tutorials) because I cannot get OSG to build. I get

  In file included from ../DatabasePager.cpp:1:
  ../../../include/osgDB/DatabasePager:24:34: OpenThreads/ScopedLock: No
  such file or directory

and then few pages of errors. I'll have another go at it soon.

--=20
Timothy Stranex <ti...@st...>

Re: [Pyode-user] pyODE and PyOSG

[Timothy S. <ti...@st...>]

Hello,

I've finally been able to get OSG and PyOSG built and installed.

On Sat, 2004-10-02 at 22:33, brett hartshorn wrote:
> I have ported tutorial2.py and tutorial3.py to use PyOSG as the renderer,=
 i thought
> that someone may want to include them in CVS because i think it might be =
another good
> example.=20

They're pretty cool. I have two suggestions, if you're interested:

    1. In tutorial2_osg.py, start with the camera further away from the
       blocks and facing them.
    2. In tutoiral3_osg.py, add a little more light and colour the base
       plane.

> Also attached is the file named tutorial3_osg_segfault.py.  This file wil=
l crash when you
> run it because it seems that if more than 34 bodies collide at once (at l=
east on the first
> frame if they are all intersecting), then pyODE will crash by segmentatio=
n fault.

After testing it on my computer, it segfaults if here are more than 68
objects. I've done some looking but I can't work out what's causing it.
The segfault occurs in world.step() or world.quickStep(). My
investigation found two potential problems:

1. Body.setMass() takes a Mass object argument. It doesn't keep a
reference to it but uses its dMass Mass._mass for dBodySetMass(dBodyID,
const dMass *mass). If the Mass object is deallocated, ODE could still
try to access it.

2. ContactJoint uses Contact objects for ODE calls without keeping
references. ODE might still try to access it even if the Contact object
has been deallocated.

I'm not entirely sure if the above points are correct because none of
the tutorials ever crash even though they could by the above mechanisms.
Also, fixing them doesn't fix the segfault problem above.

What do you think?

--=20
Timothy Stranex <ti...@st...>

Re: [Pyode-user] pyODE and PyOSG

[brett h. <bha...@ya...>]

Hi Tim,

I was actually already planning to update the tutorials and those were changes i was planning to
make, its going to take a little time though because i am in the middle of fixing some things in 
PyOSG.  I'll let you know when i've made the updates.

I'm not sure where that Segfault is comming from either; its strange, but maybe as we do more
testing, it will become clear.  In the meantime it does not seem like a big problem because i
don't think that that many objects should ever be intersecting in the first place.

-brett

--- Timothy Stranex <ti...@st...> wrote:

> Hello,
> 
> I've finally been able to get OSG and PyOSG built and installed.
> 
> On Sat, 2004-10-02 at 22:33, brett hartshorn wrote:
> > I have ported tutorial2.py and tutorial3.py to use PyOSG as the renderer, i thought
> > that someone may want to include them in CVS because i think it might be another good
> > example. 
> 
> They're pretty cool. I have two suggestions, if you're interested:
> 
>     1. In tutorial2_osg.py, start with the camera further away from the
>        blocks and facing them.
>     2. In tutoiral3_osg.py, add a little more light and colour the base
>        plane.
> 
> > Also attached is the file named tutorial3_osg_segfault.py.  This file will crash when you
> > run it because it seems that if more than 34 bodies collide at once (at least on the first
> > frame if they are all intersecting), then pyODE will crash by segmentation fault.
> 
> After testing it on my computer, it segfaults if here are more than 68
> objects. I've done some looking but I can't work out what's causing it.
> The segfault occurs in world.step() or world.quickStep(). My
> investigation found two potential problems:
> 
> 1. Body.setMass() takes a Mass object argument. It doesn't keep a
> reference to it but uses its dMass Mass._mass for dBodySetMass(dBodyID,
> const dMass *mass). If the Mass object is deallocated, ODE could still
> try to access it.
> 
> 2. ContactJoint uses Contact objects for ODE calls without keeping
> references. ODE might still try to access it even if the Contact object
> has been deallocated.
> 
> I'm not entirely sure if the above points are correct because none of
> the tutorials ever crash even though they could by the above mechanisms.
> Also, fixing them doesn't fix the segfault problem above.
> 
> What do you think?
> 
> -- 
> Timothy Stranex <ti...@st...>
> 

> ATTACHMENT part 2 application/pgp-signature name=signature.asc




		
_______________________________
Do you Yahoo!?
Declare Yourself - Register online to vote today!
http://vote.yahoo.com

Re: [Pyode-user] pyODE and PyOSG

[Matthias B. <ba...@ir...>]

Sorry for not replying earlier, I've been too busy once more...

Timothy Stranex wrote:
>>Also attached is the file named tutorial3_osg_segfault.py.  This file will crash when you
>>run it because it seems that if more than 34 bodies collide at once (at least on the first
>>frame if they are all intersecting), then pyODE will crash by segmentation fault.
> 
> After testing it on my computer, it segfaults if here are more than 68
> objects. I've done some looking but I can't work out what's causing it.
> The segfault occurs in world.step() or world.quickStep(). My
> investigation found two potential problems:
> 
> 1. Body.setMass() takes a Mass object argument. It doesn't keep a
> reference to it but uses its dMass Mass._mass for dBodySetMass(dBodyID,
> const dMass *mass). If the Mass object is deallocated, ODE could still
> try to access it.
> 
> 2. ContactJoint uses Contact objects for ODE calls without keeping
> references. ODE might still try to access it even if the Contact object
> has been deallocated.

The mass properties and the contact structure are copied when calling 
dBodySetMass()/dJointCreateContact(), so ODE won't access the original 
data after the calls. So that's not the problem.

As I haven't PyOSG running on Windows, I just stripped away the PyOSG 
stuff and could also run the file. It crashes as well when using more 
than 32 bodies (or more than 9 bodies if I use step() instead of 
quickstep()).
I counted the contact joints that are generated in the near_callback() 
function and once there are more than about 2000 contacts the 
dWorldQuickStep() function will crash (dWorldStep() already crashes once 
there are more than 120 contacts). So far, I'd say the bug is in ODE, 
not PyODE.

Maybe this is the stack size issue that occasionally comes up in the ODE 
mailing list? Could it be that the stack overflows when the number of 
contacts gets too large?

- Matthias -

PS: Concerning PyOSG on Windows.... I did a test with a simple Pyrex 
file and Visual Studio .NET to see if the compiled module will be 
accepted by Python. I was using the distutils to compile the module and 
when calling the setup script, it complained about the compiler version. 
  So it seems if you want to run PyOSG on Windows you also have to 
compile Python yourself (unless it's possible either to compile OSG with 
VC6 or to use the OSG binaries with VC6).

But at least I could run some PyOSG demos with the CD image that Brett 
has provided. :) (unfortunately, the 3D output doesn't seem to be 
hardware accelerated)