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