pyode-user — PyODE User Discussions

Re: [Pyode-user] Fix for bug 1854241

[Ethan Glasser-C. <gl...@cs...>]

On 05/31/2010 03:39 AM, Alexandru Dumitrache wrote:
> Hello,
>
> Here is a quick fix for the following bug:
>
> Mass.setSphereTotal wraps wrong function - ID: 1854241
>    

Hi, sorry for the epically late response. I just applied this patch. Thanks!

Ethan

Re: [Pyode-user] Problem with PyODE object deallocation and XODE changes

[Ethan Glasser-C. <gl...@cs...>]

On 08/04/2010 07:03 AM, John Glover wrote:
> I have code that can reproduce it on OS X 10.5 with Python 2.6.5, but
> the same code doesn't crash with the same Python version on Ubuntu, so
> it could be something strange with Python garbage collection on the
> Mac. However, the following minor fix sorts the problem out, so I was
> hoping that it would be possible to get it checked in, unless someone
> has an alternative.
>    

Hi. Is it possible for you to resend these patches as unified diff (diff 
-u) and as attachments? I'll check them in for you.

Ethan

Re: [Pyode-user] Declarations

[Ethan Glasser-C. <gl...@cs...>]

On 05/31/2010 05:37 AM, Alexandru Dumitrache wrote:
> Here is a small step in this direction. This is a script which parses object.h
> (and also mass.h)
> and then searches each ODE_API function in PyODE source code.
>    

Hi,

I committed this script to git (in the "examples" directory). Thanks!

Ethan

Re: [Pyode-user] tutorial3: dInitODE() or similar

[Ethan Glasser-C. <gl...@cs...>]

On 09/23/2010 12:02 PM, Joshua R. Davis wrote:
> Hi,
>
> I apologize if this is a FAQ; it shows up a bit on Google, but without resolution, and I can't find it in this list's archives. When I execute tutorial3.py, I get these errors:
>
> ODE INTERNAL ERROR 2: Please call ODE initialization (dInitODE() or similar) before using the library in dCollide()
> Abort trap
>
> My setup is PyODE 1.2.0 on Python 2.6.x on Mac OS 10.6. The PyODE module does not have dInitODE or dInitODE2.
>    

Hi,

Good question :) The response is "try a newer PyODE". I'm not sure where 
you got your version of PyODE, but there's a git snapshot on sourceforge 
that should have dInitODE.

HTH,

Ethan

Re: [Pyode-user] tutorial 1 not behaving the same regarding the value of the dt variable

[Ethan Glasser-C. <gl...@cs...>]

On 08/08/2010 08:47 AM, Roland Everaert wrote:
>    Hello,
>
> I am currently testing the pyode library with pygame and pyOpenGL and I
> am quite surprised that the behavior of the tutorial 1 code is not the
> same if dt differ from 0.04.
>
> Why when dt is greater than 0.04 the body goes higher and why is it go
> lower if smaller than 0.04. Or in other word, why the step() method
> influence the computation of the position like the gravity is higher
> with small step and lower when step are big?
>    

I believe this is an artifact of how forces are applied. If you replace 
the call to body.addForce with one to body.setLinearVel, the two 
simulations behave "identically" (every fourth step when dv=0.01 is 
exactly the same as the corresponding step when dv=0.04).

I do not know why applying the force should count "more" if dv is 
larger, but I don't think it's a pyode issue. In case you haven't 
already, you might consider asking on vanilla ODE mailing lists/fora.

Ethan

[Pyode-user] tutorial3: dInitODE() or similar

[Joshua R. D. <joshuardavis@q.com>]

Hi,

I apologize if this is a FAQ; it shows up a bit on Google, but without resolution, and I can't find it in this list's archives. When I execute tutorial3.py, I get these errors:

ODE INTERNAL ERROR 2: Please call ODE initialization (dInitODE() or similar) before using the library in dCollide()
Abort trap

My setup is PyODE 1.2.0 on Python 2.6.x on Mac OS 10.6. The PyODE module does not have dInitODE or dInitODE2.

Josh
Joshua R. Davis    joshuardavis@q.com

[Pyode-user] tutorial 1 not behaving the same regarding the value of the dt variable

[Roland E. <r.e...@gm...>]

  Hello,

I am currently testing the pyode library with pygame and pyOpenGL and I 
am quite surprised that the behavior of the tutorial 1 code is not the 
same if dt differ from 0.04.

Why when dt is greater than 0.04 the body goes higher and why is it go 
lower if smaller than 0.04. Or in other word, why the step() method 
influence the computation of the position like the gravity is higher 
with small step and lower when step are big?

Below is an example of the output when using small steps:

Tick 0.01
0.00sec: pos=( 0.000,  2.000,  0.000)  vel=( 0.000,  0.000,  0.000)
Tick 0.018
0.01sec: pos=( 0.000,  2.019,  0.000)  vel=( 0.000,  1.902,  0.000)
Tick 0.01
0.03sec: pos=( 0.000,  2.050,  0.000)  vel=( 0.000,  1.725,  0.000)
Tick 0.011
0.04sec: pos=( 0.000,  2.066,  0.000)  vel=( 0.000,  1.627,  0.000)
Tick 0.01
0.05sec: pos=( 0.000,  2.083,  0.000)  vel=( 0.000,  1.519,  0.000)
Tick 0.01
0.06sec: pos=( 0.000,  2.097,  0.000)  vel=( 0.000,  1.421,  0.000)
Tick 0.01
0.07sec: pos=( 0.000,  2.111,  0.000)  vel=( 0.000,  1.323,  0.000)
Tick 0.01
0.08sec: pos=( 0.000,  2.123,  0.000)  vel=( 0.000,  1.225,  0.000)
Tick 0.01
0.09sec: pos=( 0.000,  2.134,  0.000)  vel=( 0.000,  1.127,  0.000)
Tick 0.01
0.10sec: pos=( 0.000,  2.144,  0.000)  vel=( 0.000,  1.029,  0.000)
Tick 0.01
0.11sec: pos=( 0.000,  2.154,  0.000)  vel=( 0.000,  0.931,  0.000)
Tick 0.011
0.12sec: pos=( 0.000,  2.162,  0.000)  vel=( 0.000,  0.833,  0.000)
Tick 0.01
0.13sec: pos=( 0.000,  2.170,  0.000)  vel=( 0.000,  0.725,  0.000)
Tick 0.01
0.14sec: pos=( 0.000,  2.176,  0.000)  vel=( 0.000,  0.627,  0.000)
Tick 0.01
0.15sec: pos=( 0.000,  2.181,  0.000)  vel=( 0.000,  0.529,  0.000)
Tick 0.01
0.16sec: pos=( 0.000,  2.186,  0.000)  vel=( 0.000,  0.430,  0.000)
Tick 0.01
0.17sec: pos=( 0.000,  2.189,  0.000)  vel=( 0.000,  0.332,  0.000)
Tick 0.011
0.18sec: pos=( 0.000,  2.191,  0.000)  vel=( 0.000,  0.234,  0.000)
Tick 0.01
0.19sec: pos=( 0.000,  2.193,  0.000)  vel=( 0.000,  0.126,  0.000)
Tick 0.01
0.20sec: pos=( 0.000,  2.193,  0.000)  vel=( 0.000,  0.028,  0.000)
Tick 0.01
0.21sec: pos=( 0.000,  2.192,  0.000)  vel=( 0.000, -0.070,  0.000)
Tick 0.01
0.22sec: pos=( 0.000,  2.191,  0.000)  vel=( 0.000, -0.168,  0.000)
Tick 0.01
0.23sec: pos=( 0.000,  2.188,  0.000)  vel=( 0.000, -0.266,  0.000)
Tick 0.01
0.24sec: pos=( 0.000,  2.184,  0.000)  vel=( 0.000, -0.364,  0.000)
Tick 0.01
0.25sec: pos=( 0.000,  2.180,  0.000)  vel=( 0.000, -0.462,  0.000)
Tick 0.01
0.26sec: pos=( 0.000,  2.174,  0.000)  vel=( 0.000, -0.560,  0.000)
Tick 0.01
0.27sec: pos=( 0.000,  2.168,  0.000)  vel=( 0.000, -0.659,  0.000)
Tick 0.01
0.28sec: pos=( 0.000,  2.160,  0.000)  vel=( 0.000, -0.757,  0.000)
Tick 0.01
0.29sec: pos=( 0.000,  2.151,  0.000)  vel=( 0.000, -0.855,  0.000)
Tick 0.01
0.30sec: pos=( 0.000,  2.142,  0.000)  vel=( 0.000, -0.953,  0.000)
Tick 0.01
0.31sec: pos=( 0.000,  2.131,  0.000)  vel=( 0.000, -1.051,  0.000)
Tick 0.01
0.32sec: pos=( 0.000,  2.120,  0.000)  vel=( 0.000, -1.149,  0.000)
Tick 0.01
0.33sec: pos=( 0.000,  2.107,  0.000)  vel=( 0.000, -1.247,  0.000)
Tick 0.01
0.34sec: pos=( 0.000,  2.094,  0.000)  vel=( 0.000, -1.345,  0.000)
Tick 0.01
0.35sec: pos=( 0.000,  2.080,  0.000)  vel=( 0.000, -1.443,  0.000)
Tick 0.01
0.36sec: pos=( 0.000,  2.064,  0.000)  vel=( 0.000, -1.541,  0.000)
Tick 0.01
0.37sec: pos=( 0.000,  2.048,  0.000)  vel=( 0.000, -1.640,  0.000)
Tick 0.01
0.38sec: pos=( 0.000,  2.030,  0.000)  vel=( 0.000, -1.738,  0.000)
Tick 0.01
0.39sec: pos=( 0.000,  2.012,  0.000)  vel=( 0.000, -1.836,  0.000)
Tick 0.01
0.40sec: pos=( 0.000,  1.993,  0.000)  vel=( 0.000, -1.934,  0.000)
Tick 0.011
0.41sec: pos=( 0.000,  1.972,  0.000)  vel=( 0.000, -2.032,  0.000)
Tick 0.01
0.42sec: pos=( 0.000,  1.949,  0.000)  vel=( 0.000, -2.140,  0.000)
Tick 0.01
0.43sec: pos=( 0.000,  1.926,  0.000)  vel=( 0.000, -2.238,  0.000)
Tick 0.01
0.44sec: pos=( 0.000,  1.903,  0.000)  vel=( 0.000, -2.336,  0.000)
Tick 0.01
0.45sec: pos=( 0.000,  1.879,  0.000)  vel=( 0.000, -2.434,  0.000)
Tick 0.01
0.46sec: pos=( 0.000,  1.853,  0.000)  vel=( 0.000, -2.532,  0.000)
Tick 0.01
0.47sec: pos=( 0.000,  1.827,  0.000)  vel=( 0.000, -2.630,  0.000)
Tick 0.01
0.48sec: pos=( 0.000,  1.800,  0.000)  vel=( 0.000, -2.728,  0.000)
Tick 0.01
0.49sec: pos=( 0.000,  1.772,  0.000)  vel=( 0.000, -2.827,  0.000)
Tick 0.01
0.50sec: pos=( 0.000,  1.742,  0.000)  vel=( 0.000, -2.925,  0.000)
Tick 0.01
0.51sec: pos=( 0.000,  1.712,  0.000)  vel=( 0.000, -3.023,  0.000)
Tick 0.01
0.52sec: pos=( 0.000,  1.681,  0.000)  vel=( 0.000, -3.121,  0.000)
Tick 0.01
0.53sec: pos=( 0.000,  1.649,  0.000)  vel=( 0.000, -3.219,  0.000)
Tick 0.01
0.54sec: pos=( 0.000,  1.616,  0.000)  vel=( 0.000, -3.317,  0.000)
Tick 0.01
0.55sec: pos=( 0.000,  1.581,  0.000)  vel=( 0.000, -3.415,  0.000)
Tick 0.01
0.56sec: pos=( 0.000,  1.546,  0.000)  vel=( 0.000, -3.513,  0.000)
Tick 0.01
0.57sec: pos=( 0.000,  1.510,  0.000)  vel=( 0.000, -3.611,  0.000)
Tick 0.01
0.58sec: pos=( 0.000,  1.473,  0.000)  vel=( 0.000, -3.709,  0.000)
Tick 0.01
0.59sec: pos=( 0.000,  1.435,  0.000)  vel=( 0.000, -3.808,  0.000)
Tick 0.01
0.60sec: pos=( 0.000,  1.396,  0.000)  vel=( 0.000, -3.906,  0.000)
Tick 0.01
0.61sec: pos=( 0.000,  1.356,  0.000)  vel=( 0.000, -4.004,  0.000)
Tick 0.009
0.62sec: pos=( 0.000,  1.315,  0.000)  vel=( 0.000, -4.102,  0.000)
Tick 0.01
0.63sec: pos=( 0.000,  1.277,  0.000)  vel=( 0.000, -4.190,  0.000)
Tick 0.01
0.64sec: pos=( 0.000,  1.234,  0.000)  vel=( 0.000, -4.288,  0.000)
Tick 0.011
0.65sec: pos=( 0.000,  1.190,  0.000)  vel=( 0.000, -4.386,  0.000)
Tick 0.01
0.66sec: pos=( 0.000,  1.141,  0.000)  vel=( 0.000, -4.494,  0.000)
Tick 0.01
0.67sec: pos=( 0.000,  1.095,  0.000)  vel=( 0.000, -4.592,  0.000)
Tick 0.01
0.68sec: pos=( 0.000,  1.048,  0.000)  vel=( 0.000, -4.690,  0.000)
Tick 0.011
0.69sec: pos=( 0.000,  1.000,  0.000)  vel=( 0.000, -4.789,  0.000)
Tick 0.01
0.70sec: pos=( 0.000,  0.946,  0.000)  vel=( 0.000, -4.896,  0.000)
Tick 0.01
0.71sec: pos=( 0.000,  0.896,  0.000)  vel=( 0.000, -4.995,  0.000)
Tick 0.01
0.72sec: pos=( 0.000,  0.846,  0.000)  vel=( 0.000, -5.093,  0.000)
Tick 0.01
0.73sec: pos=( 0.000,  0.794,  0.000)  vel=( 0.000, -5.191,  0.000)
Tick 0.01
0.74sec: pos=( 0.000,  0.741,  0.000)  vel=( 0.000, -5.289,  0.000)
Tick 0.01
0.75sec: pos=( 0.000,  0.687,  0.000)  vel=( 0.000, -5.387,  0.000)
Tick 0.01
0.76sec: pos=( 0.000,  0.632,  0.000)  vel=( 0.000, -5.485,  0.000)
Tick 0.01
0.77sec: pos=( 0.000,  0.576,  0.000)  vel=( 0.000, -5.583,  0.000)
Tick 0.011
0.78sec: pos=( 0.000,  0.519,  0.000)  vel=( 0.000, -5.681,  0.000)
Tick 0.01
0.79sec: pos=( 0.000,  0.456,  0.000)  vel=( 0.000, -5.789,  0.000)
Tick 0.01
0.80sec: pos=( 0.000,  0.397,  0.000)  vel=( 0.000, -5.887,  0.000)
Tick 0.01
0.81sec: pos=( 0.000,  0.337,  0.000)  vel=( 0.000, -5.985,  0.000)
Tick 0.01
0.82sec: pos=( 0.000,  0.276,  0.000)  vel=( 0.000, -6.083,  0.000)
Tick 0.01
0.83sec: pos=( 0.000,  0.214,  0.000)  vel=( 0.000, -6.182,  0.000)
Tick 0.01
0.84sec: pos=( 0.000,  0.152,  0.000)  vel=( 0.000, -6.280,  0.000)
Tick 0.01
0.85sec: pos=( 0.000,  0.088,  0.000)  vel=( 0.000, -6.378,  0.000)
Tick 0.01
0.86sec: pos=( 0.000,  0.023,  0.000)  vel=( 0.000, -6.476,  0.000)
Tick 0.01
0.87sec: pos=( 0.000, -0.043,  0.000)  vel=( 0.000, -6.574,  0.000)
Tick 0.01
0.88sec: pos=( 0.000, -0.109,  0.000)  vel=( 0.000, -6.672,  0.000)
Tick 0.01
0.89sec: pos=( 0.000, -0.177,  0.000)  vel=( 0.000, -6.770,  0.000)
Tick 0.01
0.90sec: pos=( 0.000, -0.246,  0.000)  vel=( 0.000, -6.868,  0.000)
Tick 0.011
0.91sec: pos=( 0.000, -0.315,  0.000)  vel=( 0.000, -6.966,  0.000)
Tick 0.01
0.93sec: pos=( 0.000, -0.393,  0.000)  vel=( 0.000, -7.074,  0.000)
Tick 0.01
0.94sec: pos=( 0.000, -0.465,  0.000)  vel=( 0.000, -7.172,  0.000)
Tick 0.01
0.95sec: pos=( 0.000, -0.538,  0.000)  vel=( 0.000, -7.270,  0.000)
Tick 0.01
0.96sec: pos=( 0.000, -0.611,  0.000)  vel=( 0.000, -7.369,  0.000)
Tick 0.01
0.97sec: pos=( 0.000, -0.686,  0.000)  vel=( 0.000, -7.467,  0.000)
Tick 0.01
0.98sec: pos=( 0.000, -0.762,  0.000)  vel=( 0.000, -7.565,  0.000)
Tick 0.011
0.99sec: pos=( 0.000, -0.838,  0.000)  vel=( 0.000, -7.663,  0.000)
Tick 0.01
1.00sec: pos=( 0.000, -0.924,  0.000)  vel=( 0.000, -7.771,  0.000)
Tick 0.01
1.01sec: pos=( 0.000, -1.003,  0.000)  vel=( 0.000, -7.869,  0.000)
Tick 0.01
1.02sec: pos=( 0.000, -1.082,  0.000)  vel=( 0.000, -7.967,  0.000)
Tick 0.01
1.03sec: pos=( 0.000, -1.163,  0.000)  vel=( 0.000, -8.065,  0.000)
Tick 0.011
1.04sec: pos=( 0.000, -1.244,  0.000)  vel=( 0.000, -8.163,  0.000)
Tick 0.01
1.05sec: pos=( 0.000, -1.335,  0.000)  vel=( 0.000, -8.271,  0.000)
Tick 0.01
1.06sec: pos=( 0.000, -1.419,  0.000)  vel=( 0.000, -8.369,  0.000)
Tick 0.01
1.07sec: pos=( 0.000, -1.504,  0.000)  vel=( 0.000, -8.467,  0.000)
Tick 0.01
1.08sec: pos=( 0.000, -1.589,  0.000)  vel=( 0.000, -8.565,  0.000)
Tick 0.01
1.09sec: pos=( 0.000, -1.676,  0.000)  vel=( 0.000, -8.663,  0.000)
Tick 0.01
1.10sec: pos=( 0.000, -1.764,  0.000)  vel=( 0.000, -8.762,  0.000)
Tick 0.01
1.11sec: pos=( 0.000, -1.852,  0.000)  vel=( 0.000, -8.860,  0.000)
Tick 0.01
1.12sec: pos=( 0.000, -1.942,  0.000)  vel=( 0.000, -8.958,  0.000)
Tick 0.01
1.13sec: pos=( 0.000, -2.032,  0.000)  vel=( 0.000, -9.056,  0.000)
Tick 0.01
1.14sec: pos=( 0.000, -2.124,  0.000)  vel=( 0.000, -9.154,  0.000)
Tick 0.01
1.15sec: pos=( 0.000, -2.217,  0.000)  vel=( 0.000, -9.252,  0.000)
Tick 0.01
1.16sec: pos=( 0.000, -2.310,  0.000)  vel=( 0.000, -9.350,  0.000)
Tick 0.01
1.17sec: pos=( 0.000, -2.405,  0.000)  vel=( 0.000, -9.448,  0.000)
Tick 0.01
1.18sec: pos=( 0.000, -2.500,  0.000)  vel=( 0.000, -9.546,  0.000)
Tick 0.01
1.19sec: pos=( 0.000, -2.596,  0.000)  vel=( 0.000, -9.644,  0.000)
Tick 0.01
1.20sec: pos=( 0.000, -2.694,  0.000)  vel=( 0.000, -9.743,  0.000)
Tick 0.01
1.21sec: pos=( 0.000, -2.792,  0.000)  vel=( 0.000, -9.841,  0.000)
Tick 0.01
1.22sec: pos=( 0.000, -2.892,  0.000)  vel=( 0.000, -9.939,  0.000)
Tick 0.01
1.23sec: pos=( 0.000, -2.992,  0.000)  vel=( 0.000, -10.037,  0.000)
Tick 0.01
1.24sec: pos=( 0.000, -3.093,  0.000)  vel=( 0.000, -10.135,  0.000)
Tick 0.01
1.25sec: pos=( 0.000, -3.196,  0.000)  vel=( 0.000, -10.233,  0.000)
Tick 0.01
1.26sec: pos=( 0.000, -3.299,  0.000)  vel=( 0.000, -10.331,  0.000)
Tick 0.011
1.27sec: pos=( 0.000, -3.403,  0.000)  vel=( 0.000, -10.429,  0.000)
Tick 0.01
1.28sec: pos=( 0.000, -3.519,  0.000)  vel=( 0.000, -10.537,  0.000)
Tick 0.01
1.29sec: pos=( 0.000, -3.626,  0.000)  vel=( 0.000, -10.635,  0.000)
Tick 0.01
1.30sec: pos=( 0.000, -3.733,  0.000)  vel=( 0.000, -10.733,  0.000)
Tick 0.01
1.31sec: pos=( 0.000, -3.841,  0.000)  vel=( 0.000, -10.831,  0.000)
Tick 0.01
1.32sec: pos=( 0.000, -3.950,  0.000)  vel=( 0.000, -10.930,  0.000)
Tick 0.01
1.33sec: pos=( 0.000, -4.061,  0.000)  vel=( 0.000, -11.028,  0.000)
Tick 0.01
1.34sec: pos=( 0.000, -4.172,  0.000)  vel=( 0.000, -11.126,  0.000)
Tick 0.01
1.35sec: pos=( 0.000, -4.284,  0.000)  vel=( 0.000, -11.224,  0.000)
Tick 0.01
1.36sec: pos=( 0.000, -4.397,  0.000)  vel=( 0.000, -11.322,  0.000)
Tick 0.01
1.37sec: pos=( 0.000, -4.512,  0.000)  vel=( 0.000, -11.420,  0.000)
Tick 0.01
1.38sec: pos=( 0.000, -4.627,  0.000)  vel=( 0.000, -11.518,  0.000)
Tick 0.01
1.39sec: pos=( 0.000, -4.743,  0.000)  vel=( 0.000, -11.616,  0.000)
Tick 0.01
1.40sec: pos=( 0.000, -4.860,  0.000)  vel=( 0.000, -11.714,  0.000)
Tick 0.01
1.41sec: pos=( 0.000, -4.978,  0.000)  vel=( 0.000, -11.812,  0.000)
Tick 0.01
1.42sec: pos=( 0.000, -5.097,  0.000)  vel=( 0.000, -11.911,  0.000)
Tick 0.01
1.43sec: pos=( 0.000, -5.217,  0.000)  vel=( 0.000, -12.009,  0.000)
Tick 0.01
1.44sec: pos=( 0.000, -5.339,  0.000)  vel=( 0.000, -12.107,  0.000)
Tick 0.01
1.45sec: pos=( 0.000, -5.461,  0.000)  vel=( 0.000, -12.205,  0.000)
Tick 0.01
1.46sec: pos=( 0.000, -5.584,  0.000)  vel=( 0.000, -12.303,  0.000)
Tick 0.01
1.47sec: pos=( 0.000, -5.708,  0.000)  vel=( 0.000, -12.401,  0.000)
Tick 0.01
1.48sec: pos=( 0.000, -5.833,  0.000)  vel=( 0.000, -12.499,  0.000)
Tick 0.01
1.49sec: pos=( 0.000, -5.959,  0.000)  vel=( 0.000, -12.597,  0.000)
Tick 0.011
1.50sec: pos=( 0.000, -6.086,  0.000)  vel=( 0.000, -12.695,  0.000)
Tick 0.01
1.51sec: pos=( 0.000, -6.226,  0.000)  vel=( 0.000, -12.803,  0.000)
Tick 0.01
1.52sec: pos=( 0.000, -6.355,  0.000)  vel=( 0.000, -12.901,  0.000)
Tick 0.01
1.53sec: pos=( 0.000, -6.485,  0.000)  vel=( 0.000, -12.999,  0.000)
Tick 0.01
1.54sec: pos=( 0.000, -6.616,  0.000)  vel=( 0.000, -13.098,  0.000)
Tick 0.01
1.55sec: pos=( 0.000, -6.748,  0.000)  vel=( 0.000, -13.196,  0.000)
Tick 0.01
1.56sec: pos=( 0.000, -6.881,  0.000)  vel=( 0.000, -13.294,  0.000)
Tick 0.01
1.57sec: pos=( 0.000, -7.015,  0.000)  vel=( 0.000, -13.392,  0.000)
Tick 0.01
1.58sec: pos=( 0.000, -7.150,  0.000)  vel=( 0.000, -13.490,  0.000)
Tick 0.01
1.59sec: pos=( 0.000, -7.286,  0.000)  vel=( 0.000, -13.588,  0.000)
Tick 0.01
1.60sec: pos=( 0.000, -7.423,  0.000)  vel=( 0.000, -13.686,  0.000)
Tick 0.01
1.61sec: pos=( 0.000, -7.561,  0.000)  vel=( 0.000, -13.784,  0.000)
Tick 0.01
1.62sec: pos=( 0.000, -7.700,  0.000)  vel=( 0.000, -13.882,  0.000)
Tick 0.01
1.63sec: pos=( 0.000, -7.839,  0.000)  vel=( 0.000, -13.980,  0.000)
Tick 0.01
1.64sec: pos=( 0.000, -7.980,  0.000)  vel=( 0.000, -14.079,  0.000)
Tick 0.01
1.65sec: pos=( 0.000, -8.122,  0.000)  vel=( 0.000, -14.177,  0.000)
Tick 0.01
1.66sec: pos=( 0.000, -8.265,  0.000)  vel=( 0.000, -14.275,  0.000)
Tick 0.01
1.67sec: pos=( 0.000, -8.408,  0.000)  vel=( 0.000, -14.373,  0.000)
Tick 0.01
1.68sec: pos=( 0.000, -8.553,  0.000)  vel=( 0.000, -14.471,  0.000)
Tick 0.01
1.69sec: pos=( 0.000, -8.699,  0.000)  vel=( 0.000, -14.569,  0.000)
Tick 0.01
1.70sec: pos=( 0.000, -8.845,  0.000)  vel=( 0.000, -14.667,  0.000)
Tick 0.01
1.71sec: pos=( 0.000, -8.993,  0.000)  vel=( 0.000, -14.765,  0.000)
Tick 0.01
1.72sec: pos=( 0.000, -9.142,  0.000)  vel=( 0.000, -14.863,  0.000)
Tick 0.01
1.73sec: pos=( 0.000, -9.291,  0.000)  vel=( 0.000, -14.961,  0.000)
Tick 0.011
1.74sec: pos=( 0.000, -9.442,  0.000)  vel=( 0.000, -15.060,  0.000)
Tick 0.01
1.75sec: pos=( 0.000, -9.609,  0.000)  vel=( 0.000, -15.167,  0.000)
Tick 0.01
1.76sec: pos=( 0.000, -9.761,  0.000)  vel=( 0.000, -15.266,  0.000)
Tick 0.01
1.77sec: pos=( 0.000, -9.915,  0.000)  vel=( 0.000, -15.364,  0.000)
Tick 0.01
1.78sec: pos=( 0.000, -10.070,  0.000)  vel=( 0.000, -15.462,  0.000)
Tick 0.01
1.79sec: pos=( 0.000, -10.225,  0.000)  vel=( 0.000, -15.560,  0.000)
Tick 0.01
1.80sec: pos=( 0.000, -10.382,  0.000)  vel=( 0.000, -15.658,  0.000)
Tick 0.01
1.81sec: pos=( 0.000, -10.539,  0.000)  vel=( 0.000, -15.756,  0.000)
Tick 0.01
1.82sec: pos=( 0.000, -10.698,  0.000)  vel=( 0.000, -15.854,  0.000)
Tick 0.01
1.83sec: pos=( 0.000, -10.857,  0.000)  vel=( 0.000, -15.952,  0.000)
Tick 0.011
1.84sec: pos=( 0.000, -11.018,  0.000)  vel=( 0.000, -16.050,  0.000)
Tick 0.01
1.85sec: pos=( 0.000, -11.196,  0.000)  vel=( 0.000, -16.158,  0.000)
Tick 0.01
1.86sec: pos=( 0.000, -11.358,  0.000)  vel=( 0.000, -16.256,  0.000)
Tick 0.01
1.87sec: pos=( 0.000, -11.522,  0.000)  vel=( 0.000, -16.354,  0.000)
Tick 0.01
1.88sec: pos=( 0.000, -11.686,  0.000)  vel=( 0.000, -16.453,  0.000)
Tick 0.011
1.89sec: pos=( 0.000, -11.852,  0.000)  vel=( 0.000, -16.551,  0.000)
Tick 0.01
1.90sec: pos=( 0.000, -12.035,  0.000)  vel=( 0.000, -16.659,  0.000)
Tick 0.01
1.91sec: pos=( 0.000, -12.203,  0.000)  vel=( 0.000, -16.757,  0.000)
Tick 0.01
1.92sec: pos=( 0.000, -12.371,  0.000)  vel=( 0.000, -16.855,  0.000)
Tick 0.01
1.93sec: pos=( 0.000, -12.541,  0.000)  vel=( 0.000, -16.953,  0.000)
Tick 0.01
1.94sec: pos=( 0.000, -12.711,  0.000)  vel=( 0.000, -17.051,  0.000)
Tick 0.01
1.95sec: pos=( 0.000, -12.883,  0.000)  vel=( 0.000, -17.149,  0.000)
Tick 0.01
1.96sec: pos=( 0.000, -13.055,  0.000)  vel=( 0.000, -17.247,  0.000)
Tick 0.01
1.97sec: pos=( 0.000, -13.229,  0.000)  vel=( 0.000, -17.345,  0.000)
Tick 0.01
1.98sec: pos=( 0.000, -13.403,  0.000)  vel=( 0.000, -17.443,  0.000)
Tick 0.01
1.99sec: pos=( 0.000, -13.579,  0.000)  vel=( 0.000, -17.542,  0.000)
Tick 0.01
2.00sec: pos=( 0.000, -13.755,  0.000)  vel=( 0.000, -17.640,  0.000)
Tick 0.01
2.01sec: pos=( 0.000, -13.932,  0.000)  vel=( 0.000, -17.738,  0.000)
Tick 0.01
2.02sec: pos=( 0.000, -14.111,  0.000)  vel=( 0.000, -17.836,  0.000)
Tick 0.011
2.03sec: pos=( 0.000, -14.290,  0.000)  vel=( 0.000, -17.934,  0.000)
Tick 0.01
2.04sec: pos=( 0.000, -14.488,  0.000)  vel=( 0.000, -18.042,  0.000)
Tick 0.01
2.05sec: pos=( 0.000, -14.670,  0.000)  vel=( 0.000, -18.140,  0.000)
Tick 0.01
2.06sec: pos=( 0.000, -14.852,  0.000)  vel=( 0.000, -18.238,  0.000)
Tick 0.01
2.07sec: pos=( 0.000, -15.036,  0.000)  vel=( 0.000, -18.336,  0.000)
Tick 0.01
2.08sec: pos=( 0.000, -15.220,  0.000)  vel=( 0.000, -18.434,  0.000)
Tick 0.01
2.09sec: pos=( 0.000, -15.405,  0.000)  vel=( 0.000, -18.532,  0.000)
Tick 0.011
2.10sec: pos=( 0.000, -15.592,  0.000)  vel=( 0.000, -18.630,  0.000)
Tick 0.01
2.11sec: pos=( 0.000, -15.798,  0.000)  vel=( 0.000, -18.738,  0.000)
Tick 0.011
2.12sec: pos=( 0.000, -15.986,  0.000)  vel=( 0.000, -18.836,  0.000)
Tick 0.01
2.13sec: pos=( 0.000, -16.194,  0.000)  vel=( 0.000, -18.944,  0.000)
Tick 0.01
2.14sec: pos=( 0.000, -16.385,  0.000)  vel=( 0.000, -19.042,  0.000)
Tick 0.01
2.15sec: pos=( 0.000, -16.576,  0.000)  vel=( 0.000, -19.141,  0.000)
Tick 0.01
2.16sec: pos=( 0.000, -16.769,  0.000)  vel=( 0.000, -19.239,  0.000)
Tick 0.01
2.17sec: pos=( 0.000, -16.962,  0.000)  vel=( 0.000, -19.337,  0.000)
Tick 0.01
2.18sec: pos=( 0.000, -17.156,  0.000)  vel=( 0.000, -19.435,  0.000)
Tick 0.01
2.19sec: pos=( 0.000, -17.352,  0.000)  vel=( 0.000, -19.533,  0.000)
Tick 0.01
2.20sec: pos=( 0.000, -17.548,  0.000)  vel=( 0.000, -19.631,  0.000)
Tick 0.01
2.21sec: pos=( 0.000, -17.745,  0.000)  vel=( 0.000, -19.729,  0.000)
Tick 0.01
2.22sec: pos=( 0.000, -17.944,  0.000)  vel=( 0.000, -19.827,  0.000)
Tick 0.01
2.23sec: pos=( 0.000, -18.143,  0.000)  vel=( 0.000, -19.925,  0.000)
Tick 0.01
2.24sec: pos=( 0.000, -18.343,  0.000)  vel=( 0.000, -20.023,  0.000)
Tick 0.011
2.25sec: pos=( 0.000, -18.544,  0.000)  vel=( 0.000, -20.122,  0.000)
Tick 0.01
2.27sec: pos=( 0.000, -18.767,  0.000)  vel=( 0.000, -20.229,  0.000)
Tick 0.01
2.28sec: pos=( 0.000, -18.970,  0.000)  vel=( 0.000, -20.328,  0.000)
Tick 0.01
2.29sec: pos=( 0.000, -19.174,  0.000)  vel=( 0.000, -20.426,  0.000)
Tick 0.011
2.30sec: pos=( 0.000, -19.380,  0.000)  vel=( 0.000, -20.524,  0.000)
Tick 0.01
2.31sec: pos=( 0.000, -19.607,  0.000)  vel=( 0.000, -20.632,  0.000)
Tick 0.011
2.32sec: pos=( 0.000, -19.814,  0.000)  vel=( 0.000, -20.730,  0.000)
Tick 0.01
2.33sec: pos=( 0.000, -20.043,  0.000)  vel=( 0.000, -20.838,  0.000)
Tick 0.01
2.34sec: pos=( 0.000, -20.252,  0.000)  vel=( 0.000, -20.936,  0.000)
Tick 0.01
2.35sec: pos=( 0.000, -20.463,  0.000)  vel=( 0.000, -21.034,  0.000)
Tick 0.01
2.36sec: pos=( 0.000, -20.674,  0.000)  vel=( 0.000, -21.132,  0.000)
Tick 0.01
2.37sec: pos=( 0.000, -20.886,  0.000)  vel=( 0.000, -21.230,  0.000)
Tick 0.01
2.38sec: pos=( 0.000, -21.100,  0.000)  vel=( 0.000, -21.328,  0.000)
Tick 0.01
2.39sec: pos=( 0.000, -21.314,  0.000)  vel=( 0.000, -21.426,  0.000)
Tick 0.011
2.40sec: pos=( 0.000, -21.529,  0.000)  vel=( 0.000, -21.524,  0.000)
Tick 0.01
2.41sec: pos=( 0.000, -21.767,  0.000)  vel=( 0.000, -21.632,  0.000)
Tick 0.01
2.42sec: pos=( 0.000, -21.984,  0.000)  vel=( 0.000, -21.730,  0.000)
Tick 0.01
2.43sec: pos=( 0.000, -22.203,  0.000)  vel=( 0.000, -21.829,  0.000)
Tick 0.01
2.44sec: pos=( 0.000, -22.422,  0.000)  vel=( 0.000, -21.927,  0.000)
Tick 0.01
2.45sec: pos=( 0.000, -22.642,  0.000)  vel=( 0.000, -22.025,  0.000)
Tick 0.01
2.46sec: pos=( 0.000, -22.863,  0.000)  vel=( 0.000, -22.123,  0.000)
Tick 0.01
2.47sec: pos=( 0.000, -23.086,  0.000)  vel=( 0.000, -22.221,  0.000)
Tick 0.011
2.48sec: pos=( 0.000, -23.309,  0.000)  vel=( 0.000, -22.319,  0.000)
Tick 0.01
2.49sec: pos=( 0.000, -23.556,  0.000)  vel=( 0.000, -22.427,  0.000)
Tick 0.01
2.50sec: pos=( 0.000, -23.781,  0.000)  vel=( 0.000, -22.525,  0.000)
Tick 0.01
2.51sec: pos=( 0.000, -24.007,  0.000)  vel=( 0.000, -22.623,  0.000)
Tick 0.01
2.52sec: pos=( 0.000, -24.234,  0.000)  vel=( 0.000, -22.721,  0.000)

[Pyode-user] Problem with PyODE object deallocation and XODE changes

[John G. <glo...@gm...>]

Hello,

I'm working on a Google Summer of Code project on PaGMO
(http://sourceforge.net/apps/mediawiki/pagmo) where I need to
instantiate a large number of similar ODE worlds and objects running
in multithreaded environment. I ran into a problem with Python garbage
collection of some of the objects. Basically it seemed that sometimes
a world was being deallocated, calling dBodyDestroy and deallocating
memory for a body, but the Python object was still calling its own
dealloc and bodyDestroy (with a similar problem for Joints), and
crashing with a segmentation fault.

I have code that can reproduce it on OS X 10.5 with Python 2.6.5, but
the same code doesn't crash with the same Python version on Ubuntu, so
it could be something strange with Python garbage collection on the
Mac. However, the following minor fix sorts the problem out, so I was
hoping that it would be possible to get it checked in, unless someone
has an alternative.

cvs diff: Diffing src
Index: src/body.pyx
===================================================================
RCS file: /cvsroot/pyode/pyode/src/body.pyx,v
retrieving revision 1.8
diff -r1.8 body.pyx
59c59
<         if self.bid!=NULL:
---
>         if self.bid!=NULL and self.world:
Index: src/joints.pyx
===================================================================
RCS file: /cvsroot/pyode/pyode/src/joints.pyx,v
retrieving revision 1.14
diff -r1.14 joints.pyx
124c124
<         if self.jid!=NULL:
---
>         if self.jid!=NULL and self.world:

Also, I'm not sure if you are aware, but the PyBrain project
(http://pybrain.org/) has some small XODE additions, perhaps they
could also be included at some stage soon? Here's the diff:

cvs diff: Diffing xode
Index: xode/body.py
===================================================================
RCS file: /cvsroot/pyode/pyode/xode/body.py,v
retrieving revision 1.5
diff -r1.5 body.py
0a1,2
> #@PydevCodeAnalysisIgnore
>
205a208,217
>             elif (name == 'cappedCylinder'):
>                 radius = float(attrs.get('radius', 1.0))
>                 length = float(attrs['length'])
>                 if (density is not None):
>                     mass.setCappedCylinder(float(density), 3, radius, length)
>             elif (name == 'cylinder'):
>                 radius = float(attrs.get('radius', 1.0))
>                 length = float(attrs['length'])
>                 if (density is not None):
>                     mass.setCylinder(float(density), 3, radius, length)
214a227
>
Index: xode/geom.py
===================================================================
RCS file: /cvsroot/pyode/pyode/xode/geom.py,v
retrieving revision 1.5
diff -r1.5 geom.py
0a1,2
> #@PydevCodeAnalysisIgnore
>
72c74
<             raise NotImplementedError()
---
>             self._parseGeomCylinder(attrs)
88c90
<             j = joint.Joint(nodename, self)
---
>             j = joint.Joint(nodeName, self)
181a184,200
>     def _parseGeomCylinder(self, attrs):
>         def start(name, attrs):
>             if (name == 'ext'):
>                 pass
>             else:
>                 raise errors.ChildError('cylinder', name)
>
>         def end(name):
>             if (name == 'cylinder'):
>                 self._parser.pop()
>
>         radius = float(attrs['radius'])
>         length = float(attrs['length'])
>
>         self._setObject(ode.GeomCylinder, radius=radius, length=length)
>         self._parser.push(startElement=start, endElement=end)
>
236c255
<
---
>
245c264
<                 tri = int(attrs['ia'])-1, int(attrs['ib'])-1,
int(attrs['ic'])-1
---
>                 tri = int(attrs['ia']) - 1, int(attrs['ib']) - 1, int(attrs['ic']) - 1


Thanks,
John

Re: [Pyode-user] Declarations

[Alexandru D. <al...@ci...>]

Here is a small step in this direction. This is a script which parses object.h
(and also mass.h)
and then searches each ODE_API function in PyODE source code.

It reports:
- NOT IMPLEMENTED: functions declared in declarations.pyx, but not implemented
anywhere
- IMPLEMENTED, BUT NOT DECLARED: functions found in some source file *.pyx, but
not in declarations.pyx
- NOT FOUND: functions which are not found at all in PyODE sources
- and for each found function, the file into which was implemented (e.g.
joints.pyx).

The script also extracts the doc for each function from ODE headers, but it does
nothing with it yet.
There is a commented #print doc somewhere in the source :)

Improvements to this script are welcome.

Alex


> Hey, just a note, in case anyone was wondering: the auto.py script Alex
> contributed a while ago didn't generate C declarations (of the kind in
> declarations.pyx) for the functions being added. I think it would be
> really neat to write a script that opens /usr/include/ode/objects.h and
> converts all the ODE_API functions into pyrex C declarations, but I
> don't have the time.
>
> Ethan

[Pyode-user] Fix for bug 1854241

[Alexandru D. <al...@ci...>]

Hello,

Here is a quick fix for the following bug:

Mass.setSphereTotal wraps wrong function - ID: 1854241

I have also noticed that the following function is not implemented:
void dMassRotate (dMass *, const dMatrix3 R);

Alex

[Pyode-user] Declarations

[Ethan Glasser-C. <gl...@cs...>]

Hey, just a note, in case anyone was wondering: the auto.py script Alex
contributed a while ago didn't generate C declarations (of the kind in
declarations.pyx) for the functions being added. I think it would be
really neat to write a script that opens /usr/include/ode/objects.h and
converts all the ODE_API functions into pyrex C declarations, but I
don't have the time.

Ethan

Re: [Pyode-user] Problems and modifications of the example code

[Ethan Glasser-C. <gl...@cs...>]

al...@ci... wrote:
> If not, maybe Timothy Stranex can help us :)

I just updated it. Thanks Timothy Stranex for your help!

Ethan

Re: [Pyode-user] Problems and modifications of the example code

[<al...@ci...>]

Well, I see you are one of the owners of tye PyPI entry for PyODE:

    * Author:  see file AUTHORS <timothy at stranex com>
    * Home Page: http://pyode.sourceforge.net/
    * License: BSD or LGPL
    * Package Index Owner: tstranex, glasserc

Doesn't that mean you have permissions for updating the package, even if you
didn't create it?

If not, maybe Timothy Stranex can help us :)

Alex

> al...@ci... wrote:
>> Also, your step-by-step install instructions are nice, can we include them in
>> PyODE's readme files?
>>
>> However, the version from Ubuntu repos may be old. A solution would be to
>> update
>> the PyPi index,
>> in order to let the users get the latest PyODE with 'easy_install pyode' or
>> 'pip
>> install pyode'.
>>
>> Ethan, what do you think?
>
> I didn't create the original PyPI entry for Python-Pyode and so cannot
> update it. Sorry. If it's any consolation, Debian/Ubuntu have been
> pretty good about building relatively recent CVS snapshots.
>
>> I will also ask Ethan to commit the attached patch.
>
> OK, applied.
>
> Ethan
>

Re: [Pyode-user] Problems and modifications of the example code

[Ethan Glasser-C. <gl...@cs...>]

al...@ci... wrote:
> Also, your step-by-step install instructions are nice, can we include them in
> PyODE's readme files?
> 
> However, the version from Ubuntu repos may be old. A solution would be to update
> the PyPi index,
> in order to let the users get the latest PyODE with 'easy_install pyode' or 'pip
> install pyode'.
> 
> Ethan, what do you think?

I didn't create the original PyPI entry for Python-Pyode and so cannot
update it. Sorry. If it's any consolation, Debian/Ubuntu have been
pretty good about building relatively recent CVS snapshots.

> I will also ask Ethan to commit the attached patch.

OK, applied.

Ethan

Re: [Pyode-user] Problems and modifications of the example code

[Hian-Kun T. <hi...@gm...>]

Hello,

Thank you for your kind reply and patch file. It works well for me.

That's my pleasure to offer my test procedure to be included in PyODE's
readme files. I have few experience in writing guidances or instructions,
though, and English is not my first language, So please feel free to change
or to modify my writing to fit the quality of the readme files.

Best Regards,

Hiankun

On Tue, May 18, 2010 at 1:00 AM, <al...@ci...> wrote:

> Hello and welcome to PyODE :)
>
> I also had the same problems with the tutorials. In the attachment you will
> find
> my changes
> for transforms.py and vehicle.py.
>
> My system: Ubuntu Karmic (Py2.6) and Windows XP (Py2.5). On XP, the samples
> run
> fine without glutInit.
> On Ubuntu, they fail with the error you described on your blog.
>
> I think glutInit should be called somewhere at the beginning of the
> program,
> after opening an OpenGL window.
> This is right after pygame.display.set_mode(...)
>
> The other change was glColor3; this function is not present on my systems.
> I
> just replaced it with glColor3f.
>
> Please let me know if the attached patch works for you.
>
> Also, your step-by-step install instructions are nice, can we include them
> in
> PyODE's readme files?
>
> However, the version from Ubuntu repos may be old. A solution would be to
> update
> the PyPi index,
> in order to let the users get the latest PyODE with 'easy_install pyode' or
> 'pip
> install pyode'.
>
> Ethan, what do you think?
>
> I will also ask Ethan to commit the attached patch.
>
> Alex
>
>
>
> > Hello,
> >
> > This is my first time to subscribe to and post to a mailing list. In case
> I
> > did something not suitable, correct me please.
> >
> > I found PyODE last week, then tried to install and tested with it. With
> no
> > much efforts I installed all the necessary libraries and packages in my
> > Ubuntu 8.04, and ran the example codes named Tutorial 1, 2, and 3
> > successfully. When I tried to test the transforms.py, some problems
> emerged.
> >
> > After installing necessary libraries and packages, I found I have to
> > modified some part of the original transforms.py to make it run in my
> > system. The modifications are the following:
> >
> > - from cgtypes import *
> > + from cgkit.cgtypes import *
> >
> > +       glutInit()
> >         glutSolidCube(1)
> >
> > My system is Ubuntu 8.04 with Python 2.5.2.
> >
> > I am not sure why the original example code cannot run on my system, but
> I
> > think maybe I should post my testing experience to you. If you have any
> > corrections or suggestions on my test, please let me know. Thank you.
> >
> > (FYI, I have written down my test procedures in my blog:
> > http://hiankun.blogspot.com/2010/05/py-pyode-installation-and-test.html)
> >
> >
> > Best Regards,
> >
> > Hiankun
> >
> ------------------------------------------------------------------------------
> >
> > _______________________________________________
> > Pyode-user mailing list
> > Pyo...@li...
> > https://lists.sourceforge.net/lists/listinfo/pyode-user
> >
>

Re: [Pyode-user] Problems and modifications of the example code

[<al...@ci...>]

Hello and welcome to PyODE :)

I also had the same problems with the tutorials. In the attachment you will find
my changes
for transforms.py and vehicle.py.

My system: Ubuntu Karmic (Py2.6) and Windows XP (Py2.5). On XP, the samples run
fine without glutInit.
On Ubuntu, they fail with the error you described on your blog.

I think glutInit should be called somewhere at the beginning of the program,
after opening an OpenGL window.
This is right after pygame.display.set_mode(...)

The other change was glColor3; this function is not present on my systems. I
just replaced it with glColor3f.

Please let me know if the attached patch works for you.

Also, your step-by-step install instructions are nice, can we include them in
PyODE's readme files?

However, the version from Ubuntu repos may be old. A solution would be to update
the PyPi index,
in order to let the users get the latest PyODE with 'easy_install pyode' or 'pip
install pyode'.

Ethan, what do you think?

I will also ask Ethan to commit the attached patch.

Alex



> Hello,
>
> This is my first time to subscribe to and post to a mailing list. In case I
> did something not suitable, correct me please.
>
> I found PyODE last week, then tried to install and tested with it. With no
> much efforts I installed all the necessary libraries and packages in my
> Ubuntu 8.04, and ran the example codes named Tutorial 1, 2, and 3
> successfully. When I tried to test the transforms.py, some problems emerged.
>
> After installing necessary libraries and packages, I found I have to
> modified some part of the original transforms.py to make it run in my
> system. The modifications are the following:
>
> - from cgtypes import *
> + from cgkit.cgtypes import *
>
> +       glutInit()
>         glutSolidCube(1)
>
> My system is Ubuntu 8.04 with Python 2.5.2.
>
> I am not sure why the original example code cannot run on my system, but I
> think maybe I should post my testing experience to you. If you have any
> corrections or suggestions on my test, please let me know. Thank you.
>
> (FYI, I have written down my test procedures in my blog:
> http://hiankun.blogspot.com/2010/05/py-pyode-installation-and-test.html )
>
>
> Best Regards,
>
> Hiankun
> ------------------------------------------------------------------------------
>
> _______________________________________________
> Pyode-user mailing list
> Pyo...@li...
> https://lists.sourceforge.net/lists/listinfo/pyode-user
>

[Pyode-user] Problems and modifications of the example code

[Hian-Kun T. <hi...@gm...>]

Hello,

This is my first time to subscribe to and post to a mailing list. In case I
did something not suitable, correct me please.

I found PyODE last week, then tried to install and tested with it. With no
much efforts I installed all the necessary libraries and packages in my
Ubuntu 8.04, and ran the example codes named Tutorial 1, 2, and 3
successfully. When I tried to test the transforms.py, some problems emerged.

After installing necessary libraries and packages, I found I have to
modified some part of the original transforms.py to make it run in my
system. The modifications are the following:

- from cgtypes import *
+ from cgkit.cgtypes import *

+       glutInit()
        glutSolidCube(1)

My system is Ubuntu 8.04 with Python 2.5.2.

I am not sure why the original example code cannot run on my system, but I
think maybe I should post my testing experience to you. If you have any
corrections or suggestions on my test, please let me know. Thank you.

(FYI, I have written down my test procedures in my blog:
http://hiankun.blogspot.com/2010/05/py-pyode-installation-and-test.html )


Best Regards,

Hiankun

Re: [Pyode-user] PyODE joint properties accessible as parameters

[Ethan Glasser-C. <gl...@cs...>]

al...@ci... wrote:
> Hello,
> 
> Here is the patch for accessing joint parameters as properties.

Sorry for the long delay. I have reviewed and applied this patch. A few
notes:

1. The old mechanism for setting parameters may have been faster because
the reference to the ODE function (dJointGetBallParam,
dJointSetBallParam) gets compiled away. But then again, it may be as
fast to just use function pointers, the way you do. Plus, your code is
cleaner.

2. Why set setJointParam and getJointParam per-instance rather than
making a class variable?

3. This is a big patch -- I would have been happier reviewing and
committing each change separately. For instance, moving to
setJointParam/getJointParam as one commit, then introducing the
parameters-as-properties thing, then introducing new joint types..

> I have tried to use 'Strip trailing spaces' in the editor, but now I have
> another problem.
> There are a lot of lines in the patch which do not change anything.
> e.g. (instead of dots, there are spaces):
> -....
> -      BallJoint(world, jointgroup=None)....
> +
> +      BallJoint(world, jointgroup=None)
> 

> How should I get rid of these? Manually editing the patch? Git Gui does not help me
> (i.e. 'Stage/Unstage hunk from commit' does not work properly, and messes the
> entire patch)

Normally I would commit a whitespace cleanup commit first, but it's
often hard to remember.. I have separated out the parts of your patch
that are whitespace fixes and applied these secondly. (I use magit,
which lets you stage/unstage individual lines.)

Ethan

Re: [Pyode-user] PyODE joint properties accessible as parameters

[<al...@ci...>]

Since the patch file is too large, I have compressed it in order to reach the
mailing list.

> Hello,
>
> Here is the patch for accessing joint parameters as properties.
>
> Examples:
>
> j = ode.HingeJoint(world)
> j.param.lo_stop = 0
> j.param.cfm = 1e-5
> j.param.vel = 0.1
>
> For complex joints:
> joint.param[1].fmax = 1
> joint.param[2].fmax = 2
> joint.param[3].fmax = 3
>
> And for Plane2D:
> joint.paramX.cfm = 1e-5
> joint.paramY.cfm = 1e-10
> joint.paramAngle.cfm = 1e-10
>
> Or:
> joint.param['X'].cfm = 1e-5
> joint.param['Y'].cfm = 1e-10
> joint.param['Angle'].cfm = 1e-5
>
>
> The patch also contains PUJoint, PRJoint, PistonJoint and Joint.enable/disable,
> so it can be applied
> against latest git revision.
>
>
> I have tried to use 'Strip trailing spaces' in the editor, but now I have
> another problem.
> There are a lot of lines in the patch which do not change anything.
> e.g. (instead of dots, there are spaces):
> -....
> -      BallJoint(world, jointgroup=None)....
> +
> +      BallJoint(world, jointgroup=None)
>
> How should I get rid of these? Manually editing the patch? Git Gui does not help
> me
> (i.e. 'Stage/Unstage hunk from commit' does not work properly, and messes the
> entire patch)
>
> Alex
>
>> al...@ci... wrote:
>>> In ode.pyx there is a comment:
>>>
>>> ## This causes some kind of weird bug! Need to fix this.
>>>
>>> import weakref
>>>
>>> _geom_c2py_lut = weakref.WeakValueDictionary()
>>>
>>> In my programs, sometimes the lut is not able to find the geom ID,
>>> and Space.collide_callback() fails with a KeyError. When this happens,
>>> some boxes pass through the floor and fall down to -infinity.
>>> Using a normal dictionary seems to solve the problem.
>>>
>>> Is this the weird bug?
>>
>> It sounds related but this isn't exactly the bug I was confused about
>> when I wrote that comment. The bug is that if you create Geoms but don't
>> save references to them, (like the "geoms" list in tutorial 3) then the
>> geoms get garbage collected and they therefore don't have any collisions.
>>
>> Your bug sounds related, because it seems like geoms are getting garbage
>> collected, but if that's true, then they should be getting destroyed
>> with dGeomDestroy() and so not causing collisions.
>>
>>> Therefore, we have two possibilities to solve the conflict:
>>>
>>> A) Overriding __setattr__:
>>>
>>>    Pros: - compatible with existing code
>>>
>>>    Cons: - may be slow (overriding __getattr__ and __setattr__ slows down the
>>> access to class items)
>>>          - you are not warned at all if you misspell the name of a property
>>>           (e.g. you use body.pos = (1,2,3) but the correct name is
>>> 'body.position'; however, python will not complain at all)
>>>
>>> B) Custom data field:
>>>    Pros: - more lightweight
>>>          - works fine, with no conflicts
>>>          - if you misspell the name of a property, you will receive an error
>>>
>>>    Cons: - breaks existing code which uses custom data
>>
>> I like B better. It would be really great if we could offer a setting
>> that would enable backwards-compatible behavior, though :)
>>
>>> Which one should we choose? I prefer B) since it already works on my
>>> computer.
>>>
>>> I have also implemented a mechanism for accessing joint parameters as
>>> properties.
>>> It works like this:
>>>
>>> j = ode.HingeJoint(world)
>>> j.param.lo_stop = 0
>>> j.param.cfm = 1e-5
>>> j.param.vel = 0.1
>>>
>>> For complex joints:
>>> joint.param[1].fmax = 1
>>> joint.param[2].fmax = 2
>>> joint.param[3].fmax = 3
>>>
>>> And for Plane2D:
>>> joint.paramX.cfm = 1e-5
>>> joint.paramY.cfm = 1e-10
>>> joint.paramAngle.cfm = 1e-10
>>>
>>> Or:
>>> joint.param['X'].cfm = 1e-5
>>> joint.param['Y'].cfm = 1e-10
>>> joint.param['Angle'].cfm = 1e-5
>>>
>>> And of course, the joint parameters are visible at TAB completion.
>>
>> Sounds like a good idea to me.
>>
>> Ethan
>>
>

Re: [Pyode-user] Lots of missing functions added to PyODE

[Ethan Glasser-C. <gl...@cs...>]

al...@ci... wrote:
> In ode.pyx there is a comment:
> 
> ## This causes some kind of weird bug! Need to fix this.
> 
> import weakref
> 
> _geom_c2py_lut = weakref.WeakValueDictionary()
> 
> In my programs, sometimes the lut is not able to find the geom ID,
> and Space.collide_callback() fails with a KeyError. When this happens,
> some boxes pass through the floor and fall down to -infinity.
> Using a normal dictionary seems to solve the problem.
> 
> Is this the weird bug?

It sounds related but this isn't exactly the bug I was confused about
when I wrote that comment. The bug is that if you create Geoms but don't
save references to them, (like the "geoms" list in tutorial 3) then the
geoms get garbage collected and they therefore don't have any collisions.

Your bug sounds related, because it seems like geoms are getting garbage
collected, but if that's true, then they should be getting destroyed
with dGeomDestroy() and so not causing collisions.

> Therefore, we have two possibilities to solve the conflict:
> 
> A) Overriding __setattr__:
> 
>    Pros: - compatible with existing code
> 
>    Cons: - may be slow (overriding __getattr__ and __setattr__ slows down the
> access to class items)
>          - you are not warned at all if you misspell the name of a property
>           (e.g. you use body.pos = (1,2,3) but the correct name is
> 'body.position'; however, python will not complain at all)
> 
> B) Custom data field:
>    Pros: - more lightweight
>          - works fine, with no conflicts
>          - if you misspell the name of a property, you will receive an error
> 
>    Cons: - breaks existing code which uses custom data

I like B better. It would be really great if we could offer a setting
that would enable backwards-compatible behavior, though :)

> Which one should we choose? I prefer B) since it already works on my computer.
> 
> I have also implemented a mechanism for accessing joint parameters as properties.
> It works like this:
> 
> j = ode.HingeJoint(world)
> j.param.lo_stop = 0
> j.param.cfm = 1e-5
> j.param.vel = 0.1
> 
> For complex joints:
> joint.param[1].fmax = 1
> joint.param[2].fmax = 2
> joint.param[3].fmax = 3
> 
> And for Plane2D:
> joint.paramX.cfm = 1e-5
> joint.paramY.cfm = 1e-10
> joint.paramAngle.cfm = 1e-10
> 
> Or:
> joint.param['X'].cfm = 1e-5
> joint.param['Y'].cfm = 1e-10
> joint.param['Angle'].cfm = 1e-5
> 
> And of course, the joint parameters are visible at TAB completion.

Sounds like a good idea to me.

Ethan

Re: [Pyode-user] Lots of missing functions added to PyODE

[<al...@ci...>]

> al...@ci... wrote:
>> A summary of changes:
>>
>> * World: damping functions, QuickStep over-relaxation tuning
>> * Body: damping, auto-disable, setMovedCallback
>> * Joints:
>>   - enable/disable joints
>>   - JointType... constants
>>   - 3 new joint classes: Piston, PR and PU.
>
> Hmm.. why did you move the enable/disable functions for bodies to the
> bottom of the file, instead of adding the autodisable stuff where the
> enable stuff was?

Well... at first I wanted to keep (more or less) the same order as ODE wiki.

> I think _bodyMovedCallbacks should be a weakdict, shouldn't it? Also,
> would it make more sense to add a _body_c2py_lut lookup table like for
> geoms in ode.py? In that case you'd only need to store the callbacks in
> _bodyMovedCallbacks. Of course, if it's a weakdict, you'd need to handle
> the case where the body goes out of scope.. presumably the moved
> callback won't be called if the body ceases to exist, but I'm not sure ;)

You are right. I will learn how to use weakdicts :)

> Maybe Body.getData() and Body.setData() should raise NotImplementedError?

Yes, this is also a good idea.

> You add a lot of blank lines between sections of code! I find this
> distracting. Also, you have lots and lots of trailing whitespace, which
> I really hate.

Well.. my coding style includes lots of whitespace :)
Okay, now I found Document->Strip Trailing Spaces in Geany. I did not notice them.

> Also, it seems a little silly for code this simple, but you could send
> smaller patches, especially if you're rearranging method declarations.
>
>> Many declarations were generated automatically with a small script: auto.py
>> (it
>> is attached).
>
> I added this, it's pretty neat. Thanks.
>
>> The following functions are still not implemented (I need some help here):
>>
>> dJointID dBodyGetJoint (dBodyID, int index);  (should return a Joint instance)
>
> I would add a _joint_c2py_lut, like with geoms. Ignore the comment, that
> was before I fully understood why tutorial3 used to break :)
>
>> dGeomID dBodyGetFirstGeom (dBodyID);
>> dGeomID dBodyGetNextGeom (dGeomID);           (these two should be wrapped
>> into
>> an iterable or a geom list)
>
> Hmm, if nobody gets to this before the weekend I'll see if I can add
> something.
>
>> Regards,
>> Alex
>
> How would you like to be credited it the changelog? Just your email address?
>
> Ethan
>

You may credit me like this:

Alex Dumitrache <al...@ci...>


In ode.pyx there is a comment:

## This causes some kind of weird bug! Need to fix this.

import weakref

_geom_c2py_lut = weakref.WeakValueDictionary()


In my programs, sometimes the lut is not able to find the geom ID,
and Space.collide_callback() fails with a KeyError. When this happens,
some boxes pass through the floor and fall down to -infinity.
Using a normal dictionary seems to solve the problem.

Is this the weird bug?


I also tried to implement Set* and Get* methods as properties, they are more
elegant.

    body.mass = 1           instead of body.setMass(1)
    print body.position     instead of print body.getPosition()

However, in Body class (and maybe others), they conflict with __setattr__.

At first, I have tried to override __setattr__, but I wasn't able to call the
default implementation (that's because Body is a "cdef class").

Then, I tried to remove __getattr__ and __setattr__ and instead use
something like this:

a) Add custom data as properties to a dedicated field ("data"):


    # Set custom data

    body.data.mycounter = 5

    body.data.mystring = "test"



    # Access custom data

    print body.data.mystring, body.data.mycounter



b) Supply a custom data object:



   # Set custom data

   body.data = myCustomData


   # Access custom data

   print body.data



Therefore, we have two possibilities to solve the conflict:

A) Overriding __setattr__:

   Pros: - compatible with existing code

   Cons: - may be slow (overriding __getattr__ and __setattr__ slows down the
access to class items)
         - you are not warned at all if you misspell the name of a property
          (e.g. you use body.pos = (1,2,3) but the correct name is
'body.position'; however, python will not complain at all)

B) Custom data field:
   Pros: - more lightweight
         - works fine, with no conflicts
         - if you misspell the name of a property, you will receive an error

   Cons: - breaks existing code which uses custom data

Which one should we choose? I prefer B) since it already works on my computer.

I have also implemented a mechanism for accessing joint parameters as properties.
It works like this:

j = ode.HingeJoint(world)
j.param.lo_stop = 0
j.param.cfm = 1e-5
j.param.vel = 0.1

For complex joints:
joint.param[1].fmax = 1
joint.param[2].fmax = 2
joint.param[3].fmax = 3

And for Plane2D:
joint.paramX.cfm = 1e-5
joint.paramY.cfm = 1e-10
joint.paramAngle.cfm = 1e-10

Or:
joint.param['X'].cfm = 1e-5
joint.param['Y'].cfm = 1e-10
joint.param['Angle'].cfm = 1e-5

And of course, the joint parameters are visible at TAB completion.

The old method, with setParam and getParam, still works as before.

The implementation uses descriptors, and all the functions are in the Joint base
class.
I will do some profiling to see if this does not slowdown the creation of
contact joints
in collision handler (because right now, they are a bottleneck in my robot
simulation).

I'm not sending the patch right now, since the code needs a bit of cleanup.

Alex

Re: [Pyode-user] Lots of missing functions added to PyODE

[Ethan Glasser-C. <gl...@cs...>]

al...@ci... wrote:
> A summary of changes:
> 
> * World: damping functions, QuickStep over-relaxation tuning
> * Body: damping, auto-disable, setMovedCallback
> * Joints:
>   - enable/disable joints
>   - JointType... constants
>   - 3 new joint classes: Piston, PR and PU.

Hmm.. why did you move the enable/disable functions for bodies to the
bottom of the file, instead of adding the autodisable stuff where the
enable stuff was?

I think _bodyMovedCallbacks should be a weakdict, shouldn't it? Also,
would it make more sense to add a _body_c2py_lut lookup table like for
geoms in ode.py? In that case you'd only need to store the callbacks in
_bodyMovedCallbacks. Of course, if it's a weakdict, you'd need to handle
the case where the body goes out of scope.. presumably the moved
callback won't be called if the body ceases to exist, but I'm not sure ;)

Maybe Body.getData() and Body.setData() should raise NotImplementedError?

You add a lot of blank lines between sections of code! I find this
distracting. Also, you have lots and lots of trailing whitespace, which
I really hate.

Also, it seems a little silly for code this simple, but you could send
smaller patches, especially if you're rearranging method declarations.

> Many declarations were generated automatically with a small script: auto.py (it
> is attached).

I added this, it's pretty neat. Thanks.

> The following functions are still not implemented (I need some help here):
> 
> dJointID dBodyGetJoint (dBodyID, int index);  (should return a Joint instance)

I would add a _joint_c2py_lut, like with geoms. Ignore the comment, that
was before I fully understood why tutorial3 used to break :)

> dGeomID dBodyGetFirstGeom (dBodyID);
> dGeomID dBodyGetNextGeom (dGeomID);           (these two should be wrapped into
> an iterable or a geom list)

Hmm, if nobody gets to this before the weekend I'll see if I can add
something.

> Regards,
> Alex

How would you like to be credited it the changelog? Just your email address?

Ethan

Re: [Pyode-user] ImportError with PyODE-snapshot-2010-03-22.win32-py2.6.exe

[<al...@ci...>]

Hello,

I have only tested PyODE on XP, so feedback on other Windows versions is welcome.

Do you have Python installed in C:\Python26 or other folder?

In C:\Python26 you should have ode.dll, which is loaded when importing ode.
Try copying it into Windows folder, or into your working folder.

If it still does not work, ode.dll itself may require some other dll,
which does not come bundled with Win 7. You may download Dependency Walker
and try opening ode.dll . Please report any errors here.

Regards,
Alex


> Hello,
>
> After installing PyODE-snapshot-2010-03-22.win32-py2.6 (python 2.6.5 and
> windows 7 home 64bits), an "import ode" causes an ImportError: DLL load
> failed on my machine.
>
> Can I get a little help please ?
>
> Regards,
> Cédrick Faury
>
> ------------------------------------------------------------------------------
> Download Intel® Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> http://p.sf.net/sfu/intel-sw-dev
> _______________________________________________
> Pyode-user mailing list
> Pyo...@li...
> https://lists.sourceforge.net/lists/listinfo/pyode-user
>

[Pyode-user] ImportError with PyODE-snapshot-2010-03-22.win32-py2.6.exe

[Cédrick F. <ced...@fr...>]

Hello,

After installing PyODE-snapshot-2010-03-22.win32-py2.6 (python 2.6.5 and 
windows 7 home 64bits), an "import ode" causes an ImportError: DLL load 
failed on my machine.

Can I get a little help please ?

Regards,
Cédrick Faury

Re: [Pyode-user] Pyode binary distribution

[<al...@ci...>]

Hello,

It's not enough to add geoms = []. Every time you create a new geom, you do:

geoms.append(geom)

In my Python 2.5, the ragdoll from your original code was falling through the
floor.
I guess the difference was in older versions of PyODE: they might not call
dGeomDestroy()
in the geom destructor, or the body object might have had some references to the
geoms.

Alex

> Thanks Alex.
>
> Yes the code you have sent is working fine. For some strange reason, when I
> added  geoms = [] on my original program, ragdoll continued falling. I will
> check what is going on. And of course my question would be, why and how was
> it working in Python2.5? What is the difference?
>
> Yes, the ragdoll is from monsterden.net. I think the original one is from
> Cornel.edu, bu tI can not remember the exact link now, and I am not sure if
> it is the same guy. Well, it is upto you to add it in the examples. It is an
> interesting one, and a bit more advanced than falling boxes.
>
> Kadir
>
> 2010/3/28 <al...@ci...>
>
>> Hello,
>>
>> I found the problem, see the attached file.
>>
>> Somewhere in the code, there is a line:
>>
>> # create a list to store any ODE bodies which are not part of the ragdoll
>> (this
>>
>> # is needed to avoid Python garbage collecting these bodies)
>>
>> bodies = []
>>
>>
>> A similar code snippet is needed for geoms, too. That's why I added the
>> following:
>> geoms = []
>>
>>
>> And after creating every geom, I have added it to that list. That solved
>> the
>> problem.
>>
>> "bodies" and "geoms" are not used anywhere in the code. They just say to
>> Python's garbage collector: I'm using these objects, do not delete them.
>>
>> When there are no more references to a body or a geom, PyODE removes those
>> objects
>> from ODE simulation automatically. That happened into your code: bodies
>> were still
>> present in simulation (that's why the doll was falling), but all the geoms
>> (floors and capsules) were deleted.
>>
>> Is the ragdoll example the one from
>> http://monsterden.net/software/ragdoll-pyode-tutorial ?
>> I think it would be nice to include it in the PyODE examples folder.
>>
>> Alex
>>
>> > Hello Alex,
>> >
>> > Thanks for your note and recommendations. I have answed them one by one,
>> > next to your questions:
>> >
>> > Kadir
>> >
>> > 2010/3/27 <al...@ci...>
>> >
>> >> Hello,
>> >>
>> >> First thing you should check:
>> >> Do the examples from C:\Python26\pyode-examples run correctly?
>> >>
>> >> >>> Tutorial 1 runs OK, with the same numerical output
>> >>>> Tutorial 2 runs OK with same double pendulum swinging
>> >>>> Tutorial 3 runs with the same problem I had with new installation of
>> > PyODE. Boxes falling down, penetrating the floor (plane).
>> >
>> >
>> >> tutorial3.py has an example with a GeomPlane some falling boxes and
>> >> spheres.
>> >> Does it run correctly?
>> >>
>> >
>> >>>> Tutorial 3 runs with the same problem I had with new installation of
>> > PyODE. Boxes falling down, penetrating the floor (plane).
>> >
>> >
>> >> I have just tested it with a fresh install of Python 2.6, PyOpenGL 3.0.1
>> >> and
>> >> PyODE-snapshot-2010-03-22.win32-py2.6.exe.
>> >> It worked from the first try.
>> >>
>> >> Which version of ODE do you use on Python 2.5? It seems that different
>> ODE
>> >> versions behave slightly differently
>> >> with the same scene description.
>> >>
>> >> >>>> I believe PyODE 1.2.0, which was installed using
>> > PyODE-1.2.0.win32-py2.5.exe.
>> >
>> >
>> >> Do you use PyODE directly from your program or do you have some higher
>> >> level
>> >> library, like cgkit?
>> >> In the second case, please check that it uses the same stepping method
>> >> (step or
>> >> quickStep) in both Py25 and 26.
>> >>
>> >> >>>> I use it directly. I use Vpython for visualisation.
>> >
>> >
>> >> Can you send me a small test program, with the floor and one body, which
>> >> works
>> >> in Py25 and not in 26?
>> >>
>> >
>> >>>>> I am attaching one famous RagDoll I have been using with PyODE. It is
>> > supposed to fall and lie down on the floor.
>> > Although I know nothing about robotics, I am trying to get this RagDoll
>> up
>> > and walking.
>> >
>> > I have visited your robot site.  I have downloaded the windows version of
>> > your robot and ran it on my laptop. I liked it very much. I tried to
>> > implement a similar kinematic robot arm earlier, I had some coordination
>> > problems, then I was planning to migrate it to ODE as a dynamic arm. I
>> use
>> > VPython for visualization, not OpenGL since VPython is very easy to use.
>> >
>> >>
>> >> I am also using PyODE in a simulation which involves bodies sitting, and
>> >> sometimes falling, on the ground.
>> >> When the gravity, body mass or vertical speed were too high, they could
>> >> break
>> >> the floor and fall down.
>> >> So you may start debugging with reducing the gravity value.
>> >>
>> >> >>> I set g = -0.81, same behaviour, slow-motion.
>> >
>> > It looks like a collision detection problem but where? Any double
>> Precision
>> > / SÝngle Precision issue?
>> >
>> >
>> >> However, the simulation runs exactly the same in Py25 and 26, with
>> exactly
>> >> the
>> >> same code. I do not use
>> >> PyODE directly, but all the rendering and simulation is done using
>> cgkit.
>> >> I'm
>> >> using boxes and trimeshes,
>> >> and sometimes spheres for debugging.
>> >>
>> >> The program in which I use PyODE is a robot arm simulator, still in
>> early
>> >> stages
>> >> of development, available here:
>> >> http://github.com/alexdu/robot-sandbox . For now, it only runs on
>> Windows
>> >> out of
>> >> the box (unzip and run).
>> >>
>> >> > Hi again,
>> >> >
>> >> > I have installed Python 2.6.4 and tried to install PyODE on top. I
>> have
>> >> > downloaded the
>> >> > PyODE-snapshot-2010-03-22.win32-py2.6.exe<
>> >>
>> http://sourceforge.net/projects/pyode/files/pyode/snapshot-2010-03-22/PyODE-snapshot-2010-03-22.win32-py2.6.exe/download
>> >> >from
>> >> > the sourceforge and somehow got it working :))
>> >> >
>> >> > But now funny things are happening. It looks like the GeomPlane is not
>> >> > functioning correctly, so that everything falls down forever. My
>> "floor"
>> >> has
>> >> > gone. The same exact code works OK in Python25, in 2.6, the rest seems
>> OK
>> >> > for the moment (At least gravity is there, joints are working, bodies
>> are
>> >> > working OK), but the floor is gone!?
>> >> >
>> >> > Is it a collision detection problem, although for the remaining parts
>> it
>> >> > seems to work ok. Bodies are mostly CappedCylinders (plus some
>> spheres).
>> >> >
>> >> >>From Idle, I can see ode.GeomPlane is in there, but somehow it is not
>> >> > working OK.
>> >> >
>> >> > I will check with some other programs, or simple geometries.
>> >> >
>> >> > Thnaks for your work and support.
>> >> >
>> >> > Kadir
>> >> >
>> >> > 2010/3/23 Ethan Glasser-Camp <gl...@cs...>
>> >> >
>> >> >> al...@ci... wrote:
>> >> >> > I have tried to create a binary Win32 installer for latest PyODE
>> >> >> snapshot.
>> >> >> > I am sure Kadir and others will find it useful.
>> >> >>
>> >> >> This is awesome, thanks!
>> >> >>
>> >> >> I have uploaded this, as well as tarballs taken from today's git, to
>> the
>> >> >> files section of the sourceforge project:
>> >> >>
>> >> >> https://sourceforge.net/projects/pyode/files/
>> >> >>
>> >> >> I've elected to use a snapshot-ymd system, since at present the
>> project
>> >> >> doesn't have "features" that are added in any regular fashion.
>> >> >>
>> >> >> I also updated the project website with the git URL and links to the
>> >> >> most current files.
>> >> >>
>> >> >> > Since I'm a beginner in creating Python packages, I have two small
>> >> >> issues:
>> >> >> >
>> >> >> > 1. The installer copies "ode.dll" to c:\python25. Is this a
>> problem?
>> >> >> > I believe it should be copied into "site-packages" instead, but I
>> did
>> >> not
>> >> >> know
>> >> >> > how to
>> >> >> > specify this in setup.py.
>> >> >>
>> >> >> No idea here, sorry..
>> >> >>
>> >> >> > 2. The examples are copied into c:\python25\pyode-examples. Is
>> there a
>> >> >> better
>> >> >> > choice?
>> >> >>
>> >> >> I wouldn't include them at all, frankly.
>> >> >>
>> >> >> > 3. When installing the binary package to a fresh Python directory,
>> >> >> tutorials 1
>> >> >> > and 3
>> >> >> > work fine; the others need pygame and maybe cgkit. Is there a way
>> to
>> >> >> specify
>> >> >> > these dependencies in the binary installer?
>> >> >>
>> >> >> I think it's fine to leave these out -- not all people who use ODE
>> are
>> >> >> going to want to use it with Pygame.
>> >> >>
>> >> >> > I have added examples and ode.dll as "data_files" in setup.py. I
>> would
>> >> >> also like to
>> >> >> > see the setup.py which created the releases from
>> >> >> pyode.sourceforge.net(1.2.0).
>> >> >>
>> >> >> I would guess that the setup.py in the source tree is the one they
>> used,
>> >> >> but I have no idea.
>> >> >>
>> >> >> Ethan
>> >> >>
>> >> >>
>> >> >>
>> >>
>> ------------------------------------------------------------------------------
>> >> >> Download Intel&#174; Parallel Studio Eval
>> >> >> Try the new software tools for yourself. Speed compiling, find bugs
>> >> >> proactively, and fine-tune applications for parallel performance.
>> >> >> See why Intel Parallel Studio got high marks during beta.
>> >> >> http://p.sf.net/sfu/intel-sw-dev
>> >> >> _______________________________________________
>> >> >> Pyode-user mailing list
>> >> >> Pyo...@li...
>> >> >> https://lists.sourceforge.net/lists/listinfo/pyode-user
>> >> >>
>> >> >
>> >>
>> >>
>> >
>>
>