Re: [Pyode-user] The Pyrex version is ready to be checked in

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

Bernie Roehl wrote:
> I would propose that we proceed in roughly the order given above.  I 
> know Timothy is working on
> an XODE reader, and I have an interest in adding trimesh support.  
> Perhaps Matthias would be able
> to look at AMotor and CylinderClass?  Once all that is done, we can all 
> participate in the review phase,
> and then look at who would like to help with the cleanup and packaging.

Sounds good to me. I'll see if I can add the AMotor and Cylinder (if I 
find some info about it) somewhen this week.

> The only item that I didn't put into the list above is:
> - Make the objects pickleable?

Well, I also don't know if this is really necessary. The idea occured 
when we were talking about the trimesh geom. I thought maybe even when 
the mesh creation code is written in Python and creating a mesh is 
rather slow, then maybe it would be useful to be able to dump the final 
mesh to disk using the pickle module and then just load that again later 
on. Another thing might be to be able to dump the current state of a 
simulation to disk and continue or redo the simulation later.
But it's really low priority and I also think we can wait until someone 
really needs it.

By the way, I was reading the documentation of the trimesh class. How 
about doing it analogous to ODE? There could be a TriMeshData class that 
has the responsibility to provide the actual mesh data and a GeomTriMesh 
class that represents the geom object and that takes a TriMeshData as input.
Using Python's array module sounds like a good idea to me. So the 
TriMeshData could be provided with the vertices and faces stored in an 
array object. If we keep a reference to those arrays we can be sure that 
the memory won't get deleted and we can use the raw pointer into the 
array. If the floating point type in the array doesn't match the ODE 
type then the TriMeshData has to convert the array. I'd also suggest to 
have convenience methods to build the mesh from ordinary Python lists 
containing the vertices and faces as ordinary Python tuples or other 
3-sequences. The TriMeshData would then just create the array objects 
internally and proceed in the same way as above.
With this scheme you could also pass a pointer to the very same data 
that is used by a rendering engine if this is desired. All you have to 
do is to write a class that has the same interface than the array class 
and that just returns the pointer when the buffer_info() method is 
returned. Of course, then you have to make sure that the data remains 
valid during the simulation.
Any thoughts?

- Matthias -