pyode-user Mailing List for Python-ODE Bindings (Page 18)

SourceForge Headquarters 225 Broadway Suite 1600 San Diego, CA 92101 +1 (858) 422-6466

I just noticed all the modification dates in the changelog.... spooky!
And what happened on April 4?
Anyway, see you next month then...
;-)

- Matthias -

Chris Bainbridge wrote:
>>>>s.getBody()
> 
> <ode.Body object at 0xa7c506ec>

Non-placeable geoms always returned the ode.environment dummy Body (this 
is a PyODE Body class without an underlying ODE dBody. That's why it 
crashed when you actually tried to access the ODE body).

I've changed this so that there is no dummy Body anymore. 
ode.environment still exists, but it simply holds None. Calling 
getBody() on a Space will now return None instead of an empty Body. 
Creating an empty Body class is not possible anymore, now you must pass 
a World object.
I've also modified the attach() method of the joints as was suggested a 
while ago. It's now ok to pass None as one of the arguments.

> Also, it would be nice to be able to iterate over a space in a more
> python-like way, say:

Agreed and done. :)

It's all in cvs...

- Matthias -

According to the ODE manual space.getBody should return an error in
the debug build of ODE . Instead I get:

>>> import ode
>>> s=3Dode.Space()
>>> s
<ode.SimpleSpace object at 0xa7c48a20>
>>> s.getBody()
<ode.Body object at 0xa7c506ec>
>>> dir(s)
['__class__', '__delattr__', '__doc__', '__getattribute__',
'__hash__', '__init__', '__new__', '__reduce__', '__reduce_ex__',
'__repr__', '__setattr__', '__str__', '_id', 'add', 'collide',
'disable', 'enable', 'getAABB', 'getBody',
 'getCategoryBits', 'getCollideBits', 'getGeom', 'getNumGeoms',
'getPosition', 'getRotation', 'getSpace', 'isEnabled', 'isSpace',
'placeable', 'query', 'remove', 'setBody', 'setCategoryBits',
'setCollideBits', 'setPosition', 'setRo
tation']
>>> s.placeable()
False
>>> s.getBody()
<ode.Body object at 0xa7c506ec>
>>> s.getBody().getPosition()
zsh: segmentation fault  python

Also, it would be nice to be able to iterate over a space in a more
python-like way, say:

for g in space:
    print g

looks prettier than;

 for i in range(space.getNumGeoms()):
    print space.getGeom(i)

and len(space) might return the number of Geoms inside it.. just some ideas=
 ;-)

Roger Stuckey wrote:
> Firstly, can you provide an example using xode to load a trimesh 
> geometry? 

see Timothy's mail...

> At the moment, I am using cgkit.objimport to create an 
> _OBJReader object, which is then used to read an obj file and 
> subsequently build a TriMeshData object (using the verts and vfaces 
> variables). I had to comment out the line "self.faces = []" in the 
> g(self, *groups) method within the class definition of _OBJReader to do 
> so. 

In the 'g' callback of the importer the face list is cleared because the 
importer tries to recreate the scene hierarchy instead of putting 
everything in one big mesh, i.e. after importing an OBJ file you may 
have several separate meshes in your scene.

> Maybe you could consider making this class public, to allow explicit 
> use, rather than enforcing the generic "load" function in cgkit?

The base class of the importer is already public, it's the OBJReader 
class in the objmtl module:

http://cgkit.sourceforge.net/doc2/module-cgkit.objmtl.html

The OBJ *importer* uses this module to read the obj file and create 
cgkit objects. If you just use the verts and faces attributes of the 
importer you basically circumvent the actual functionality of the class 
(as you're only using the functionality of the base reader class). So 
I'd recommend to derive from objmtl.OBJReader and implement the 'v' and 
'f' callbacks.

Another option would be to import the model using load() and then take 
the mesh from the cgkit scene and convert it into a TriMeshData object. 
Then you could use any format that is supported by cgkit without that 
you have to change your code. This would look something like this 
(untested):

load("mymodel.obj")
mesh = worldObject("<objectname>")
trimeshdata = ode.TriMeshData()
trimeshdata.build(mesh.verts, mesh.faces)

If the mesh is not a triangle mesh you'd have to call 
convertToTriMesh(mesh) first.

> Secondly, I have been dropping a trimesh cube onto another trimesh cube, 
> but the colliding objects behave quite strangely - nothing like the 
> behaviour of a GeomBox being dropped onto a GeomPlane, for example. They 
> bounce quite violently off each other! I've tried altering the ERP 
> (currently 2.0), CFM (1E-5) and simulation time-step (0.001), to no 
> avail. Is this a problem with the OPCODE, or something else?

I haven't done that much tests with TriMesh-TriMesh collisions but it 
was also my experience that this doesn't work really stable. If I 
remember correctly, this has also been mentioned in the ODE mailing 
list. So it would be better if there would be only contacts between the 
primitive shapes and a TriMesh (for example, you could use the TriMesh 
for your Terrain and the simple objects for players, vehicles or whatever).
But on the other hand, I'm not sure if TriMesh support is really wrapped 
the right way in PyODE. There's this thing about setting the trimesh 
positions of the previous time step which I basically ignored, so maybe 
this also has a bad influence of the simulation. So if someone who knows 
how to deal with that stuff wants to have a look....

- Matthias -

On Tue, 2005-05-24 at 22:03 +1000, Roger Stuckey wrote:
> Firstly, can you provide an example using xode to load a trimesh 
> geometry?

This should probably work:

from xode import parser

trimesh_doc='''<?xml version="1.0" encoding="iso-8859-1"?>
<xode>
  <world>
    <space>
      <geom name="trimesh1">
        <trimesh>
          <vertices>
            <v x="0" y="1" z="1" />
            <v x="1" y="2" z="2" />
            <v x="2" y="0" z="1" />
            <v x="0" y="1" z="2" />
            <v x="2" y="2" z="1" />
          </vertices>
          <triangles>
            <t ia="1" ib="2" ic="3" />
            <t ia="2" ib="1" ic="4" />
            <t ia="3" ib="2" ic="1" />
          </triangles>
        </trimesh>
      </geom>
    </space>
  </world>
</xode>
'''

p = parser.Parser()
root = p.parseString(trimesh_doc)
trimesh1 = root.namedChild('trimesh1').getODEObject()

> Secondly, I have been dropping a trimesh cube onto another trimesh cube, 
> but the colliding objects behave quite strangely - nothing like the 
> behaviour of a GeomBox being dropped onto a GeomPlane, for example. They 
> bounce quite violently off each other!

It is possible that the vertices of the triangles are not specified in
the correct winding order. Try reversing the order and see if that
works. For example, instead of specifying a triangle as v1, v2, v3, try
v3, v2, v1.

-- 
Timothy Stranex <str...@ma...>

Matthias, others,

I have a couple of questions regarding Trimesh objects.

Firstly, can you provide an example using xode to load a trimesh 
geometry? At the moment, I am using cgkit.objimport to create an 
_OBJReader object, which is then used to read an obj file and 
subsequently build a TriMeshData object (using the verts and vfaces 
variables). I had to comment out the line "self.faces = []" in the 
g(self, *groups) method within the class definition of _OBJReader to do 
so. Maybe you could consider making this class public, to allow explicit 
use, rather than enforcing the generic "load" function in cgkit?

Secondly, I have been dropping a trimesh cube onto another trimesh cube, 
but the colliding objects behave quite strangely - nothing like the 
behaviour of a GeomBox being dropped onto a GeomPlane, for example. They 
bounce quite violently off each other! I've tried altering the ERP 
(currently 2.0), CFM (1E-5) and simulation time-step (0.001), to no 
avail. Is this a problem with the OPCODE, or something else?

By the way, I'm using the Windows binary release of pyode, and have also 
tried it (compiled from source) on my Powerbook with the same results.

Thanks for any help, and thanks for the great project,

Roger

Miles Jacobs wrote:
> Does PyODE allow the application of forces directly to a joint, as seen 
> in ODE (e.g. dJointAddSliderForce)?  I have looked in vain.

It didn't, but now it does. I've just checked in the modifications.
Each joint now has a method like addForce(), addTorque() or addTorques() 
that is a wrapper around the corresponding ODE function.

- Matthias -

Does PyODE allow the application of forces directly to a joint, as seen in 
ODE (e.g. dJointAddSliderForce)?  I have looked in vain.

Miles

_________________________________________________________________
Is your PC infected? Get a FREE online computer virus scan from McAfee® 
Security. http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963

Peter Hunt wrote:
> Will this be available any time soon?

I have just checked if it builds for Python 2.4, too (as this requires 
MSVC 7.1) and it seems everything is fine. So the next version will also 
be available for Python 2.4, I just don't know when we're going to 
release a new version... ;)
(If you want I can email you an installer of the current cvs version)

- Matthias -

Will this be available any time soon?

Thanks.

Chris,
	I had been having problems with passing None to the j.attach call
in Windows. I am still having these problems, but found that if I test for
None and instead pass ode.environment, the program functions as expected.
	I guess I should submit a bug report, but hopefully if anyone else
is having this problem, they can find this post in the archives.
	-Vincent

On Thu, 3 Mar 2005, Chris Bainbridge wrote:

> On Wed, 2 Mar 2005 23:35:28 -0500 (EST), Jonathan V Toups
> <to...@ph...> wrote:
> >
> >         j.attach(geom1.getBody(),geom2.getBody());
> >
> > Causes a nasty error.  This is because if one of the Geom objects is an
> > immovable object, getBody returns None.  This behaviour is puzzling, since
> > in Linux, I am clearly getting a body, perhaps where I shouldn't be.
>
> Are you sure? The behaviour under linux and windows should be
> identical... it's the same code. getBody should return None.
>
> >         So the question is, how do you handle adding contact joints to
> > objects which do not have bodies?  Or, how do you make an object with a
> > body permanantly fixed in space?  Or, am I doing something totally
> > ridiculous?
>
> You can't add joints to geoms. You can only use joint constraints on
> ODE bodies. You can fix a body in space by creating a fixedjoint with
> the environment (pass 0 as the body arg). However, this is generally
> advised against since it adds unnecessary constraints. The usual way
> to get what your trying to do is to place the geom somewhere, and then
> calculate contact joints. The contact joint should be attached to the
> static environment.  afaik, calling getBody should return None, and
> your contact joint is created with that and a real body, so your code
> should already work!
>

Hezekiah,
	I am using geomBox objects which are perfectly flat in on direction
and extend slightly into and out of the screen.  As long as no forces are
applied in the z-direction, you can construct your level out of these
objects.  It works in Linux at any rate.
	-Vincent

On Thu, 3 Mar 2005, Hezekiah M. Carty wrote:

> Jonathan V Toups wrote:
> > Friends,
> > 	I am writing a simples 2D physics simulator for an amateur game I
> > am working on, and the following problem has come up:
>
> Out of curiosity, how are you planning on restricting the game to
> physics to 2D?  I have used the Plane2D ODE addon in C/C++, but it looks
> like pyode does not have support for this.
>
> Hez
>
>

Jonathan V Toups wrote:
> Friends,
> 	I am writing a simples 2D physics simulator for an amateur game I
> am working on, and the following problem has come up:

Out of curiosity, how are you planning on restricting the game to 
physics to 2D?  I have used the Plane2D ODE addon in C/C++, but it looks 
like pyode does not have support for this.

Hez

Chris,
	Thanks for the speedy response.
	In Linux the behavior is exactly as you describe.  I just checked
the code, and the getBody() calls return None, just
like they do in Windows.  But in Windows the j.attach call with one of the
arguments as None causes a crash with an error message about an unexpected
segmentation violation.  Could it be a bug?
	I was working on recompiling the ODE library and PyODE in windows
(thinking maybe the latest source had fixed it, or that I might be able to
poke around the code and find the problem myself) but I was trying to do it
with cygwin and wasn't getting too far.
	The code definitely functions the way I am expecting it to under
Linux, so something is definitely going on.  I wonder what to do next?
	-Vincent

>> The following code reproduces:
>> 
>>   import ode
>> 
>>   space = ode.Space()
>>   geom = ode.GeomSphere(space, radius=0.5)
>>   geom.setCategoryBits(1)

> You're using the wrong type (it could be argued that pyode should
> transparently convert it...).

> Try geom.setCategoryBits(long(1))

Thanks for the fix.  I should have figured that out!

Alan

I had trouble as well in the joint.attach for colliding with a fixed object.
The following changes to Joint in joints.pyx fixed my problem:

    def attach(self, Body body1, Body body2):
        """attach(body1, body2)

        Attach the joint to some new bodies.

        @param body1: First body
        @param body2: Second body
        @type body1: Body
        @type body2: Body
        """

        cdef dBodyID id1
        cdef dBodyID id2

        if body1 == None:
            id1 = NULL
        else:
            id1 = body1.bid

        if body2 == None:
            id2 = NULL
        else:
            id2 = body2.bid

        self.body1 = body1
        self.body2 = body2
        dJointAttach(self.jid, id1, id2)

Feel free to incorporate if it solves the problem in the way it should
be solved :-)

Best regards,
Alan Blount 

Jonathan V Toups wrote:
> 	j.attach(geom1.getBody(),geom2.getBody());
> 
> Causes a nasty error.  This is because if one of the Geom objects is an
> immovable object, getBody returns None.  This behaviour is puzzling, since
> in Linux, I am clearly getting a body, perhaps where I shouldn't be.
> 	So the question is, how do you handle adding contact joints to
> objects which do not have bodies?  Or, how do you make an object with a
> body permanantly fixed in space?  Or, am I doing something totally
> ridiculous?

PyODE contains an actual body object that represents the static 
environment. And that's the ode.environment object. However, this 
concept isn't really applied consistently throughout PyODE.
The getBody() method can return None, however the attach() method must 
not be called with None as one of its arguments.
This means, you're near callback has to look somewhat like this.

    ...
    b1 = geom1.getBody()
    b2 = geom2.getBody()
    if b1==None:
        b1=ode.environment
    if b2==None:
        b2=ode.environment
    j.attach(b1, b2)
    ...

The tutorial did work because the only object that has no body 
associated with it was the ground floor which is a non-placeable object. 
And calling getBody() on non-placeable objects always returns 
ode.environment.

This situation is not really ideal. Either the ode.environment object 
should be dropped and the value None will represent the static 
environment. Or the environment concept should be consistent and 
getBody() should never return None. I'm quite undecided about what 
approach would be the better one (I'm probably slightly in favor of the 
environment object...).

By the way, I don't know why you get a different behavior under Linux. 
getBody() should also return None. What body is it actually returning?

- Matthias -

> The following code reproduces:
> 
>   import ode
> 
>   space = ode.Space()
>   geom = ode.GeomSphere(space, radius=0.5)
>   geom.setCategoryBits(1)

You're using the wrong type (it could be argued that pyode should
transparently convert it...).

Try geom.setCategoryBits(long(1))

Alan Blount wrote:
>   geom.setCategoryBits(1)
> 
> Traceback (most recent call last):
>   File "minimum.py", line 7, in ?
>     geom.setCategoryBits(1)
>   File "geomobject.pyx", line 234, in ode.GeomObject.setCategoryBits
> SystemError: Objects/longobject.c:240: bad argument to internal function
> 
> Any idea what gives?  I looked at the pyrex source for geomobject.pyx
> and didn't see anything obvious wrong.

This is rather a "bug" in the documentation as setCategoryBits() and 
setCollideBits() actually expect a long value and not an int (I also 
wasn't aware of that until recently when I stumbled across the same 
exception).
This means you have to change your code to:

    geom.setCategoryBits(1L)

or

    geom.setCategoryBits(long(1))

However, I've just commited a change so that also int values can be 
passed (and I corrected the doc strings).
(On the other hand, should that really be changed? It will break 
programs written for PyODE >1.0.0 when they're used with 1.0.0. Maybe it 
would be better to update the docs only. Any opinions?)

- Matthias -

On Wed, 2 Mar 2005 23:35:28 -0500 (EST), Jonathan V Toups
<to...@ph...> wrote:
> 
>         j.attach(geom1.getBody(),geom2.getBody());
> 
> Causes a nasty error.  This is because if one of the Geom objects is an
> immovable object, getBody returns None.  This behaviour is puzzling, since
> in Linux, I am clearly getting a body, perhaps where I shouldn't be.

Are you sure? The behaviour under linux and windows should be
identical... it's the same code. getBody should return None.

>         So the question is, how do you handle adding contact joints to
> objects which do not have bodies?  Or, how do you make an object with a
> body permanantly fixed in space?  Or, am I doing something totally
> ridiculous?

You can't add joints to geoms. You can only use joint constraints on
ODE bodies. You can fix a body in space by creating a fixedjoint with
the environment (pass 0 as the body arg). However, this is generally
advised against since it adds unnecessary constraints. The usual way
to get what your trying to do is to place the geom somewhere, and then
calculate contact joints. The contact joint should be attached to the
static environment.  afaik, calling getBody should return None, and 
your contact joint is created with that and a real body, so your code
should already work!

Friends,
	I am writing a simples 2D physics simulator for an amateur game I
am working on, and the following problem has come up:
	I am trying to follow, more or less, Tutorial 3 from the webpage,
in that I create my "physical objects" by associating them with bodies and
I create my environment, which is fixed and immovable, by simply creating
Geom objects without bodies.  In linux, this works fine, but in Windows the
line of the code in the collision callback which looks like:

	j.attach(geom1.getBody(),geom2.getBody());

Causes a nasty error.  This is because if one of the Geom objects is an
immovable object, getBody returns None.  This behaviour is puzzling, since
in Linux, I am clearly getting a body, perhaps where I shouldn't be.
	So the question is, how do you handle adding contact joints to
objects which do not have bodies?  Or, how do you make an object with a
body permanantly fixed in space?  Or, am I doing something totally
ridiculous?
	Thanks in advance for any help that is offered.
	-Vincent
PS - In this case, the geoms which are giving me trouble are simply GeomBox
objects.

Hello all.  I'm using ODE 0.5 and PyODE-1.0.0.

I'm getting a crash when trying to limit geom collisions with
setCategoryBits and setCollisionBits.

The following code reproduces:

  import ode

  space = ode.Space()
  geom = ode.GeomSphere(space, radius=0.5)
  geom.setCategoryBits(1)

I get back:

Traceback (most recent call last):
  File "minimum.py", line 7, in ?
    geom.setCategoryBits(1)
  File "geomobject.pyx", line 234, in ode.GeomObject.setCategoryBits
SystemError: Objects/longobject.c:240: bad argument to internal function

Any idea what gives?  I looked at the pyrex source for geomobject.pyx
and didn't see anything obvious wrong.

Thanks,
Alan

Bram Stolk wrote:
>> I'm still using the official ODE 0.5 binaries under WinXP. And neither 
>> the single, nor the double version produces the above message (I had 
>> the tutorial running for several minutes).
> 
> I forgot to mention: you need to build Debug libs, not Release.
> Did you do your runs with debug libs? Checks are not done for Release.

Oh, ok. Now I also get a message:

ODE Message 2: vector has zero size (ode/src/odemath.cpp:120)

(using the official 0.5 binary debug release)

Well, but still, all I can say is that this happens somewhere inside 
ODE. So if you think this is an error that should be fixed, you should 
post a message in the ODE mailing list.
But actually, I don't even know if this is really an error or not (at 
least the simulation still looks ok).

- Matthias -

Bram Stolk wrote:
> If I let tutorial3.py run for a minute or so, with
> a current CVS pyode, and CVS ode, configed with DOUBLE type,
> I get these messages:
> 
> ODE Message 2: vector has zero size in dNormalize4()
> 
> This happens both with step() and quickStep().

I'm still using the official ODE 0.5 binaries under WinXP. And neither 
the single, nor the double version produces the above message (I had the 
tutorial running for several minutes).
But anyway, the message is generated from ODE itself (dNormalize4() is a 
function from the ODE maths routines), so there's little we can do with 
the Python wrapper to fix that problem.
Have you encountered this problem with other simulations, too? If it's 
possible to write a small example showing the problem, then it's 
probably worth posting it into the ODE mailing list.

- Matthias -

Hello,

If I let tutorial3.py run for a minute or so, with
a current CVS pyode, and CVS ode, configed with DOUBLE type,
I get these messages:

ODE Message 2: vector has zero size in dNormalize4()

This happens both with step() and quickStep().

    bram

2004	Jan	Feb	Mar (13)	Apr	May (1)	Jun (34)	Jul (23)	Aug (16)	Sep	Oct (11)	Nov (13)	Dec (1)
2005	Jan (2)	Feb (3)	Mar (13)	Apr (1)	May (5)	Jun (11)	Jul (5)	Aug (10)	Sep (16)	Oct (8)	Nov (4)	Dec (5)
2006	Jan (18)	Feb (5)	Mar (6)	Apr (12)	May (3)	Jun (1)	Jul (4)	Aug (16)	Sep (1)	Oct (5)	Nov (35)	Dec (7)
2007	Jan (17)	Feb (14)	Mar (7)	Apr (9)	May (16)	Jun (31)	Jul (13)	Aug (23)	Sep	Oct (2)	Nov (3)	Dec (1)
2008	Jan (8)	Feb (1)	Mar (3)	Apr (2)	May	Jun (4)	Jul	Aug	Sep	Oct (1)	Nov	Dec
2009	Jan	Feb (5)	Mar	Apr (2)	May	Jun (1)	Jul	Aug (5)	Sep (1)	Oct	Nov (3)	Dec
2010	Jan (6)	Feb (6)	Mar (10)	Apr (5)	May (11)	Jun	Jul	Aug (2)	Sep (8)	Oct (2)	Nov (3)	Dec (5)
2011	Jan (7)	Feb	Mar (1)	Apr (3)	May (10)	Jun (1)	Jul (1)	Aug (1)	Sep (1)	Oct (1)	Nov	Dec
2012	Jan	Feb	Mar	Apr	May (6)	Jun	Jul	Aug	Sep	Oct	Nov	Dec
2013	Jan (1)	Feb	Mar	Apr (4)	May	Jun	Jul	Aug	Sep	Oct	Nov	Dec
2014	Jan	Feb	Mar (1)	Apr	May	Jun	Jul	Aug	Sep	Oct	Nov	Dec
2023	Jan	Feb	Mar	Apr	May	Jun	Jul	Aug	Sep	Oct	Nov	Dec (1)

pyode-user Mailing List for Python-ODE Bindings (Page 18)

pyode-user — PyODE User Discussions