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 -