pyode-user — PyODE User Discussions

Re: [Pyode-user] XODE

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

I was about to start doing this myself.   :-)

I notice you're using a SAX-based parsers, which is what I was planning to do.

However, there is a complication.  The XODE spec (thank you to whoever sent
me the URL -- much appreciated) allows <geom> elements to exist with no
indication of what shape they are.  This makes things needlessly complex,
since in ODE one cannot create a geom without knowing what shape it is,
so one has to keep track of all kinds of information about the geom in the
XODE parser before encountering the <box> or <sphere> or whatever node
gives its shape.

This is a serious enough issue that I would propose that we contact the XODE
folks and ask them to change to using <geomBox>, <geomSphere>, etc,
or having a mandatory "shape" attribute on <geom>.  They already seem to make
reference to such a shape attribute, but it doesn't appear to be mandatory.

I think the <geomBox> (etc) approach is much cleaner, since there is then
a more direct correpsondence between the element tags and the ODE objects.
It also means that different elements can have different attributes (e.g. a 
geomSphere
would have a radius attribute).

I'm going to be very busy starting (checking my watch... now!), so would 
someone
here who has been following the XODE work be able to pass along that 
suggestion,
assuming you agree with it?



At 08:42 PM 6/25/2004 +0200, Timothy Stranex wrote:
>Hey,
>
>I've checked the XODE specification and I think it should be implemented
>in pure Python. I started writing an importer today using the
>xml.parsers.expat module. It's very incomplete with just basic skeleton
>code (I have not even bothered trying to test it yet) but I would like
>to hear your comments on the interface.
>
>The code is attached as xode.py.
>
>--
>Timothy Stranex <ti...@st...>
>

--
   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] Initial (re)design questions

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

I've used CObjects in SWIG-based wrappers that I've written for other 
projects, and
they work well.  I've never done it with Pyrex, but I don't think it would 
be difficult.

The only downside to this approach is that the data is opaque to Python.  I 
think
in some ways that's a good thing, but I can also think of cases where it 
might be
useful to expose the vertex and triangle data to the Python application.

However, the best solution to that is probably to provide a separate, 
graphics-engine-specific
method for exposing that data, and to simply hand vertex and index buffers 
from the
engine to ODE as CObjects.

To me, the big question has to do with floats vs doubles (which was of 
course raised earlier).
All the graphics engines I've ever used (and there are quite a few of them) 
have represented
vertex positions using floats.  There simply are not any situations that 
I'm aware of where
vertex positions need to be expressed in double precision.

If we're content to run ODE in single precision mode, then things are of 
course very easy.

The question arises "what if we want to use double-precision in ODE, but 
support trimeshes
from graphics engines that use single-precision?".  Who does the conversion?

Clearly, we cannot do it in Python.  So it either has to be done by the 
engine interface, or by
PyODE.  I'm very much of two minds about this.  On the one hand I'm 
thinking that the person
who's interfacing the engine to their application already has to write a 
small amount of interface
code to get the vertex and index arrays out of the engine and pass them (as 
CObjects) to
PyODE.  We can simply put the burden of float-to-double conversion on them 
if they want
to run ODE in double precision.

The other approach would be to have PyODE do the work, since it should know 
whether it's
been built in single- or double-precision mode.  This simplifies things for 
people using the
graphics engines (assuming their data is made up of floats).

One consideration is where the data gets stored.  The ODE documentation 
(page 65) says
"no data is copied here, so the pointers passed into this function must 
remain valid".  That
means that whoever does the conversion from float to double has to allocate 
memory for the
array of doubles, and keep track of that memory if it ever needs to be 
released.  That's a big
nuisance for PyODE, but perhaps not so bad for the person who's already 
dealing with the
graphics library.

I would therefore say that it's probably best to keep PyODE simple, and 
have two versions
(one built as single precision and one as double precision).  If the 
application developer is
content to run single-precision, then their job of getting the data out of 
the engine will be
very easy (this is the most common case).  If they choose to use the 
double-precision
PyODE, and their engine uses single-precision, then they have to allocate 
the memory to
hold the double-precision vertex data and do the conversion themselves.

What do other people think?


At 03:02 PM 6/25/2004 +0200, Timothy Stranex wrote:
>On Fri, 2004-06-25 at 09:28, Timothy Stranex wrote:
> > On Fri, 2004-06-25 at 02:31, brett hartshorn wrote:
> > > It would be nice to have some fast C functions that can convert ODE's 
> dReals vertices to osg's
> > > Vec3 vertices and pass that object directly to an osg geode.  These 
> functions could then be
> > > exposed to Python, then we would not have to do the conversion in 
> Python using tuples as the
> > > middle-man.  It sounds like its going to be hard, any ideas?
> >
> > A function capable of doing that would need to know the internal
> > structure of the Python Geode class and the C++ Geode class. To do that,
> > PyODE would have the added dependencies of both PyOSG and OSG.
> >
> > I like Bernie's intermediate array module idea. PyOSG, Python-Ogre
> > bindings and PyODE will each need to implement an importer and exporter
> > from the internal types to the array object. Since the array module is
> > already part of Python, it isn't an extra dependency.
>
>I just noticed this in Python's Extending/Embedding documentation:
>
>     Python provides a special mechanism to pass C-level information
>     (pointers) from one extension module to another one: CObjects. A
>     CObject is a Python data type which stores a pointer (void *).
>     CObjects can only be created and accessed via their C API, but they
>     can be passed around like any other Python object. In particular,
>     they can be assigned to a name in an extension module's namespace.
>     Other extension modules can then import this module, retrieve the
>     value of this name, and then retrieve the pointer from the CObject.
>
>The rest is at http://www.python.org/doc/2.3.3/ext/using-cobjects.html.
>
>--
>Timothy Stranex <ti...@st...>

--
   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] XODE

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

Hey,

I've checked the XODE specification and I think it should be implemented
in pure Python. I started writing an importer today using the
xml.parsers.expat module. It's very incomplete with just basic skeleton
code (I have not even bothered trying to test it yet) but I would like
to hear your comments on the interface.

The code is attached as xode.py.

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

Trimesh support (was: [Pyode-user] Initial (re)design questions)

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

Timothy Stranex wrote:
> On Fri, 2004-06-25 at 02:31, brett hartshorn wrote:
>>It would be nice to have some fast C functions that can convert ODE's dReals vertices to osg's
>>Vec3 vertices and pass that object directly to an osg geode.  These functions could then be
>>exposed to Python, then we would not have to do the conversion in Python using tuples as the
>>middle-man.  It sounds like its going to be hard, any ideas?
> 
> A function capable of doing that would need to know the internal
> structure of the Python Geode class and the C++ Geode class. To do that,
> PyODE would have the added dependencies of both PyOSG and OSG.

In my opinion, we should keep PyODE free from additional dependencies. 
This means the data has to be passed in a library independent way.

While musing about the problem a bit I wondered if it's really that 
essential to pass the data between a 3D engine and PyODE.
"Where does the data come from?" I can also ask that question when 
looking at the 3D engine which doesn't produce the data. I would say 
it's usually a 3D modeller where the data is produced. So we rather need 
a way to read the data produced from those modellers. And isn't that the 
reason why they developed the XODE format? So having an XODE importer 
might probably be more important than I thought in the beginning. I 
think the chances are not that bad that there will be plugins for the 
most popular 3D packages that can export XODE.

Another point is, that I think it's not uncommon to have different 
meshes for rendering and for collision detection. You want to keep the 
collision meshes as simple as possible to get interactive rates whereas 
you want the displayed mesh to be as "nice" and smooth as possible.
It might even be the case that an entirely different representation is 
used for rendering such as subdivision surfaces or NURBS patches.

Well, I don't say a direct connection to a 3D engine wouldn't be useful, 
  I only thought that there also has to be another way so we can deal 
with the above points.

- Matthias -

Re: [Pyode-user] Initial (re)design questions

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

--- Timothy Stranex <ti...@st...> wrote:
> On Fri, 2004-06-25 at 09:28, Timothy Stranex wrote:
> > On Fri, 2004-06-25 at 02:31, brett hartshorn wrote:
> > > It would be nice to have some fast C functions that can convert ODE's dReals vertices to
> osg's
> > > Vec3 vertices and pass that object directly to an osg geode.  These functions could then be
> > > exposed to Python, then we would not have to do the conversion in Python using tuples as the
> > > middle-man.  It sounds like its going to be hard, any ideas?
> > 
> > A function capable of doing that would need to know the internal
> > structure of the Python Geode class and the C++ Geode class. To do that,
> > PyODE would have the added dependencies of both PyOSG and OSG.
> > 
> > I like Bernie's intermediate array module idea. PyOSG, Python-Ogre
> > bindings and PyODE will each need to implement an importer and exporter
> > from the internal types to the array object. Since the array module is
> > already part of Python, it isn't an extra dependency.
> 
> I just noticed this in Python's Extending/Embedding documentation:
> 
>     Python provides a special mechanism to pass C-level information
>     (pointers) from one extension module to another one: CObjects. A
>     CObject is a Python data type which stores a pointer (void *).
>     CObjects can only be created and accessed via their C API, but they
>     can be passed around like any other Python object. In particular,
>     they can be assigned to a name in an extension module's namespace.
>     Other extension modules can then import this module, retrieve the
>     value of this name, and then retrieve the pointer from the CObject.
> 
> The rest is at http://www.python.org/doc/2.3.3/ext/using-cobjects.html.
> 

looks like CObjects are the way to go.  The doc had a good example, it does not look like too much
of a hack.

-brett




		
__________________________________
Do you Yahoo!?
Yahoo! Mail Address AutoComplete - You start. We finish.
http://promotions.yahoo.com/new_mail 

Re: [Pyode-user] Initial (re)design questions

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

On Fri, 2004-06-25 at 09:28, Timothy Stranex wrote:
> On Fri, 2004-06-25 at 02:31, brett hartshorn wrote:
> > It would be nice to have some fast C functions that can convert ODE's d=
Reals vertices to osg's
> > Vec3 vertices and pass that object directly to an osg geode.  These fun=
ctions could then be
> > exposed to Python, then we would not have to do the conversion in Pytho=
n using tuples as the
> > middle-man.  It sounds like its going to be hard, any ideas?
>=20
> A function capable of doing that would need to know the internal
> structure of the Python Geode class and the C++ Geode class. To do that,
> PyODE would have the added dependencies of both PyOSG and OSG.
>=20
> I like Bernie's intermediate array module idea. PyOSG, Python-Ogre
> bindings and PyODE will each need to implement an importer and exporter
> from the internal types to the array object. Since the array module is
> already part of Python, it isn't an extra dependency.

I just noticed this in Python's Extending/Embedding documentation:

    Python provides a special mechanism to pass C-level information
    (pointers) from one extension module to another one: CObjects. A
    CObject is a Python data type which stores a pointer (void *).
    CObjects can only be created and accessed via their C API, but they
    can be passed around like any other Python object. In particular,
    they can be assigned to a name in an extension module's namespace.
    Other extension modules can then import this module, retrieve the
    value of this name, and then retrieve the pointer from the CObject.

The rest is at http://www.python.org/doc/2.3.3/ext/using-cobjects.html.

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

Re: [Pyode-user] Initial (re)design questions

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

On Thu, 2004-06-24 at 22:49, Matthias Baas wrote:
> Uhm, I must confess that I don't remember the details why I switched
> to a global dictionary....
> I suppose it wasn't that straightforward to get to the dictionary
> inside the space from within the near callback. Well, but if there's
> a better solution it'll be fine with me if we change the code.

I've written some code that implements addGeom(), delGeom() and
_getGeom() for Space and passes the Space as an argument to
near_callback. It seems to work fine with your collision detection
tutorial but I'm probably overlooking something.

Also, I've just noticed that ODE has dSpaceAdd and dSpaceRemove
functions.

> Actually, I don't know why it works for me *without* specifying the
> lib....

Perhaps you're ODE library has stdc++ statically linked?

> So unless someone of you would like to use Leo I'd rather remove
> the markup.

Go ahead. I use GNU Emacs. This is unrelated but I recommend that we use
epydoc markup (http://epydoc.sourceforge.net/) in the docstrings for API
documentation (where it is needed).

> Another thing is, I'd rather like to split the Pyrex file into several
> smaller files as currently it has over 2600 lines which is a rather
> big chunk (back then, a Pyrex file could not include other Pyrex
> files, but now this is possible).

Agreed.

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

Re: [Pyode-user] Initial (re)design questions

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

On Fri, 2004-06-25 at 02:31, brett hartshorn wrote:
> It would be nice to have some fast C functions that can convert ODE's dRe=
als vertices to osg's
> Vec3 vertices and pass that object directly to an osg geode.  These funct=
ions could then be
> exposed to Python, then we would not have to do the conversion in Python =
using tuples as the
> middle-man.  It sounds like its going to be hard, any ideas?

A function capable of doing that would need to know the internal
structure of the Python Geode class and the C++ Geode class. To do that,
PyODE would have the added dependencies of both PyOSG and OSG.

I like Bernie's intermediate array module idea. PyOSG, Python-Ogre
bindings and PyODE will each need to implement an importer and exporter
from the internal types to the array object. Since the array module is
already part of Python, it isn't an extra dependency.

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

Re: [Pyode-user] Initial (re)design questions

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

--- Matthias Baas <ba...@ir...> wrote:
> Bernie Roehl wrote:
> > in) into Python, and then from Python back into C for ODE to use.  I 
> > think the more common case by far will be simply passing the data from 
> > the 3D engine to ODE directly.  Perhaps this can be done using Python's 
> > array module (not the one in Numeric, the other one).  Something to 
> > explore.
> 
> How do we get to the mesh data when using a particular 3D engine? Which 
> engines are available from Python? Brett mentioned PyOpenGL, vtk and 
> PyOSG. So far, I've only used PyOpenGL and that's really only a direct 
> binding of the OpenGL API which does not have any mesh import 
> functionality or a mesh data structure (maybe in OpenGLContext, but I've 
> never used that one).
> Brett, how would that work for PyOSG? Can the vertices and faces 
> directly be accessed from Python?
> 

OSG has a Geode class that holds all the vertices, faces, uvs and normals that make up a mesh
object.  Vertices and faces can be accessed to/from Python, below is how you can build a cube in
PyOSG, in c++ it looks pretty much the same - just replace 'self' with 'geode->'  Once you have
passed the geode all the data it turns it into an OpenGL display list so it renders quickly.  If
triangle data is not being passed from ODE to OSG every frame then it should be pretty fast.

It would be nice to have some fast C functions that can convert ODE's dReals vertices to osg's
Vec3 vertices and pass that object directly to an osg geode.  These functions could then be
exposed to Python, then we would not have to do the conversion in Python using tuples as the
middle-man.  It sounds like its going to be hard, any ideas?

-brett

def makeCube(self):
	self.addPrimitiveSet(osg.DrawArrays(osg.PrimitiveSet.POLYGON,0,4))
	self.addPrimitiveSet(osg.DrawArrays(osg.PrimitiveSet.POLYGON,4,4))
	self.addPrimitiveSet(osg.DrawArrays(osg.PrimitiveSet.POLYGON,8,4))
	self.addPrimitiveSet(osg.DrawArrays(osg.PrimitiveSet.POLYGON,12,4))
	self.addPrimitiveSet(osg.DrawArrays(osg.PrimitiveSet.POLYGON,16,4))
	self.addPrimitiveSet(osg.DrawArrays(osg.PrimitiveSet.POLYGON,20,4))

	# set up coords.
	coords = osg.Vec3Array()
	coords.resize(24)
	coords[0].set( -1.0000,   1.0000,  -1.000 )
	coords[1].set( 1.0000,   1.0000,  -1.0000 )
	coords[2].set( 1.0000,  -1.0000,  -1.0000 )
	coords[3].set( -1.0000,  -1.0000,  -1.000 )

	coords[4].set( 1.0000,   1.0000,  -1.0000 )
	coords[5].set( 1.0000,   1.0000,   1.0000 )
	coords[6].set( 1.0000,  -1.0000,   1.0000 )
	coords[7].set( 1.0000,  -1.0000,  -1.0000 )

	coords[8].set( 1.0000,   1.0000,   1.0000 )
	coords[9].set( -1.0000,   1.0000,   1.000 )
	coords[10].set( -1.0000,  -1.0000,   1.000 )
	coords[11].set( 1.0000,  -1.0000,   1.0000 )

	coords[12].set( -1.0000,   1.0000,   1.000 )
	coords[13].set( -1.0000,   1.0000,  -1.000 )
	coords[14].set( -1.0000,  -1.0000,  -1.000 )
	coords[15].set( -1.0000,  -1.0000,   1.000 )

	coords[16].set( -1.0000,   1.0000,   1.000 )
	coords[17].set( 1.0000,   1.0000,   1.0000 )
	coords[18].set( 1.0000,   1.0000,  -1.0000 )
	coords[19].set( -1.0000,   1.0000,  -1.000 )

	coords[20].set( -1.0000,  -1.0000,   1.000 )
	coords[21].set( -1.0000,  -1.0000,  -1.000 )
	coords[22].set( 1.0000,  -1.0000,  -1.0000 )
	coords[23].set( 1.0000,  -1.0000,   1.0000 )

	self.setVertexArray(coords)

	# set up the normals.
	cubeNormals = osg.Vec3Array()
	cubeNormals.resize(6)

	cubeNormals[0].set(0.0,0.0,-1.0)
	cubeNormals[1].set(1.0,0.0,0.0)
	cubeNormals[2].set(0.0,0.0,1.0)
	cubeNormals[3].set(-1.0,0.0,0.0)
	cubeNormals[4].set(0.0,1.0,0.0)
	cubeNormals[5].set(0.0,-1.0,0.0)

	self.setNormalArray( cubeNormals )
	self.setNormalBinding(osg.Geometry.BIND_PER_PRIMITIVE )

	cubeState = osg.StateSet()
	redMaterial = osg.Material()
	red = osg.Vec4(1.0, 0.0, 0.0, 1.0)
	redMaterial.setDiffuse(osg.Material.FRONT_AND_BACK, red)
	cubeState.setAttribute(redMaterial)

	self.setStateSet(cubeState)



		
__________________________________
Do you Yahoo!?
Yahoo! Mail is new and improved - Check it out!
http://promotions.yahoo.com/new_mail

Re: [Pyode-user] Initial (re)design questions

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

At 04:49 PM 6/24/2004, Matthias Baas wrote:
>How do we get to the mesh data when using a particular 3D engine? Which 
>engines are available from Python?

I'm working on a wrapper for Ogre (www.ogre3d.org), but my guess is that 
the vertex and triangle data will be available as simple C arrays of floats 
and ints respectively in almost any engine.

>>>6) double vs float. What type do we use?
>>Can't we just change the typedef for dReal, and rebuild with the 
>>appropriate version of ODE?
>
>Will the trimesh support (or rather, Opcode) work if doubles are used?

I think the trimesh support will have to convert floats into dReals.

>>>8) Shall we try to implement an XODE import/export in Python?
>>I've been trying to find information about XODE, and have had no luck.
>>Am I just looking in the wrong places?
>
>Here are all the revisions of the spec:
>
>http://tankammo.com/xode/

Thanks!

>So unless someone of you would like to use Leo I'd rather remove the markup.

That was the first thing I did when I downloaded PyODE.  :-)

>Another thing is, I'd rather like to split the Pyrex file into several 
>smaller files as currently it has over 2600 lines which is a rather big 
>chunk (back then, a Pyrex file could not include other Pyrex files, but 
>now this is possible).

I'm open to that, but I don't think it's a big problem either way.


--
    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] Initial (re)design questions

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

Bernie Roehl wrote:
> in) into Python, and then from Python back into C for ODE to use.  I 
> think the more common case by far will be simply passing the data from 
> the 3D engine to ODE directly.  Perhaps this can be done using Python's 
> array module (not the one in Numeric, the other one).  Something to 
> explore.

How do we get to the mesh data when using a particular 3D engine? Which 
engines are available from Python? Brett mentioned PyOpenGL, vtk and 
PyOSG. So far, I've only used PyOpenGL and that's really only a direct 
binding of the OpenGL API which does not have any mesh import 
functionality or a mesh data structure (maybe in OpenGLContext, but I've 
never used that one).
Brett, how would that work for PyOSG? Can the vertices and faces 
directly be accessed from Python?

>> 6) double vs float. What type do we use?
> 
> Can't we just change the typedef for dReal, and rebuild with the 
> appropriate version of ODE?

Will the trimesh support (or rather, Opcode) work if doubles are used?

>> 8) Shall we try to implement an XODE import/export in Python?
> 
> I've been trying to find information about XODE, and have had no luck.  
> Am I just looking in the wrong places?

Here are all the revisions of the spec:

http://tankammo.com/xode/


Timothy Stranex wrote:
> I noticed you have commented out the Space.addgeom(). Why is that?
> Wouldn't it and a removegeom() method remove the need for a global geom
> dictionary?

Uhm, I must confess that I don't remember the details why I switched to 
a global dictionary....
I suppose it wasn't that straightforward to get to the dictionary inside 
the space from within the near callback. Well, but if there's a better 
solution it'll be fine with me if we change the code.

> When I tried to import your PyODE in Python, it gave "undefined symbol:
> __cxa_pure_virtual". After some Googling, I added "stdc++" to LIBS in
> setup.py which fixed the problem. 

That was the most common problem people had when compiling the module. 
But I was never able to reproduce that error message.... but anyway, the 
file generated by Pyrex is a C file so the compiler thinks we're dealing 
with pure C and doesn't link the C++ lib. But as ODE is C++ the lib is 
needed and has to be specified manually. Actually, I don't know why it 
works for me *without* specifying the lib....


I'll try to brush up my code this weekend (adding Bernie's changes, 
translating comments, etc.) so that we can get it into cvs from where 
you can check out your copy. I'll also try to do a list of what's still 
to do.
By the way, if you've already looked at my pyx file you might have 
wondered about lines like this:

#@+leo
#@+node:0::@file ode.pyx
#@+body

This is markup from Leo, an outlining editor 
(http://webpages.charter.net/edreamleo/front.html). I used it for the 
binding as a test, but even though I see its advantages, it didn't 
manage to replace my usual coding editor (which is just XEmacs, even 
though I'm on Windows... ;) However, I'm using Leo for other tasks and 
can recommend it nevertheless...).
So unless someone of you would like to use Leo I'd rather remove the markup.

Another thing is, I'd rather like to split the Pyrex file into several 
smaller files as currently it has over 2600 lines which is a rather big 
chunk (back then, a Pyrex file could not include other Pyrex files, but 
now this is possible).
(I hope the author of Leo isn't reading this because Leo would be a 
solution to keep the file as one file and still have smaller, manageable 
chunks... ;-) ...however, I don't want to impose a particular editor on 
you).
So are there any objections?

- Matthias -

Re: [Pyode-user] Status of the wrappers?

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

The money has been kindly provided by AwareMedia, so you can thank them for it.  They are funding
artists, and programming is one of the art forms they are supporting.

I think we should vote on who gets the bounty when we have a release done.  Democracy i think is
the only fair way to decide these things.

-brett

--- Bernie Roehl <br...@ec...> wrote:
> Hmm... that's very nice of you to offer.  I would suggest the money goes to 
> Matthias, for these reasons...
> 
> 1) The code is his, I'm just making small changes to it
> 
> 2) When I do commercial projects, $300 isn't much money
> 
> 3) When I do non-commercial projects, $300 is way too much!  *smile*
> 
> 
> 



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

Re: [Pyode-user] Initial (re)design questions

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

> 
> 1) Which tool to use for creating the wrappers?
> 
> I think the most common tools are Boost.Python, SWIG, Pyrex and ctypes....

Pyrex looks like our best bet.  Boost is great, but it can get crazy sometimes, ever had to use a
pointer to a member function?  It's some wacky shit.
(void (libraryName::myClass::*) (float, float) const)


> 
> 2) Should we wrap the C functions or the C++ classes?
> 
> Here's my opinion: I'd go for the C functions because they belong to the 
> official and *documented* API.

Agreed.

> 
> 3) How do we map the ODE API to Python?
> 
> Well, you see my preference if you look at my binding... ;)
> I've put everything in classes and the functions became methods. Every 
> joint type got its own class (instead of just *one* joint class). The 
> same holds for geoms. In general, I'm always in favour of a "Pythonic" 
> interface, even if that would mean that we would have to change the 
> original interface slightly.
> Oh, what's also nice is the ability to pass any Python 3-sequence where 
> ODE actually expects a vector. This way, you can still choose to use the 
> vector type of your choice (or just plain tuples).

Sounds good to me.

> 
> 4) How do we implement the collision callback mechanism?
> 
> In my version, I tried to do it just as it is done in C with the near 
> callback that can now be implemented in Python.
> However, there's the above mentioned problem with the lookup table that 
> so far can only grow, but never gets smaller again.
> What might also be desireable is the ability to use a "default" callback 
> that's implemented in C so that no Python code has to be called during a 
> simulation. If you have a lot of objects this Python callback can 
> actually slow down the simulation too much.

this sounds like it could be a tricky issue.  I've experienced massive slow downs in PyOSG using
too many transform callbacks.  I think the situation here is similiar.

> 
> 5) Trimesh support?
> 
> I suppose, everyone wants to have that, right? ;-)
> But how do we pass the data?

Bernie brought up a good point "where does the data come from?"  Seems like a bad idea to
per-frame be sending vertices as python tuples back and forth from ODE to python then to a
renderer.  Rendering in python is always going to be done by another library like PyOpenGL, VTK,
or PyOSG.  So it would be best if PyODE could directly connect to the other wrappers and pass data
around.  PyOSG would be ideal for me personally, since that is the primary renderer i am using.
http://opart.org/pyosg/

Some people have already started on the OSG ODE integration, Kenneth Holmlund maybe able to help
us with that.  http://q12.org/pipermail/ode/2004-March/011629.html


> 
> 7) What build system do we use?
> 
> I would really recommend using the distutils as this is the standard way 
> for distributing Python extension modules. It has the advantage that 
> building the module works the same on every platform.

Agreed.

> 
> 8) Shall we try to implement an XODE import/export in Python?
> 
> This might raise the popularity of the Python version...

Agreed, this would be great.

> 
> 9) Which operating systems can we support directly?
> 
> Or in other words: What systems are you working on? I'm mainly on 
> Windows XP and can occasionally do tests on Linux (SuSE 8.2).

I am using redhat 8 and 9, fedora core1, and debian.  Although i may switch over to just Debian
and Morphix soon.

> 
> 10) ...what else?...

funny that we are all spread so far all over the world, i guess there is not going to be any PyODE
parties in the near future.

-brett



	
		
__________________________________
Do you Yahoo!?
New and Improved Yahoo! Mail - 100MB free storage!
http://promotions.yahoo.com/new_mail 

Re: [Pyode-user] Initial (re)design questions

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

On Wed, 2004-06-23 at 00:07, Matthias Baas wrote:
> And I think by using Pyrex we make it much=20
> easier to enable them to compile the module themselves. Pyrex is a small=20
> tool and it's easy to install and try out.

Agreed. I've had a look at your code and they Pyrex manual and I
definitely feel it is the best way to go.

> That's why I have
> a lookup table called "_geom_c2py_lut" in the module. This is just a=20
> dictionary that maps C pointers to Python objects. The problem now is,=20
> that Pyrex didn't support weak references at the time I was writing the=20
> module. As a result, I wasn't able to remove entries from this lookup=20
> table when the corresponding object was destroyed.

I noticed you have commented out the Space.addgeom(). Why is that?
Wouldn't it and a removegeom() method remove the need for a global geom
dictionary?

> Here's my opinion: I'd go for the C functions because they belong to the=20
> official and *documented* API.

Agreed.

> In general, I'm always in favour of a "Pythonic" interface, even if that
> would mean that we would have to change the original interface slightly.

Agreed.

> 7) What build system do we use?
> I would really recommend using the distutils as this is the standard way=20
> for distributing Python extension modules. It has the advantage that=20
> building the module works the same on every platform.

Agreed.

> 8) Shall we try to implement an XODE import/export in Python?
> This might raise the popularity of the Python version...

Yes. It looks pretty cool.

> 9) Which operating systems can we support directly?
> Or in other words: What systems are you working on? I'm mainly on=20
> Windows XP and can occasionally do tests on Linux (SuSE 8.2).

I'm working exclusively on Gentoo Linux.

> 10) ...what else?...

When I tried to import your PyODE in Python, it gave "undefined symbol:
__cxa_pure_virtual". After some Googling, I added "stdc++" to LIBS in
setup.py which fixed the problem. I think it's a problem with Gentoo's
ODE package.

Your collision tutorial demo has inspired me to work on PyODE again...

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

Re: [Pyode-user] Status of the wrappers?

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

Hmm... that's very nice of you to offer.  I would suggest the money goes to 
Matthias, for these reasons...

1) The code is his, I'm just making small changes to it

2) When I do commercial projects, $300 isn't much money

3) When I do non-commercial projects, $300 is way too much!  *smile*



At 02:38 PM 6/22/2004, brett hartshorn wrote:
>Hello Bernie and Matthias,
>
>Clean and quick with Pyrex sounds like a good plan, i wish you luck.  I 
>won't be able to help with
>any of the code for the next 2-3 months.  But in two months i am quitting 
>my day job to make more
>time for working on free software projects, and then i may have time to help.
>
>I want to see the ODE wrappers done and done well.  So i am putting a $300 
>bounty on them.  This
>bounty is not meant to make people fight, everyone should still work 
>together as much as possible.
>  I just know from my own experiences it can be hard to work on free 
> software and pay the bills, so
>this bounty is just meant to help out the developer a little bit.
>
>Here's the conditions for the bounty:
>   1. All the features of ODE are exposed in Python (within reason, not 
> every little thing, but all
>of the important stuff)
>   2. The code is clean and easy to build (clean: i should have no 
> problems in reading it) (easy to
>build: can be built on all platforms)
>   3. It is licensed under the GNU GPL or LGPL
>
>
>Thoughts?
>-brett
>
>
>--- Bernie Roehl <br...@ec...> wrote:
> > At 11:05 AM 6/21/2004 -0700, brett hartshorn wrote:
> > >Wrapping a
> > >wrapper is not ideal, but from the perspective where several python
> > >wrappers must be created and
> > >maintained, it makes sense that they all use the same wrapping language.
> >
> > Perhaps, though I think it depends on the circumstances.
> >
> > For example, in the project I'm working on, I'm wrapping a C++ graphics
> > library using SWIG and
> > wrapping ODE using Pyrex.  My reasoning is that the C++ graphics API is 
> one
> > project, the
> > ODE wrapper is another, and my main project simply imports modules from 
> the
> > other two.
> >
> > In fact, I initially just used Mattias' PyODE without even knowing that it
> > was written
> > using Pyrex -- it was just a .pyd that I imported.  The fact that I am now
> > modifying some of the
> > code in that wrapper doesn't really change anything --  the main project
> > doesn't care where the .pyd
> > files came from or what tools were used to create them.
> >
> > That means we can use the right tool for the job in each case.  Since ODE
> > is written in C, it makes
> > sense to use Pyrex.  Since the graphics library is written in C++, it 
> makes
> > sense to use SWIG.
> > For other things, it makes sense to use Boost.  I could easily see a 
> Python
> > application that
> > imports modules that were created using all three tools, and the
> > application developer doesn't need
> > to know.
> >
> > >So it is a blancing act, do we
> > >shoehorn ODE to fit into the Boost model, or do it the clean and quick 
> way
> > >with Pyrex?
> >
> > I vote for clean and quick.  :-)
> >
> > >Btw, is anybody in the San Francisco area?
> >
> > I'm in Waterloo, Ontario Canada (about an hour west of Toronto).
> >
> >
> > --
> >    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
> >
> >
> >
> > -------------------------------------------------------
> > This SF.Net email sponsored by Black Hat Briefings & Training.
> > Attend Black Hat Briefings & Training, Las Vegas July 24-29 -
> > digital self defense, top technical experts, no vendor pitches,
> > unmatched networking opportunities. Visit www.blackhat.com
> > _______________________________________________
> > Pyode-user mailing list
> > Pyo...@li...
> > https://lists.sourceforge.net/lists/listinfo/pyode-user
> >
>
>
>
>
>__________________________________
>Do you Yahoo!?
>Yahoo! Mail is new and improved - Check it out!
>http://promotions.yahoo.com/new_mail

--
    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] Status of the wrappers?

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

At 02:28 PM 6/22/2004, Timothy Stranex wrote:
>Please tell me your sourceforge.net usernames so I can add you to the
>PyODE project. Shall I'll remove the current code from CVS and import
>Matthias's code?

I'm broehl on sourceforge.

I would suggest keeping what's on CVS now (or moving it into a separate
branch) and adding a branch for Matthias'  code.  I'll email him the changes
I made to add setCategoryBits() and setCollideBits().


--
    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] Initial (re)design questions

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

At 12:07 AM 6/23/2004 +0200, Matthias Baas wrote:
>I think the most common tools are Boost.Python, SWIG, Pyrex and ctypes. It 
>seems you've already agreed on Pyrex. Currently, I'm using Boost.Python 
>for another project, so I also have a little experience here as well (by 
>the way, that other project might eventually turn into the second version 
>of cgkit, my other Open Source project at cgkit.sf.net.

I didn't reallize you were the author of cgkit as well.  I use it all the time!

>Now to Boost.Python: it actually took me to while to get started with it. 
>Before you can actually do the very first tests you have to download a 
>~13MB package (compared to ~180KB for Pyrex) and compile the Boost.Python 
>runtime

That's why I never really got into Boost Python -- I simply didn't have 
time to go through all that, I needed to get something running for a 
specific project.

>As ODE has a rather small API, and the "official" API is C anyway, I'd 
>probably tend to stick to Pyrex. As this is an Open Source project we 
>should encourage other people to have a look at the code so that they 
>might contribute something. And I think by using Pyrex we make it much 
>easier to enable them to compile the module themselves. Pyrex is a small 
>tool and it's easy to install and try out.

Agreed.

>5) Trimesh support?
>
>I suppose, everyone wants to have that, right? ;-)
>But how do we pass the data?

I think the more basic question is "where does the data come from?".  My 
guess is that most of the time it will come from a 3D engine of some 
kind.  I don't like the overhead involved in converting arrays of vertices 
and triangle indices from C (the language the engine is written in) into 
Python, and then from Python back into C for ODE to use.  I think the more 
common case by far will be simply passing the data from the 3D engine to 
ODE directly.  Perhaps this can be done using Python's array module (not 
the one in Numeric, the other one).  Something to explore.

>6) double vs float. What type do we use?

Can't we just change the typedef for dReal, and rebuild with the 
appropriate version of ODE?

>7) What build system do we use?
>
>I would really recommend using the distutils as this is the standard way 
>for distributing Python extension modules. It has the advantage that 
>building the module works the same on every platform.

Agreed.

>8) Shall we try to implement an XODE import/export in Python?

I've been trying to find information about XODE, and have had no luck.  Am 
I just looking in the wrong places?

>PS: I'm yet from another corner of the world, I'm from Germany...

This is turning out to be a very international project!    :-)


--
   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] Status of the wrappers?

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

Timothy Stranex wrote:
> Please tell me your sourceforge.net usernames so I can add you to the
> PyODE project. 

My sf user name is "mbaas".

> Shall I'll remove the current code from CVS and import
> Matthias's code?

Maybe before getting our hands dirty in the code we should clarify those 
points I've posted in my other message (which will also give me the 
opportunity to translate some of the comments that are still in German 
in my files... ;-) ).

- Matthias -

[Pyode-user] Initial (re)design questions

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

Hi,

it's good to see that there's still interest to get to a decent ODE 
binding that's up to date and will be maintained.
I suppose there are a couple of questions and decisions that have to be 
made:

1) Which tool to use for creating the wrappers?

I think the most common tools are Boost.Python, SWIG, Pyrex and ctypes. 
It seems you've already agreed on Pyrex. Currently, I'm using 
Boost.Python for another project, so I also have a little experience 
here as well (by the way, that other project might eventually turn into 
the second version of cgkit, my other Open Source project at 
cgkit.sf.net. I even have plans to integrate ODE in that project at some 
time, however not as 1:1 binding but as an internal dynamics system, so 
it's not really a replacement for PyODE).
I have only very little experience with SWIG. But when I tested it 
(which was already quite a while ago), it didn't appear to be that well 
suited to wrap C++ code. I'm aware that there have been new versions 
since then so the situation might be better now.
But at least I can comment a bit on Pyrex vs Boost.Python. When using 
Pyrex you have to write your wrapper code in a "special language" 
(*.pyx) which is compiled by the Pyrex compiler into C source code. Then 
you compile this C source code with your C compiler and you get your 
Python module. This "special language" closely follows the Python syntax 
and adds some more constructs that allow to declare C variables or call 
C functions. So you can say the Pyrex language is just Python spiced up 
with C. That's why it's so easy to learn, you already know most of the 
syntax. Programming in Pyrex feels very "Pythonic" and you can freely 
mix Python code and C calls (sometimes without noticing), Pyrex will 
take care of reference counts and type conversions between C and Python 
types. The major drawback with the current version of Python is in my 
opinion the lack of a tool that processes header files. Because you can 
call C functions, Pyrex has to know an "approximate" signature of the 
function so that it can do proper type conversions. And that's the 
tedious part because you still have to do that manually. Of course, if 
we build on my binding we already have a great deal of the declarations. 
But if there are going to be interface changes in ODE we have to go 
through the declarations and adapt them to reflect the changes. This is 
not automated! Another disadvantage of Pyrex is that it has no special 
support for C++ yet. If you want to wrap classes, you first have to 
write a C wrapper file.
Now to Boost.Python: it actually took me to while to get started with 
it. Before you can actually do the very first tests you have to download 
a ~13MB package (compared to ~180KB for Pyrex) and compile the 
Boost.Python runtime (Pyrex is implemented in pure Python and uses the 
distutils). But once you've everything set up you can really do spiffy 
things, especially when you want to wrap C++ code. The first thing, that 
I found remarkable is that it doesn't need a special compiler that 
translates interface files or whatever. Everything you need is your C++ 
compiler and you just define the interfaces in "pure" C++ and directly 
compile that code into a Python module. From my experience, the learning 
curve is much steeper than for Pyrex. It took me a while to get those 
call policies right and understand some of the compile errors. But the 
more I use Boost.Python, the more I'm in awe of what you can do with it, 
or rather, what it does for you! Once you've defined your wrapper 
classes Boost.Python takes care of converting the types between C++ and 
Python and of course, you don't have to deal with reference counts and 
that low level stuff from the pure Python/C API. The manual declaration 
of the ODE headers is not necessary here, because you simply include the 
original headers right away.
Personally, I like both tools and I think they both have their 
advantages and disadvantages and it depends on the project which tool is 
better suited.
As ODE has a rather small API, and the "official" API is C anyway, I'd 
probably tend to stick to Pyrex. As this is an Open Source project we 
should encourage other people to have a look at the code so that they 
might contribute something. And I think by using Pyrex we make it much 
easier to enable them to compile the module themselves. Pyrex is a small 
tool and it's easy to install and try out.
But I also want to mention one open issue I have with Pyrex in my 
binding. For the collision callback mechanism it's necessary to pass C 
pointers (geoms) back to Python which means we have to be able to map a 
C pointer to its corresponding Python object. This is *not* done 
automatically in Pyrex as it is done in Boost.Python. That's why I have 
a lookup table called "_geom_c2py_lut" in the module. This is just a 
dictionary that maps C pointers to Python objects. The problem now is, 
that Pyrex didn't support weak references at the time I was writing the 
module. As a result, I wasn't able to remove entries from this lookup 
table when the corresponding object was destroyed. I've reported this to 
the author of Pyrex but I'm not sure if support for weak references has 
really been added in the meantime. However, I didn't find that problem 
really restricting for my purposes because when I did a new simulation I 
was usually restarting the program anyway, and even if I wouldn't I 
could still delete the entries in the dictionary manually as you have 
access to it from Python. But I wanted to bring it up anyway, because 
this is really a flaw in my binding.

Well, sorry, this was a lot of text for just one point, I try to be more 
concise with the other ones:

2) Should we wrap the C functions or the C++ classes?

Here's my opinion: I'd go for the C functions because they belong to the 
official and *documented* API.

3) How do we map the ODE API to Python?

Well, you see my preference if you look at my binding... ;)
I've put everything in classes and the functions became methods. Every 
joint type got its own class (instead of just *one* joint class). The 
same holds for geoms. In general, I'm always in favour of a "Pythonic" 
interface, even if that would mean that we would have to change the 
original interface slightly.
Oh, what's also nice is the ability to pass any Python 3-sequence where 
ODE actually expects a vector. This way, you can still choose to use the 
vector type of your choice (or just plain tuples).

4) How do we implement the collision callback mechanism?

In my version, I tried to do it just as it is done in C with the near 
callback that can now be implemented in Python.
However, there's the above mentioned problem with the lookup table that 
so far can only grow, but never gets smaller again.
What might also be desireable is the ability to use a "default" callback 
that's implemented in C so that no Python code has to be called during a 
simulation. If you have a lot of objects this Python callback can 
actually slow down the simulation too much.

5) Trimesh support?

I suppose, everyone wants to have that, right? ;-)
But how do we pass the data?

6) double vs float. What type do we use?

I've always used doubles and really would like to continue doing so as I 
belief it can postpone numerical problems.
However, I don't know if trimesh support is possible with doubles. This 
was a problem in the beginning, wasn't it? This is actually what has 
always prevented me from trying it out.

7) What build system do we use?

I would really recommend using the distutils as this is the standard way 
for distributing Python extension modules. It has the advantage that 
building the module works the same on every platform.

8) Shall we try to implement an XODE import/export in Python?

This might raise the popularity of the Python version...

9) Which operating systems can we support directly?

Or in other words: What systems are you working on? I'm mainly on 
Windows XP and can occasionally do tests on Linux (SuSE 8.2).

10) ...what else?...


- Matthias -

PS: I'm yet from another corner of the world, I'm from Germany...

Re: [Pyode-user] Status of the wrappers?

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

On Tue, 2004-06-22 at 13:25, Bernie Roehl wrote:
> >So it is a blancing act, do we
> >shoehorn ODE to fit into the Boost model, or do it the clean and quick w=
ay=20
> >with Pyrex?
>=20
> I vote for clean and quick.  :-)

As do I.

Please tell me your sourceforge.net usernames so I can add you to the
PyODE project. Shall I'll remove the current code from CVS and import
Matthias's code?

> >Btw, is anybody in the San Francisco area?
>=20
> I'm in Waterloo, Ontario Canada (about an hour west of Toronto).

I'm in Durban, South Africa.

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

Re: [Pyode-user] Status of the wrappers?

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

Hello Bernie and Matthias,

Clean and quick with Pyrex sounds like a good plan, i wish you luck.  I won't be able to help with
any of the code for the next 2-3 months.  But in two months i am quitting my day job to make more
time for working on free software projects, and then i may have time to help.

I want to see the ODE wrappers done and done well.  So i am putting a $300 bounty on them.  This
bounty is not meant to make people fight, everyone should still work together as much as possible.
 I just know from my own experiences it can be hard to work on free software and pay the bills, so
this bounty is just meant to help out the developer a little bit.

Here's the conditions for the bounty:
  1. All the features of ODE are exposed in Python (within reason, not every little thing, but all
of the important stuff)
  2. The code is clean and easy to build (clean: i should have no problems in reading it) (easy to
build: can be built on all platforms)
  3. It is licensed under the GNU GPL or LGPL


Thoughts?
-brett


--- Bernie Roehl <br...@ec...> wrote:
> At 11:05 AM 6/21/2004 -0700, brett hartshorn wrote:
> >Wrapping a
> >wrapper is not ideal, but from the perspective where several python 
> >wrappers must be created and
> >maintained, it makes sense that they all use the same wrapping language.
> 
> Perhaps, though I think it depends on the circumstances.
> 
> For example, in the project I'm working on, I'm wrapping a C++ graphics 
> library using SWIG and
> wrapping ODE using Pyrex.  My reasoning is that the C++ graphics API is one 
> project, the
> ODE wrapper is another, and my main project simply imports modules from the 
> other two.
> 
> In fact, I initially just used Mattias' PyODE without even knowing that it 
> was written
> using Pyrex -- it was just a .pyd that I imported.  The fact that I am now 
> modifying some of the
> code in that wrapper doesn't really change anything --  the main project 
> doesn't care where the .pyd
> files came from or what tools were used to create them.
> 
> That means we can use the right tool for the job in each case.  Since ODE 
> is written in C, it makes
> sense to use Pyrex.  Since the graphics library is written in C++, it makes 
> sense to use SWIG.
> For other things, it makes sense to use Boost.  I could easily see a Python 
> application that
> imports modules that were created using all three tools, and the 
> application developer doesn't need
> to know.
> 
> >So it is a blancing act, do we
> >shoehorn ODE to fit into the Boost model, or do it the clean and quick way 
> >with Pyrex?
> 
> I vote for clean and quick.  :-)
> 
> >Btw, is anybody in the San Francisco area?
> 
> I'm in Waterloo, Ontario Canada (about an hour west of Toronto).
> 
> 
> --
>    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 
> 
> 
> 
> -------------------------------------------------------
> This SF.Net email sponsored by Black Hat Briefings & Training.
> Attend Black Hat Briefings & Training, Las Vegas July 24-29 - 
> digital self defense, top technical experts, no vendor pitches, 
> unmatched networking opportunities. Visit www.blackhat.com
> _______________________________________________
> Pyode-user mailing list
> Pyo...@li...
> https://lists.sourceforge.net/lists/listinfo/pyode-user
> 



		
__________________________________
Do you Yahoo!?
Yahoo! Mail is new and improved - Check it out!
http://promotions.yahoo.com/new_mail

Re: [Pyode-user] Status of the wrappers?

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

At 11:05 AM 6/21/2004 -0700, brett hartshorn wrote:
>Wrapping a
>wrapper is not ideal, but from the perspective where several python 
>wrappers must be created and
>maintained, it makes sense that they all use the same wrapping language.

Perhaps, though I think it depends on the circumstances.

For example, in the project I'm working on, I'm wrapping a C++ graphics 
library using SWIG and
wrapping ODE using Pyrex.  My reasoning is that the C++ graphics API is one 
project, the
ODE wrapper is another, and my main project simply imports modules from the 
other two.

In fact, I initially just used Mattias' PyODE without even knowing that it 
was written
using Pyrex -- it was just a .pyd that I imported.  The fact that I am now 
modifying some of the
code in that wrapper doesn't really change anything --  the main project 
doesn't care where the .pyd
files came from or what tools were used to create them.

That means we can use the right tool for the job in each case.  Since ODE 
is written in C, it makes
sense to use Pyrex.  Since the graphics library is written in C++, it makes 
sense to use SWIG.
For other things, it makes sense to use Boost.  I could easily see a Python 
application that
imports modules that were created using all three tools, and the 
application developer doesn't need
to know.

>So it is a blancing act, do we
>shoehorn ODE to fit into the Boost model, or do it the clean and quick way 
>with Pyrex?

I vote for clean and quick.  :-)

>Btw, is anybody in the San Francisco area?

I'm in Waterloo, Ontario Canada (about an hour west of Toronto).


--
   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] Status of the wrappers?

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

Hello Matthias and Bernie,

Unfortunately, i have been very busy with other work in the past couple months, and i have not yet
had time to finish my version of the ODE wrapper.  I still plan to come back to it, but this may
not be for a coule months.  In the mean time, if someone beats me to the punch using another
method, i'll gladly be using their binding when it comes out, and fix bugs in it when i have time.

If not, then i plan to move forward using Boost Python to wrap the c++ wrappers.  Wrapping a
wrapper is not ideal, but from the perspective where several python wrappers must be created and
maintained, it makes sense that they all use the same wrapping language.  I am also maintaining
the PyOSG wrappers, and soon i'll be doing the Cassowary wrappers.  I have looked at the Pyrex
documentation, and it is impressive and has some real elegance.  So it is a blancing act, do we
shoehorn ODE to fit into the Boost model, or do it the clean and quick way with Pyrex?  

Thoughts?
Btw, is anybody in the San Francisco area?

-brett

--- Bernie Roehl <br...@ec...> wrote:
> For what it's worth, I'm using the version at ira.uka.de and I find it 
> works well.  I've modified it slightly to expose a couple of additional 
> methods that I needed access to (setCategoryBits() and setCollideBits()), 
> and found that it was quite easy to do even though I'd never used Pyrex 
> before.  I'm also building PyODE with the most recent version of ODE (0.5).
> 
> The main reasons I chose the ira.uka.de implementation were the fact that 
> it had some nice tutorials that made it very easy to get up to speed on 
> using it, and it provided a way to implement the near_callback() in Python 
> (which I needed for my application).  I'm not clear as to whether the other 
> implementations provide this capability or not.
> 
> Certainly the fact that ODE is written in C (as opposed to C++) makes it a 
> very natural fit for the Pyrex-based approach.  The C++ interface to ODE is 
> essentially just a wrapper, and the idea of wrapping a wrapper is 
> unappealing to me.  With the Pyrex approach, you get an object-oriented 
> interface (which I consider essential) while still using a single layer of 
> wrapper.
> 
> In any case...  perhaps a good way to kick-start this process is to 
> identify what specific functionality it is that we need that is not 
> currently available (e.g. trimesh support, which is high on my list) and 
> discuss how to add it.  If turns out that converging on a single 
> implementation is impractical for whatever reason, it would at least be 
> nice to provide some interchangeability between the three.
> 
> And yes, I'd be willing to put some time into actually writing code (as 
> opposed to just commenting on work that other people have already done or 
> will be doing).
> 
> Looking forward to hearing everyone's thoughts, and the status off all 
> three implementations...
> 
> 
> 
> 
> At 11:46 PM 6/20/2004 +0200, Matthias Baas wrote:
> >Hi,
> >
> >I would like to ask about the status of both ODE wrappers, Timothy's
> >original wrappers and Brett's rewrite. Are there any plans to continue
> >any of them? I suppose you know that I also have a wrapper
> >(http://i31www.ira.uka.de/~baas/pyode/), but it's also quite out of date
> >and, probably as everybody else here, I don't have much time to maintain
> >it. I've recently got a couple of mails from people asking about when
> >there will be a new version including trimesh support.
> >That's why I was reminded that it would really be much better if there
> >was only *one* binding with several people behind it.
> >So is there still any interest in creating a "unified" ODE binding?
> >
> >Cheers,
> >
> >- Matthias -
> >
> >
> >
> >-------------------------------------------------------
> >This SF.Net email is sponsored by The 2004 JavaOne(SM) Conference
> >Learn from the experts at JavaOne(SM), Sun's Worldwide Java Developer
> >Conference, June 28 - July 1 at the Moscone Center in San Francisco, CA
> >REGISTER AND SAVE! http://java.sun.com/javaone/sf Priority Code NWMGYKND
> >_______________________________________________
> >Pyode-user mailing list
> >Pyo...@li...
> >https://lists.sourceforge.net/lists/listinfo/pyode-user
> 
> --
>    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 
> 
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by The 2004 JavaOne(SM) Conference
> Learn from the experts at JavaOne(SM), Sun's Worldwide Java Developer
> Conference, June 28 - July 1 at the Moscone Center in San Francisco, CA
> REGISTER AND SAVE! http://java.sun.com/javaone/sf Priority Code NWMGYKND
> _______________________________________________
> 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] Status of the wrappers?

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

For what it's worth, I'm using the version at ira.uka.de and I find it 
works well.  I've modified it slightly to expose a couple of additional 
methods that I needed access to (setCategoryBits() and setCollideBits()), 
and found that it was quite easy to do even though I'd never used Pyrex 
before.  I'm also building PyODE with the most recent version of ODE (0.5).

The main reasons I chose the ira.uka.de implementation were the fact that 
it had some nice tutorials that made it very easy to get up to speed on 
using it, and it provided a way to implement the near_callback() in Python 
(which I needed for my application).  I'm not clear as to whether the other 
implementations provide this capability or not.

Certainly the fact that ODE is written in C (as opposed to C++) makes it a 
very natural fit for the Pyrex-based approach.  The C++ interface to ODE is 
essentially just a wrapper, and the idea of wrapping a wrapper is 
unappealing to me.  With the Pyrex approach, you get an object-oriented 
interface (which I consider essential) while still using a single layer of 
wrapper.

In any case...  perhaps a good way to kick-start this process is to 
identify what specific functionality it is that we need that is not 
currently available (e.g. trimesh support, which is high on my list) and 
discuss how to add it.  If turns out that converging on a single 
implementation is impractical for whatever reason, it would at least be 
nice to provide some interchangeability between the three.

And yes, I'd be willing to put some time into actually writing code (as 
opposed to just commenting on work that other people have already done or 
will be doing).

Looking forward to hearing everyone's thoughts, and the status off all 
three implementations...




At 11:46 PM 6/20/2004 +0200, Matthias Baas wrote:
>Hi,
>
>I would like to ask about the status of both ODE wrappers, Timothy's
>original wrappers and Brett's rewrite. Are there any plans to continue
>any of them? I suppose you know that I also have a wrapper
>(http://i31www.ira.uka.de/~baas/pyode/), but it's also quite out of date
>and, probably as everybody else here, I don't have much time to maintain
>it. I've recently got a couple of mails from people asking about when
>there will be a new version including trimesh support.
>That's why I was reminded that it would really be much better if there
>was only *one* binding with several people behind it.
>So is there still any interest in creating a "unified" ODE binding?
>
>Cheers,
>
>- Matthias -
>
>
>
>-------------------------------------------------------
>This SF.Net email is sponsored by The 2004 JavaOne(SM) Conference
>Learn from the experts at JavaOne(SM), Sun's Worldwide Java Developer
>Conference, June 28 - July 1 at the Moscone Center in San Francisco, CA
>REGISTER AND SAVE! http://java.sun.com/javaone/sf Priority Code NWMGYKND
>_______________________________________________
>Pyode-user mailing list
>Pyo...@li...
>https://lists.sourceforge.net/lists/listinfo/pyode-user

--
   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] Status of the wrappers?

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

Hi,

I would like to ask about the status of both ODE wrappers, Timothy's
original wrappers and Brett's rewrite. Are there any plans to continue
any of them? I suppose you know that I also have a wrapper
(http://i31www.ira.uka.de/~baas/pyode/), but it's also quite out of date
and, probably as everybody else here, I don't have much time to maintain
it. I've recently got a couple of mails from people asking about when
there will be a new version including trimesh support.
That's why I was reminded that it would really be much better if there
was only *one* binding with several people behind it.
So is there still any interest in creating a "unified" ODE binding?

Cheers,

- Matthias -