pyode-user — PyODE User Discussions

Re: [Pyode-user] pyODE and PyOSG

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

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

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

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

- Matthias -

[Pyode-user] pyODE and PyOSG

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

Hello Bernie, Matthias, and Timothy,

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

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

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


Hope everyone is doing well,
-brett


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

Re: [Pyode-user] hinge.getAnchor2()

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

Chris Bainbridge wrote:
> Hi, the python wrapper seems to have missed this function. I'm trying to 
> figure out why my hinge joint isn't working...

The getAnchor2() methods are in cvs now (I was just in the process of 
adding doc strings for the joints anyway).

- Matthias -

[Pyode-user] hinge.getAnchor2()

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

Hi, the python wrapper seems to have missed this function. I'm trying to 
figure out why my hinge joint isn't working...

Re: [Pyode-user] CVS problem solved, sort of

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

On Tue, 2004-08-24 at 15:07, Matthias Baas wrote:
>  > - XODE reader
>=20
> It's finished as far as I can tell, isn't it?

It is complete except for the following features:

  - Quaternion and axis-angle rotation modes
  - Groups
  - Joints other than BallJoint

I will write the remaining joint parsers sometime next week.

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

Re: [Pyode-user] Individual Space classes

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

On Tue, 2004-08-24 at 15:08, Matthias Baas wrote:
> Timothy Stranex wrote:
> > I have sent a message to William Denniss (the author of XODE) about
> > this.
>=20
> Did you get any reply?

I got one reply but nothing back from my reply to that...

One big problem with creating an XODE extension is that the extension
tag comes at the end of the space element making it impossible to create
the Space instance before the bodies and geoms. It would mean either
moving to a DOM parser or implementing something similar.

I think we should defer support for Space classes specified in the XODE
file to a later release.

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

Re: [Pyode-user] Individual Space classes

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

Timothy Stranex wrote:
> I have sent a message to William Denniss (the author of XODE) about
> this. I suggested either adding space class selection export to a future
> XODE release or adding an extension that looks something like this:
> [...]

Did you get any reply?

- Matthias -

Re: [Pyode-user] CVS problem solved, sort of

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

Bernie Roehl wrote:
> Perhaps we could update the instructions on the PyODE home page?

By the way, when doing an update the location of the repository doesn't 
have to be specified again as it's stored in the CVS subdirectories. So 
the third line on the above page could just be "cvs update" (from within 
the pyode directory).
But maybe it would be enough just to refer to the original SF 
documentation?

And while we are at it, when should we do our first "official" release? 
I think the current state is almost ready for a release.

Here's the todo list from a couple of posts ago:

 >New Features:
 > - Add AMotor class

Done.

 > - Add Cylinder class (not the capped one)

Cylinder is not yet part of the official API.

 > - Trimesh support

An initial version that seems to work is in place. The interface for 
passing the mesh data may be extended in the future.

 > - XODE reader

It's finished as far as I can tell, isn't it?


 > Review:
 > - Check the ODE API for new (or so far unsupported) functions and add 
 >them to the respective class

I've added quite a few missing functions. There are still some more.

 > - Review the design and improve whatever has to be improved (like the
 > global lookup dictionary).

This has to be done yet.


 > Cleanup:
 > - Do more error checking.

Done sporadically.

 > - Add some __str__() methods that output useful data

Not done yet.

 > - Make the documentation (doc strings) complete

Partially done. Maybe this should be completed before doing a release.

 > - Add a proper file header on all the .pyx files

Not done yet.

 > Packaging:
 > - Update all the files that are necessary for a proper release 
 >(readme, license, changelog, ...)
 > - Write more examples, demos, tutorials. :)

Not done yet.


Even though some things are still missing I think we should try to get a 
release out somewhen soon so that other interested people can give feedback.

- Matthias -

[Pyode-user] CVS problem solved, sort of

[Bernie R. <br...@ec...>]

In investigating the CVS problem further, I found that the instructions at 
pyode.sourceforge.net are not quite correct.  That page says to login like 
this:

cvs -d:pserver:pyode.sourceforge.net:/cvsroot/pyode login

That doesn't appear to work, either from Windows or from my Solaris 
box.  It produces a "connection timed out" error.

However, the page at http://sourceforge.net/cvs/?group_id=73553 says to do 
it like this:

cvs -d:pserver:ano...@cv...:/cvsroot/pyode login

... which works fine.  Perhaps we could update the instructions on the 
PyODE home page?

In any case, I was able to get the latest sources using the second method.


--
   Bernie Roehl
   University of Waterloo Dept of Electrical and Computer Engineering
   Mail: br...@ec...   Voice: (519) 888-4567 x 2607 [work]
   URL: http://ece.uwaterloo.ca/~broehl 

[Pyode-user] CVS?

[Bernie R. <br...@ec...>]

I've been trying for a few days now to get the latest PyODE from 
pyode.sourceforge.net, and the server appears to be down.

Any idea when it will be up again?


--
   Bernie Roehl
   University of Waterloo Dept of Electrical and Computer Engineering
   Mail: br...@ec...   Voice: (519) 888-4567 x 2607 [work]
   URL: http://ece.uwaterloo.ca/~broehl 

Re: [Pyode-user] Individual Space classes

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

On Thu, 2004-08-05 at 22:54, Matthias Baas wrote:
> Do I understand that correctly that in the first option the space type=20
> is encoded directly in the XODE file whereas in the second option it's=20
> in the application code?

Affirmative.

> (Actually, I wonder why this isn't mentioned in the XODE spec at all.=20
> Did they just forget that there are several space types or do they think=20
> it's a detail that the application has to deal with?)

I have sent a message to William Denniss (the author of XODE) about
this. I suggested either adding space class selection export to a future
XODE release or adding an extension that looks something like this:

  <ext name=3D"space-class">
    # Any one of the following options:

    # 1.
    <simple/>

    # 2.
    <hash/>

    # 3.
    <quadtree centerx=3D"" centery=3D"" centerz=3D""
              extentsx=3D"" extentsy=3D"" extentsz=3D""
              depth=3D""/>
  </ext>

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

Re: [Pyode-user] Individual Space classes

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

Timothy Stranex wrote:
> It should be a trivial fix. The Space class in parser.py just needs to
> be updated to use one of the specific Space classes and the other
> classes need to use SpaceBase instead of Space as an argument to
> getFirstAncestor().

ok. I've just commited my changes, so it's available in cvs now.

>>By the way, what kind of Space will the XODE reader create? By browsing 
>>through the XODE spec it seems there's no way to specify which space 
>>should be used...(or did I miss something?).
> 
> I can think of two options: create an XODE extension that allows the
> user to set the space class; or, allow the user to pass an argument to
> the XODE parser indicating which space class to use. Maybe they could
> both be implemented by using the space class specified by a parser
> parameter unless it is overridden by the extension. Any thoughs?

Do I understand that correctly that in the first option the space type 
is encoded directly in the XODE file whereas in the second option it's 
in the application code? I would say both options can be useful. You 
certainly want to be able to store the space type in the file, but on 
the other hand it might also be useful to override these settings.
(Actually, I wonder why this isn't mentioned in the XODE spec at all. 
Did they just forget that there are several space types or do they think 
it's a detail that the application has to deal with?)

- Matthias -

Re: [Pyode-user] Individual Space classes

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

On Thu, 2004-08-05 at 18:10, Matthias Baas wrote:
> So is this a real problem or can it be easily fixed? (you could use=20
> SpaceBase instead of Space. However, I don't know if you have to be able=20
> to create instances of the class you're using. You can't create=20
> instances from SpaceBase)

It should be a trivial fix. The Space class in parser.py just needs to
be updated to use one of the specific Space classes and the other
classes need to use SpaceBase instead of Space as an argument to
getFirstAncestor().

> By the way, what kind of Space will the XODE reader create? By browsing=20
> through the XODE spec it seems there's no way to specify which space=20
> should be used...(or did I miss something?).

I can think of two options: create an XODE extension that allows the
user to set the space class; or, allow the user to pass an argument to
the XODE parser indicating which space class to use. Maybe they could
both be implemented by using the space class specified by a parser
parameter unless it is overridden by the extension. Any thoughs?

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

Re: [Pyode-user] Individual Space classes

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

Hi,

I have implemented the previously mentioned space restructuring 
(SpaceBase, SimpleSpace, HashSpace, QuadTreeSpace classes and a factory 
function Space). Now there's a problem with the XODE reader because it's 
assuming ode.Space is a class and not a function (e.g. when using 
isinstance()). The unit test produces exceptions like this:

   File "C:\PROGRA~1\PROGRA~1\Python23\Lib\site-packages\xode\geom.py", 
line 20, in __init__
     self._space = self.getFirstAncestor(ode.Space).getODEObject()
   File "C:\PROGRA~1\PROGRA~1\Python23\Lib\site-packages\xode\node.py", 
line 209, in getFirstAncestor
     if (isinstance(parent.getODEObject(), type)):
TypeError: isinstance() arg 2 must be a class, type, or tuple of classes 
and types

So is this a real problem or can it be easily fixed? (you could use 
SpaceBase instead of Space. However, I don't know if you have to be able 
to create instances of the class you're using. You can't create 
instances from SpaceBase)

By the way, what kind of Space will the XODE reader create? By browsing 
through the XODE spec it seems there's no way to specify which space 
should be used...(or did I miss something?).

- Matthias -

Re: [Pyode-user] Individual Space classes

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

On Tue, 2004-08-03 at 09:36, Matthias Baas wrote:
> As a second step I'd like to split the Space class in its individual=20
> classes as there are already three of them in ODE: SimpleSpace,=20
> HashSpace and QuadTreeSpace. However, before doing so I thought I'd=20
> better ask what you think of it. Are you in favor of this change or do=20
> you think we should stick to one Space class and pass the type as=20
> argument (as it is the case right now)?

I'm in favour of splitting them into separate classes.

> If we'll have individual classes, what class names would you prefer?=20

SimpleSpace, HashSpace and QuadTreeSpace are fine.

> Should "Space" be the abstract base class or an alias for the=20
> SimpleSpace class to remain at least a bit of compatibility to the=20
> previous version? Or should "Space" be a factory function that still=20
> works like before and returns the appropriate space class.....

I agree that having Space as a factory function is a good idea. Maybe
"SpaceBase" could be the abstract base class for the spaces?

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

[Pyode-user] Individual Space classes

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

Hi,

I'm just in the process of restructuring the Space class. The first step 
was to derive it from GeomObject as ODE considers spaces to be geoms as 
well. This is already in cvs.

As a second step I'd like to split the Space class in its individual 
classes as there are already three of them in ODE: SimpleSpace, 
HashSpace and QuadTreeSpace. However, before doing so I thought I'd 
better ask what you think of it. Are you in favor of this change or do 
you think we should stick to one Space class and pass the type as 
argument (as it is the case right now)?
If we'll have individual classes, what class names would you prefer? 
Should "Space" be the abstract base class or an alias for the 
SimpleSpace class to remain at least a bit of compatibility to the 
previous version? Or should "Space" be a factory function that still 
works like before and returns the appropriate space class..... (hm, this 
just occurred to me while typing the mail and now I'm indeed in favor of 
that solution as it remains fully compatible with the previous version. 
Any objections? :) )

- Matthias -

Re: [Pyode-user] Trimesh

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

Timothy Stranex wrote:
> From what I've found, dGeomTriMeshDataBuildSingle1 should only be used
> with single precision numbers and dGeomTriMeshDataBuildDouble1 with
> doubles. TriMeshData.build was using BuildSingle1 even if ODE was built
> with double precision dReals resulting in incorrect vertex data. I've
> fixed this in CVS by replacing the call to dGeomTriMeshDataBuildSingle1
> with one to dGeomTriMeshDataBuildSimple.

ok.
I haven't noticed those *BuildDouble functions and was still under the 
impression that trimesh won't work with doubles (why is there no 
double-trimesh binary then...?). Anyway, so if there are separate 
functions for floats and doubles we could also just use one of them 
without using dReals. In TriMeshData.build() we could just declare the 
variable "vp" and the member "vertex_buffer" as "float*" instead of 
"dReal*" and always use the float build function. Then we wouldn't need 
that unused 4th component again (that was the reason why I was switching 
from BuildSimple to the more complex version). As far as I can remember, 
Opcode always works with floats, right? So the above would save some 
more memory if ODE is compiled using doubles because our mesh buffer 
will use floats.

> Furthermore, it seems that these functions take the number of
> indices--not the number faces as was being passed before. This could
> explain why ODE was ignoring some of the triangles.

That's it! Thanks! Dropping meshes on a box seems to work now.
By the way, if someone is using those meshes I was posting... note that 
the inertia tensor stored in the file is given with respect to the 
center of gravity and not the origin (I wasn't aware of that myself).

- Matthias -

Re: [Pyode-user] Trimesh (was: Fwd: PyODE)

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

On Mon, 2004-07-26 at 10:26, Matthias Baas wrote:
> By the way, has anybody tried out the trimesh stuff? For me, it only=20
> works on some meshes whereas sometimes it seems ODE is just ignoring=20
> about half of the triangles.

=46rom what I've found, dGeomTriMeshDataBuildSingle1 should only be used
with single precision numbers and dGeomTriMeshDataBuildDouble1 with
doubles. TriMeshData.build was using BuildSingle1 even if ODE was built
with double precision dReals resulting in incorrect vertex data. I've
fixed this in CVS by replacing the call to dGeomTriMeshDataBuildSingle1
with one to dGeomTriMeshDataBuildSimple.

Furthermore, it seems that these functions take the number of
indices--not the number faces as was being passed before. This could
explain why ODE was ignoring some of the triangles.

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

Re: [Pyode-user] TriMesh stuff

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

Cool, installed and tested it.  tutorial2.py and test_xode.py both work; haven't installed pygame
or PyOpenGL to test the others yet.

Cheers,
-brett


--- Matthias Baas <ba...@ir...> wrote:

> brett hartshorn wrote:
> > Traceback (most recent call last):
> >   File "<stdin>", line 1, in ?
> > ImportError: /usr/lib/python2.2/site-packages/ode.so: undefined symbol:
> dGeomTriMeshGetTriangle
> > 
> > I guess that i should disable the OPCODE and Trimesh stuff?
> 
> Exactly. I've just checked in a modification that allows you to disable 
> trimesh support in the setup script. If you set the variable 
> TRIMESH_SUPPORT to False you only get dummy trimesh classes and no 
> trimesh C function should be called within the module.
> 
> 
> Here's what I did: I've moved the trimesh geom class out of geoms.pyx 
> into its own file trimesh.pyx. The setup script creates an intermediate 
> file _trimesh_switch.pyx that either includes the files trimesh.pyx and 
> trimeshdata.pyx or the file trimesh_dummy.pyx. This intermediate file is 
> included in ode.pyx.
> The file trimesh_dummy.pyx also defines the TriMeshData and GeomTriMesh 
> classes but they will raise NotImplementedError exceptions in their 
> constructors.
> 
> - Matthias -
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by OSTG. Have you noticed the changes on
> Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now,
> one more big change to announce. We are now OSTG- Open Source Technology
> Group. Come see the changes on the new OSTG site. www.ostg.com
> _______________________________________________
> Pyode-user mailing list
> Pyo...@li...
> https://lists.sourceforge.net/lists/listinfo/pyode-user
> 



		
__________________________________
Do you Yahoo!?
Yahoo! Mail - 50x more storage than other providers!
http://promotions.yahoo.com/new_mail

Re: [Pyode-user] TriMesh stuff

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

brett hartshorn wrote:
> Traceback (most recent call last):
>   File "<stdin>", line 1, in ?
> ImportError: /usr/lib/python2.2/site-packages/ode.so: undefined symbol: dGeomTriMeshGetTriangle
> 
> I guess that i should disable the OPCODE and Trimesh stuff?

Exactly. I've just checked in a modification that allows you to disable 
trimesh support in the setup script. If you set the variable 
TRIMESH_SUPPORT to False you only get dummy trimesh classes and no 
trimesh C function should be called within the module.


Here's what I did: I've moved the trimesh geom class out of geoms.pyx 
into its own file trimesh.pyx. The setup script creates an intermediate 
file _trimesh_switch.pyx that either includes the files trimesh.pyx and 
trimeshdata.pyx or the file trimesh_dummy.pyx. This intermediate file is 
included in ode.pyx.
The file trimesh_dummy.pyx also defines the TriMeshData and GeomTriMesh 
classes but they will raise NotImplementedError exceptions in their 
constructors.

- Matthias -

Re: [Pyode-user] TriMesh stuff

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

Cool thanks, it builds and installs now.  But i'm gettin this error:
>>> import ode
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
ImportError: /usr/lib/python2.2/site-packages/ode.so: undefined symbol: dGeomTriMeshGetTriangle

I guess that i should disable the OPCODE and Trimesh stuff?

-brett


		
__________________________________
Do you Yahoo!?
New and Improved Yahoo! Mail - Send 10MB messages!
http://promotions.yahoo.com/new_mail 

Re: [Pyode-user] TriMesh stuff

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

On Thu, 2004-07-29 at 12:04, Matthias Baas wrote:
> By the way, what's the preferred location for the ODE include files and=20
> libs on Linux? Should the script use something like /usr/include and=20
> /usr/lib as default paths? Or do you actually keep ODE in a separate=20
> directory?

The ODE documentation gives /usr/local/include and /usr/local/lib as
examples. If users compile ODE themselves, this is probably where they
will put them. However, if they install ODE with a binary package (like
an RPM, DEB or Ebuild), it will probably be installed in /usr/include
and /usr/lib.

> I'll commit the modified setup script later today. Or are there any=20
> objections (i.e. is there a reason why you can't upgrade to Pyrex 0.9.3)?

No objections; I am looking forward to it.

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

Re: [Pyode-user] TriMesh stuff

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

On Thursday 29 July 2004 11:19, Matthias Baas wrote:
> Chris Bainbridge wrote:
> > If I remove GeomTriMesh class from geoms.pyx there is no problem. So I
> > guess my question is 1) can the pyode script automagically detect whether
> > this class is available and wrap appropriately?
>
> Maybe an option to exclude trimesh support should really be added as
> I've just noticed that compiling PyODE with double precision (that has
> no trimesh support) also results in linker errors.
>
> I'll see if I can get that done this weekend.
>
> - Matthias -

I just compiled both with double precision and didn't get any errors. At least 
'import ode' now works, thats the furthest I've got so far ;-) 

Re: [Pyode-user] TriMesh stuff

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

On Thursday 29 July 2004 05:16, Timothy Stranex wrote:
> On Thu, 2004-07-29 at 02:18, Chris Bainbridge wrote:
> > 2) Is nobody else using linux? How
> > are you guys compiling the Opcode library?
>
> I'm using Gentoo Linux. I used the OPCODE sources that came in the ODE
> distribution. I think they've been modified to work on Linux. In your
> user-settings file, set OPCODE_DIRECTORY=OPCODE and it should compile.

Thanks, it worked, can't believe it was that easy! The ode readme specifically 
states it won't build opcode for you, but it will.

Re: [Pyode-user] TriMesh stuff

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

Chris Bainbridge wrote:
> If I remove GeomTriMesh class from geoms.pyx there is no problem. So I guess 
> my question is 1) can the pyode script automagically detect whether this 
> class is available and wrap appropriately? 

Maybe an option to exclude trimesh support should really be added as 
I've just noticed that compiling PyODE with double precision (that has 
no trimesh support) also results in linker errors.

I'll see if I can get that done this weekend.

- Matthias -