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