pyode-user — PyODE User Discussions

Re: [Pyode-user] GeomTransform woes

[Chris B. <chr...@gm...>]

On 13/10/06, Ethan Glasser-Camp <gl...@cs...> wrote:
> Chris Bainbridge wrote:
> > Your CFM value is too high, which allows the generated contacts to be
> > violated significantly. Try  world.setCFM(1E-8)
>
> Thanks!
>
> How come this is only a problem if the geom is translated?

I haven't looked in detail, but I would guess that it is something to
do with the corrective forces for each contact being generated for the
geom, but applied to the translated body instead (not the centre of
the geom), thus producing a rotation about the centre of the geom.
Normally no rotation would occur since the ground plane is in the way,
but if you have a high CFM the geom will be allowed to sink into the
ground a bit, so the rotation will happen, but then the constraint is
violated on the other side, so the same process occurs there, and you
end up with the oscillating behaviour your simulation shows.

Re: [Pyode-user] GeomTransform woes

[Chris B. <chr...@gm...>]

On 12/10/06, Ethan Glasser-Camp <gl...@cs...> wrote:
> Hi,
>
> I played with the third PyODE tutorial to test out GeomTransforms, but
> I can't get them to work. The attached program generates a body and a
> GeomBox translated (0, 1, 0) from it. However, if you run it, the box
> is shown rocking back and forth on the plane. I've tried playing with
> the mass, for instance translating it using Mass.translate, but this
> does not fix the problem. What am I doing wrong?

Your CFM value is too high, which allows the generated contacts to be
violated significantly. Try  world.setCFM(1E-8)

[Pyode-user] GeomTransform woes

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

Hi,

I played with the third PyODE tutorial to test out GeomTransforms, but
I can't get them to work. The attached program generates a body and a
GeomBox translated (0, 1, 0) from it. However, if you run it, the box
is shown rocking back and forth on the plane. I've tried playing with
the mass, for instance translating it using Mass.translate, but this
does not fix the problem. What am I doing wrong?

Ethan

[Pyode-user] patch for Plane2DJoint in PyODE

[Leonard R. <co...@le...>]

hey there,

i hacked in support for plane 2d joints. please consider merging this
into cvs (it's based on todays image)

http://downloads.paniq.org/patches/pyode_plane2d.patch



-- 
Leonard Ritter

-- Design / Code / Music
-- http://www.leonard-ritter.com

Re: [Pyode-user] attach does not take (0,0)

[Bram S. <br...@sa...>]

Bram Stolk wrote:
> dJointAttach (jointid, 0,0) is valid use of ODE C API.
> You use it to temporarily disable a joint.
> 
> In python, joint.attach(0,0) gives:

Oops... it turns out that joint.attach(None, None) works just fine.
Sorry for the noise.

  Bram

> 
> Traceback (most recent call last):
>   File "tutorial3.py", line 491, in _mousefunc
>     selected_slider.attach(0,0)
>   File "joints.pyx", line 153, in ode.Joint.attach
> TypeError: Argument 'body1' has incorrect type (expected ode.Body, got int)
> 
> 
>   bram
> 
> 
> 


-- 
Bram Stolk, VR Engineer SARA, Amsterdam.   tel +31 20 592 3000

"Windows is a 32-bit extension to a 16-bit graphical shell for an 8-bit 
 operating system originally coded for a 4-bit microprocessor by a 2-bit 
 company that can't stand 1 bit of competition."

[Pyode-user] attach does not take (0,0)

[Bram S. <br...@sa...>]

dJointAttach (jointid, 0,0) is valid use of ODE C API.
You use it to temporarily disable a joint.

In python, joint.attach(0,0) gives:

Traceback (most recent call last):
  File "tutorial3.py", line 491, in _mousefunc
    selected_slider.attach(0,0)
  File "joints.pyx", line 153, in ode.Joint.attach
TypeError: Argument 'body1' has incorrect type (expected ode.Body, got int)


  bram



-- 
Bram Stolk, VR Engineer SARA, Amsterdam.   tel +31 20 592 3000

"Windows is a 32-bit extension to a 16-bit graphical shell for an 8-bit 
 operating system originally coded for a 4-bit microprocessor by a 2-bit 
 company that can't stand 1 bit of competition."

Re: [Pyode-user] api update

[Bram S. <br...@sa...>]

Tm9wZSwgdGhlcmUgYXJlIEN5bGluZGVycyBub3cgKGluIGFkZGl0aW9uIHRvIENhcHN1bGVzKSwN
CkNDeWxpbmRlciBpcyByZW5hbWVkIHRvIENhcHN1bGUsIHdlIGhhdmUgDQpMTW90b3JzIGluIDAu
NiwgYW5kIGEgSGVpZ2h0ZmllbGQgaW4gMC43LCBldGMuLi4uDQoNCiAgQnJhbQ0KDQoNCg0KLS0t
LS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IHB5b2RlLXVzZXItYm91bmNlc0BsaXN0cy5z
b3VyY2Vmb3JnZS5uZXQgb24gYmVoYWxmIG9mIENocmlzIEJhaW5icmlkZ2UNClNlbnQ6IFR1ZSA4
LzI5LzIwMDYgMTM6MzENClRvOiBweW9kZS11c2VyQGxpc3RzLnNvdXJjZWZvcmdlLm5ldA0KU3Vi
amVjdDogUmU6IFtQeW9kZS11c2VyXSBhcGkgdXBkYXRlDQogDQpPbiAyOS8wOC8wNiwgQnJhbSBT
dG9sayA8YnJhbUBzYXJhLm5sPiB3cm90ZToNCj4gSGksDQo+DQo+IEFyZSB0aGVyZSBwbGFucyB0
byB1cGRhdGUgcHlvZGUgdG8gdGhlIDAuNiBBUEk/DQoNClRoZSAwLjYgYXBpIGlzIHRoZSBzYW1l
IGFzIHRoZSAwLjUgb25lLCB0aGUgb25seSB0aGluZyB0aGF0IGNoYW5nZWQgaXMNCnRoZSBidWls
ZCBzeXN0ZW0NCg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KVXNpbmcgVG9tY2F0IGJ1dCBuZWVkIHRvIGRv
IG1vcmU/IE5lZWQgdG8gc3VwcG9ydCB3ZWIgc2VydmljZXMsIHNlY3VyaXR5Pw0KR2V0IHN0dWZm
IGRvbmUgcXVpY2tseSB3aXRoIHByZS1pbnRlZ3JhdGVkIHRlY2hub2xvZ3kgdG8gbWFrZSB5b3Vy
IGpvYiBlYXNpZXINCkRvd25sb2FkIElCTSBXZWJTcGhlcmUgQXBwbGljYXRpb24gU2VydmVyIHYu
MS4wLjEgYmFzZWQgb24gQXBhY2hlIEdlcm9uaW1vDQpodHRwOi8vc2VsLmFzLXVzLmZhbGthZy5u
ZXQvc2VsP2NtZD1sbmsma2lkPTEyMDcwOSZiaWQ9MjYzMDU3JmRhdD0xMjE2NDINCl9fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpQeW9kZS11c2VyIG1haWxp
bmcgbGlzdA0KUHlvZGUtdXNlckBsaXN0cy5zb3VyY2Vmb3JnZS5uZXQNCmh0dHBzOi8vbGlzdHMu
c291cmNlZm9yZ2UubmV0L2xpc3RzL2xpc3RpbmZvL3B5b2RlLXVzZXINCg0K

Re: [Pyode-user] api update

[Chris B. <chr...@gm...>]

On 29/08/06, Bram Stolk <br...@sa...> wrote:
> Hi,
>
> Are there plans to update pyode to the 0.6 API?

The 0.6 api is the same as the 0.5 one, the only thing that changed is
the build system

[Pyode-user] api update

[Bram S. <br...@sa...>]

Hi,

Are there plans to update pyode to the 0.6 API?

  Bram

-- 
Bram Stolk, VR Engineer SARA, Amsterdam.   tel +31 20 592 3000

"Windows is a 32-bit extension to a 16-bit graphical shell for an 8-bit 
 operating system originally coded for a 4-bit microprocessor by a 2-bit 
 company that can't stand 1 bit of competition."

Re: [Pyode-user] user report

[Bram S. <br...@sa...>]

Bram Stolk wrote:
>
> - tutorial3.py gives:
>   ODE Message 2: vector has zero size in dNormalize4()

This goes away if the time steps are smaller.
To do this, change n=2 to n=4 and double the
addForce values (the 10000 and 40000 numbers)

  Bram


-- 
Bram Stolk, VR Engineer SARA, Amsterdam.   tel +31 20 592 3000

"Windows is a 32-bit extension to a 16-bit graphical shell for an 8-bit 
 operating system originally coded for a 4-bit microprocessor by a 2-bit 
 company that can't stand 1 bit of competition."

[Pyode-user] user report

[Bram S. <br...@sa...>]

Hello,


These are the things I encountered when installing pyode (cvs version).

- For a build against a recent ode (svn version), I req'd a modified
  setup.py 
  I used a modified version of this one:
  http://sources.gentoo.org/viewcvs.py/gentoo-x86/dev-python/pyode/files/

- pyrex is listed as a development requirement only in INSTALL
  However, I could not build pyode without it.

- Tutorial3 showed rendering artefacts (backfaces were being drawn)
  See: http://stolk.org/tmp/artefact-pyode.png

  I had to add this:
    glCullFace(GL_BACK)
    glFrontFace(GL_CCW)
    glEnable(GL_CULL_FACE)

- vehicle.py aborts because glutInit() was not called

- vehicle.py gives:
  ODE Message 2: inertia must be positive definite! in dBodySetMass()

- tutorial3.py gives:
  ODE Message 2: vector has zero size in dNormalize4()



-- 
Bram Stolk, VR Engineer SARA, Amsterdam.   tel +31 20 592 3000

"Windows is a 32-bit extension to a 16-bit graphical shell for an 8-bit 
 operating system originally coded for a 4-bit microprocessor by a 2-bit 
 company that can't stand 1 bit of competition."

Re: [Pyode-user] bug: read from free'd memory when joint in jointgroup

[Chris B. <chr...@gm...>]

On 17/08/06, Chris Bainbridge <chr...@gm...> wrote:
> The attached patch to current cvs fixes my memory problems. The
> ode.World needs to keep track of all Joint, Body, Geom objects, since
> dWorldDestroy removes the underlying objects (in the case of Geom the
> body it links to is removed rather than the Geom itself, but Geom then
> tries to unlink itself from the Body).

Ok, it doesn't fix everything... to deal with non-deterministic
destructor order pyode would have to know about every pointer between
ode objects, and some are hidden and can't be easily changed through
the API without knowing if both underlying objects are still valid
(body->geom for example). So we would need to ensure that the
underlying ODE objects are deconstructed in the right order, and
deconstruction is delayed when we know that another python object that
is still valid has an ode internal pointer to the to-be-destroyed
object. Argh. It's probably easier to have an explicit cleanup
function to be called at the end of a simulation that detaches all
geoms, joints, and bodies, and then actually destroy the underlying
objects in the usual pyrex destructor.

Re: [Pyode-user] bug: read from free'd memory when joint in jointgroup

[Chris B. <chr...@gm...>]

The attached patch to current cvs fixes my memory problems. The
ode.World needs to keep track of all Joint, Body, Geom objects, since
dWorldDestroy removes the underlying objects (in the case of Geom the
body it links to is removed rather than the Geom itself, but Geom then
tries to unlink itself from the Body).

Re: [Pyode-user] bug: read from free'd memory when joint in jointgroup

[Chris B. <chr...@gm...>]

On 16/08/06, Matthias Baas <ba...@ir...> wrote:
> Now the situation you describe above (i.e. dWorldDestroy() is called
> before the Python joints are deallocated) shouldn't occur because the
> Python joints keep a reference to the World object they are in. I did
> this so that the World object is deallocated after the joints. But I'm
> not sure if Python really cares about the reference counts when the
> interpreter is actually shut down.

I think the key thing here is that I'm using garbage collection module
gc which doesn't enforce any ordering on the destruction of objects. I
just disabled it in one of my test cases and it no longer crashes.

Re: [Pyode-user] bug: read from free'd memory when joint in jointgroup

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

Chris Bainbridge wrote:
> Argh, I spoke too soon. It fixed the problem, mostly, but I am still
> getting double frees. I think the problem now is that dWorldDestroy is
> destroying all of the joints that aren't part of a joint group, and
> then the destructors again get called by pyode when the joint object
> is freed. From your fix it looks like every python Joint object that
> isn't in a group will have to be notified about the destruction of the
> underlying object in World.__dealloc__

Well, unfortunately, the ownership rules in ODE (if there are any) are 
rather vague. Who is the owner of a joint object who is responsible for 
the destruction of the object? In PyODE it's basically the Python Joint 
object that takes care of destroying the ODE joint (i.e. dJointDestroy() 
is always called inside __dealloc__()). If other objects take over 
ownership (such as the joint group or the world) and destroy the ODE 
joint they have to notify the corresponding Python Joint object about 
this by calling the _destroyed() method. Then the Python Joint object 
will not destroy the ODE joint again.

Now the situation you describe above (i.e. dWorldDestroy() is called 
before the Python joints are deallocated) shouldn't occur because the 
Python joints keep a reference to the World object they are in. I did 
this so that the World object is deallocated after the joints. But I'm 
not sure if Python really cares about the reference counts when the 
interpreter is actually shut down.

Does the crash in your program occur at the time the program is being 
terminated or does it also happen while the program is running?

- Matthias -

Re: [Pyode-user] bug: read from free'd memory when joint in jointgroup

[Chris B. <chr...@gm...>]

On 15/08/06, Chris Bainbridge <chr...@gm...> wrote:
> On 15/08/06, Matthias Baas <ba...@ir...> wrote:
> > Could it be that you had a JointGroup object that you didn't empty
> > explicitly (by calling the empty() method)?
> > In this case, the destructor of the JointGroup object only calls
> > dJointGroupDestroy() without notifying the contained Python joints about
> > the destruction of the ODE joints.
> > I have just committed a fix for this. Let me know if this has also fixed
> > your problem.

Argh, I spoke too soon. It fixed the problem, mostly, but I am still
getting double frees. I think the problem now is that dWorldDestroy is
destroying all of the joints that aren't part of a joint group, and
then the destructors again get called by pyode when the joint object
is freed. From your fix it looks like every python Joint object that
isn't in a group will have to be notified about the destruction of the
underlying object in World.__dealloc__

Log:

==3141== Invalid free() / delete / delete[]
==3141==    at 0x401C12D: free (in
/usr/lib/valgrind/x86-linux/vgpreload_memcheck.so)
==3141==    by 0x463A2AB: dJointDestroy (ode.cpp:989)
==3141==    by 0x45EA930: __pyx_tp_dealloc_3ode_Joint (ode_trimesh.c:5613)
==3141==    by 0x45D8169: __pyx_tp_dealloc_3ode_AMotor (ode_trimesh.c:16542)
==3141==    by 0x409259C: (within /usr/lib/libpython2.4.so.1.0)
==3141==    by 0x407F117: PyDict_Clear (in /usr/lib/libpython2.4.so.1.0)
==3141==    by 0x4081032: (within /usr/lib/libpython2.4.so.1.0)
==3141==    by 0x40DB82F: (within /usr/lib/libpython2.4.so.1.0)
==3141==    by 0x40DC0C5: PyGC_Collect (in /usr/lib/libpython2.4.so.1.0)
==3141==    by 0x40D4EC5: Py_Finalize (in /usr/lib/libpython2.4.so.1.0)
==3141==    by 0x40D3EF9: Py_Exit (in /usr/lib/libpython2.4.so.1.0)
==3141==    by 0x40D3FC1: (within /usr/lib/libpython2.4.so.1.0)
==3141==  Address 0x4BA88B0 is 0 bytes inside a block of size 560 free'd
==3141==    at 0x401C12D: free (in
/usr/lib/valgrind/x86-linux/vgpreload_memcheck.so)
==3141==    by 0x463B907: dWorldDestroy (ode.cpp:1266)
==3141==    by 0x45E122A: __pyx_tp_dealloc_3ode_World (ode_trimesh.c:2366)
==3141==    by 0x45E83FA: __pyx_tp_dealloc_3ode_Body (ode_trimesh.c:14884)
==3141==    by 0x45EA8A7: __pyx_tp_dealloc_3ode_Joint (ode_trimesh.c:15277)
==3141==    by 0x45D7E4B: __pyx_tp_dealloc_3ode_HingeJoint (ode_trimesh.c:15619)
==3141==    by 0x407F2E9: (within /usr/lib/libpython2.4.so.1.0)
==3141==    by 0x45F679E: __pyx_tp_dealloc_3ode_GeomObject (ode_trimesh.c:16716)
==3141==    by 0x45D869F: __pyx_tp_dealloc_3ode_GeomCCylinder
(ode_trimesh.c:17976)
==3141==    by 0x407F117: PyDict_Clear (in /usr/lib/libpython2.4.so.1.0)
==3141==    by 0x4081032: (within /usr/lib/libpython2.4.so.1.0)
==3141==    by 0x40DB82F: (within /usr/lib/libpython2.4.so.1.0)

Re: [Pyode-user] bug: read from free'd memory when joint in jointgroup

[Chris B. <chr...@gm...>]

On 15/08/06, Matthias Baas <ba...@ir...> wrote:
> Could it be that you had a JointGroup object that you didn't empty
> explicitly (by calling the empty() method)?
> In this case, the destructor of the JointGroup object only calls
> dJointGroupDestroy() without notifying the contained Python joints about
> the destruction of the ODE joints.
> I have just committed a fix for this. Let me know if this has also fixed
> your problem.

Thanks, that seems to have fixed it. Have you noticed any memory
corruption problems with pyrex-0.9.4.1 and pyode? With 0.9.3.1
everything runs fine, with 0.9.4.1 I get:

*** glibc detected *** double free or corruption (!prev): 0x0823fb40 ***

And if I run valgrind there are hundreds of errors (again, 0.9.3.1 is fine).

Re: [Pyode-user] bug: read from free'd memory when joint in jointgroup

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

Chris Bainbridge wrote:
> In one of my pyode progs I get an invalid memory read reported when
> running under valgrind. It seems that dJointGroupDestroy is called by
> pyode and destroys all of the joints in the joint group. However, if
> there is another reference to the joint, then it will also call
> dJointDestroy, causing a read of the already-free'd memory. From ode
> src:
> 
> void dJointDestroy (dxJoint *j)
> {
>   dAASSERT (j);
>   if (j->flags & dJOINT_INGROUP) return;
>   removeJointReferencesFromAttachedBodies (j);
>   removeObjectFromList (j);
>   j->world->nj--;
>   dFree (j,j->vtable->size);
> }
> 
> j->flags & dJOINT_INGROUP returns true because the joint was in a
> (already destroyed) joint group, but the read of j->flags is invalid
> since the memory was already free'd.

Could it be that you had a JointGroup object that you didn't empty 
explicitly (by calling the empty() method)?
In this case, the destructor of the JointGroup object only calls 
dJointGroupDestroy() without notifying the contained Python joints about 
the destruction of the ODE joints.
I have just committed a fix for this. Let me know if this has also fixed 
your problem.

- Matthias -

[Pyode-user] bug: read from free'd memory when joint in jointgroup

[Chris B. <chr...@gm...>]

In one of my pyode progs I get an invalid memory read reported when
running under valgrind. It seems that dJointGroupDestroy is called by
pyode and destroys all of the joints in the joint group. However, if
there is another reference to the joint, then it will also call
dJointDestroy, causing a read of the already-free'd memory. From ode
src:

void dJointDestroy (dxJoint *j)
{
  dAASSERT (j);
  if (j->flags & dJOINT_INGROUP) return;
  removeJointReferencesFromAttachedBodies (j);
  removeObjectFromList (j);
  j->world->nj--;
  dFree (j,j->vtable->size);
}

j->flags & dJOINT_INGROUP returns true because the joint was in a
(already destroyed) joint group, but the read of j->flags is invalid
since the memory was already free'd.

For some reason I've only seen this with ContactJoints - I wonder if
there are extra references for these attached to an object somewhere.

[Pyode-user] importing mesh for collision detection

[James L. <jam...@do...>]

Hi,

I would like to simulate catheters using ODE. I want it to collide with some
vessel objects which I have in 3D, can be exported as .obj .x3d or .wrl etc.

What is be best way to import the mesh into ODE. I assume I have to make
them into trimeshs, for starters I don't want any deformation so how do I
set them as non-moving objects during collision.

Any suggestions on how to get started?

Thanks,
James

Re: [Pyode-user] Building against ODE-0.6 on Ubuntu

[Richard J. <ric...@op...>]

On Friday 28 July 2006 22:45, Chris Bainbridge wrote:
> On 28/07/06, Jean de Largentaye <je...@la...> wrote:
> > All I can say is that building PyODE for ODE 0.6 isn't a trivial task,
> > though it shouldn't be very hard. If you can do it (and for Ubuntu!
> > thus closer to Debian), I shall enshrine you ^_^. Heck, it's something
> > I'd love to be able to help with, if only I had the time (and the net
> > at home...).
>
> I just finished building it on gentoo, and it should build on other
> linuxes, just replace setup.py with the one that will appear shortly
> on http://sources.gentoo.org/viewcvs.py/gentoo-x86/dev-python/pyode/files/

libode is installed in /usr/local/lib on my system. I've attached a modified 
setup.py which searches for libode.

I still got compilation errors though until I removed the generated ode_*.c 
source files and had pyrex re-generate them. Then it all worked fine with one 
test failure that looks like a rounding error:

richard@shiny:/usr/local/src/PyODE-1.1.0/tests$ python test_xode.py
....................................................F........................................................
======================================================================
FAIL: testAxis2FudgeFactor (__main__.TestJointParser)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "test_xode.py", line 612, in testAxis2FudgeFactor
    self.assertEqual(self.joint8.getParam(ode.ParamFudgeFactor2), 0.2)
AssertionError: 0.20000000298023224 != 0.20000000000000001

----------------------------------------------------------------------
Ran 109 tests in 0.927s

All the examples (except the one requiring cgtypes) work fine.


    Richard

Re: [Pyode-user] Building against ODE-0.6 on Ubuntu

[Chris B. <chr...@gm...>]

On 28/07/06, Jean de Largentaye <je...@la...> wrote:
>
> All I can say is that building PyODE for ODE 0.6 isn't a trivial task,
> though it shouldn't be very hard. If you can do it (and for Ubuntu!
> thus closer to Debian), I shall enshrine you ^_^. Heck, it's something
> I'd love to be able to help with, if only I had the time (and the net
> at home...).

I just finished building it on gentoo, and it should build on other
linuxes, just replace setup.py with the one that will appear shortly
on http://sources.gentoo.org/viewcvs.py/gentoo-x86/dev-python/pyode/files/

Re: [Pyode-user] Building against ODE-0.6 on Ubuntu

[Jean de L. <je...@la...>]

Yoinks,

I don't know if you're on the ODE mailing list, but in case you're
not, I wanted to highlight that ODE 0.6 brings a number of changes and
that API compatibility wasn't a high priority. Most notable change is
the build system: ODE 0.5 (that PyODE is based on) didn't use
autotools.
All I can say is that building PyODE for ODE 0.6 isn't a trivial task,
though it shouldn't be very hard. If you can do it (and for Ubuntu!
thus closer to Debian), I shall enshrine you ^_^. Heck, it's something
I'd love to be able to help with, if only I had the time (and the net
at home...).

John

On 7/28/06, Richard Jones <ric...@op...> wrote:
> I'm trying to build PyODE 1.1.0 against ODE 0.6 on Ubuntu.
>
> The file "user-settings" doesn't appear anywhere in either the ODE
> source/build dir or in the installed directories. The config appears to only
> be used for OPCODE_DIRECTORY. I will *assume* that it should evaluate to a
> true value, since I did build with OPCODE support (which seems to equate to
> trimesh support in PyODE terms). ODE's configure reported:
>
> Configuration:
>   Target system type:      i686-pc-linux-gnu
>   Build  system type:      i686-pc-linux-gnu
>   Host   system type:      i686-pc-linux-gnu
>   Use double precision:    no
>   Use OPCODE:              yes
>   Use gyroscopic term:     yes
>   Is this a Pentium:       yes
>   Is the CPU x86-64:       no
>   Is this a release build: yes
>   Headers will be installed in /usr/local/include/ode
>   Libraries will be installed in /usr/local/lib
>
> However when I hard-code "wrap_trimesh = True" I get a slew of errors from
> ode_trimesh.c. The complete build log is attached to this email.
>
> I'm using Pyrex version 0.9.3.1-2ubuntu2 if that makes any difference. The
> INSTALL doc declares this a supported version.
>
>
>     Richard
>
>
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share your
> opinions on IT & business topics through brief surveys -- and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
>
> _______________________________________________
> Pyode-user mailing list
> Pyo...@li...
> https://lists.sourceforge.net/lists/listinfo/pyode-user
>
>
>
>

[Pyode-user] Building against ODE-0.6 on Ubuntu

[Richard J. <ric...@op...>]

I'm trying to build PyODE 1.1.0 against ODE 0.6 on Ubuntu.

The file "user-settings" doesn't appear anywhere in either the ODE 
source/build dir or in the installed directories. The config appears to only 
be used for OPCODE_DIRECTORY. I will *assume* that it should evaluate to a 
true value, since I did build with OPCODE support (which seems to equate to 
trimesh support in PyODE terms). ODE's configure reported:

Configuration:
  Target system type:      i686-pc-linux-gnu
  Build  system type:      i686-pc-linux-gnu
  Host   system type:      i686-pc-linux-gnu
  Use double precision:    no
  Use OPCODE:              yes
  Use gyroscopic term:     yes
  Is this a Pentium:       yes
  Is the CPU x86-64:       no
  Is this a release build: yes
  Headers will be installed in /usr/local/include/ode
  Libraries will be installed in /usr/local/lib

However when I hard-code "wrap_trimesh = True" I get a slew of errors from 
ode_trimesh.c. The complete build log is attached to this email.

I'm using Pyrex version 0.9.3.1-2ubuntu2 if that makes any difference. The 
INSTALL doc declares this a supported version.


    Richard

Re: [Pyode-user] using ODE/PyODE for finding nearest point of intersection

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

Maciej Kalisiak wrote:
> range to the closest obstacle.  I've experimented with the collision
> detection routines in pyODE, and it looks like I might get it to work,
> but the issue is that I get back collision contact points, which
> usually don't necessarily correspond to the *closest* point, and for
> certain shallow collisions, when there is only a single contact
> generated, I get slightly weird/erroneous position of that single
> contact.  I guess I'm wondering if there is a way to modify/choose an
> alternate contact point generating method.  Any ideas?

I'm not aware of any ODE options that let you control how the collision 
detection determines contact points, so I doubt that the above approach 
will really give any reliable results.
You could use the above approach if you would find another collision 
detection library that can also compute distances. I believe SWIFT is 
such a library (http://www.cs.unc.edu/~geom/SWIFT++/).

Another option might be testing the distance to an obstacle in a 
particular direction via a ray geom. This has the disadvantage that it 
only tests one discrete direction which means you have to use a bunch of 
rays for approximating your range scanner, but at least it yields the 
exact distance.

- Matthias -