pyode-user — PyODE User Discussions

Re: [Pyode-user] XODE & GeomTransforms

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

Timothy Stranex wrote:
>>By the way, Timothy, I noticed that since the last update to the XODE 
>>code the unittest didn't crash anymore. So what has been the reason for 
>>the crash?
> 
> I have no idea what caused the crashes. Actually, I thought you had
> fixed it...

I didn't, at least not consciously... :-)

So as we don't have an example that crashes anymore, I'll ignore it 
until it bugs us again...

- Matthias -

Re: [Pyode-user] TriMesh stuff

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

Timothy Stranex wrote:
> On Thu, 2004-07-29 at 03:15, brett hartshorn wrote:
> 
>>setup.py says:
>>ERROR: [Errno 2] No such file or directory: '../ode/config/user-settings'
>>Aborting!
> 
> You either need to extract the ODE sources to a directory 'ode' in the
> same directory that contains 'pyode'. Alternatively, you can create a
> symlink to the ODE sources.

Either that, or modify the variable ODE_BASE in the setup script.

I have updated the file INSTALL that mentions the distutils now.

> I think we should add an option to setup.py to let users tell it where
> the ODE sources are kept 

Agreed. However, I don't know what the "official" way is to introduce 
new options to the setup script. There's the possibility to have a 
setup.cfg file where you can keep default parameters that can also 
modified on the command line, but I haven't seen anything that lets me 
define new parameters.

By the way, what's the preferred location for the ODE include files and 
libs on Linux? Should the script use something like /usr/include and 
/usr/lib as default paths? Or do you actually keep ODE in a separate 
directory?

And another thing, I just realized that since Pyrex 0.9.3 we don't have 
to parse the ODE user-settings file anymore because it finally puts the 
typedef name into the generated C file. This means wherever "dReal" is 
used in the *.pyx file it will remain "dReal" in the C file and will not 
be replaced by "float" or "double". So we don't have to care anymore if 
ODE was compiled using single or double precision. We will automatically 
use the correct precision.
I'll commit the modified setup script later today. Or are there any 
objections (i.e. is there a reason why you can't upgrade to Pyrex 0.9.3)?

> or simply whether the user wants it to be compiled with double or float precision 

This decision is already made when ODE itself is compiled. There's no 
choice anymore for PyODE. But as I said above, with Pyrex 0.9.3 all this 
is obsolete anyway.

- Matthias -

Re: [Pyode-user] TriMesh stuff

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

On Thu, 2004-07-29 at 02:18, Chris Bainbridge wrote:
> 2) Is nobody else using linux? How=20
> are you guys compiling the Opcode library?

I'm using Gentoo Linux. I used the OPCODE sources that came in the ODE
distribution. I think they've been modified to work on Linux. In your
user-settings file, set OPCODE_DIRECTORY=3DOPCODE and it should compile.

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

Re: [Pyode-user] TriMesh stuff

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

On Thu, 2004-07-29 at 03:15, brett hartshorn wrote:
> setup.py says:
> ERROR: [Errno 2] No such file or directory: '../ode/config/user-settings'
> Aborting!

You either need to extract the ODE sources to a directory 'ode' in the
same directory that contains 'pyode'. Alternatively, you can create a
symlink to the ODE sources.

> I read the README, but it seem like generic install info.

I think we should add an option to setup.py to let users tell it where
the ODE sources are kept or simply whether the user wants it to be
compiled with double or float precision so it doesn't need to parse
user-settings at all.

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

Re: [Pyode-user] TriMesh stuff

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

I'm sure i missed this from a previous mail, but how do i build it the latest CVS?  I just checked
it out and tried 'make' and 'python setup.py install'

make says:
make: *** No targets specified and no makefile found.  Stop.

setup.py says:
ERROR: [Errno 2] No such file or directory: '../ode/config/user-settings'
Aborting!

I read the README, but it seem like generic install info.

Note: i'm using redhat9

thanks,
-brett

--- Chris Bainbridge <c.j...@ed...> wrote:

> Hi, I have a small query. My install of ode doesn't include the trimesh stuff, 
> because OPCODE in ODE doesn't seem to compile on linux at all. The older 
> 1.2.1 linux port appears to be incompatible with the 1.3 code bundled with 
> ODE. Pyode wraps the class anyway, so I get:
> 
> $ python
> Python 2.3.3 (#1, May 14 2004, 03:14:07)
> [GCC 3.3.2 20031218 (Gentoo Linux 3.3.2-r5, propolice-3.3-7)] on linux2
> Type "help", "copyright", "credits" or "license" for more information.
> >>> import ode
> Traceback (most recent call last):
>   File "<stdin>", line 1, in ?
> ImportError: /usr/lib/python2.3/site-packages/ode.so: undefined symbol: 
> dGeomTriMeshGetTriangle
> >>>
> 
> If I remove GeomTriMesh class from geoms.pyx there is no problem. So I guess 
> my question is 1) can the pyode script automagically detect whether this 
> class is available and wrap appropriately? 2) Is nobody else using linux? How 
> are you guys compiling the Opcode library?
> 
> Thanks,
> Chris
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by BEA Weblogic Workshop
> FREE Java Enterprise J2EE developer tools!
> Get your free copy of BEA WebLogic Workshop 8.1 today.
> http://ads.osdn.com/?ad_id=4721&alloc_id=10040&op=click
> _______________________________________________
> Pyode-user mailing list
> Pyo...@li...
> https://lists.sourceforge.net/lists/listinfo/pyode-user
> 



		
__________________________________
Do you Yahoo!?
Read only the mail you want - Yahoo! Mail SpamGuard.
http://promotions.yahoo.com/new_mail 

[Pyode-user] TriMesh stuff

[Chris B. <c.j...@ed...>]

Hi, I have a small query. My install of ode doesn't include the trimesh stuff, 
because OPCODE in ODE doesn't seem to compile on linux at all. The older 
1.2.1 linux port appears to be incompatible with the 1.3 code bundled with 
ODE. Pyode wraps the class anyway, so I get:

$ python
Python 2.3.3 (#1, May 14 2004, 03:14:07)
[GCC 3.3.2 20031218 (Gentoo Linux 3.3.2-r5, propolice-3.3-7)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import ode
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
ImportError: /usr/lib/python2.3/site-packages/ode.so: undefined symbol: 
dGeomTriMeshGetTriangle
>>>

If I remove GeomTriMesh class from geoms.pyx there is no problem. So I guess 
my question is 1) can the pyode script automagically detect whether this 
class is available and wrap appropriately? 2) Is nobody else using linux? How 
are you guys compiling the Opcode library?

Thanks,
Chris

[Pyode-user] XODE & GeomTransforms

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

Hi,

I've just checked in an updated version of the GeomTransform that checks 
the argument to setGeom() (the encapsulated geom must not be inserted 
into a space or associated with a body). Now I get a lot of failures 
when I run the XODE unittest because the encapsulated geom was already 
inserted into a space.

By the way, Timothy, I noticed that since the last update to the XODE 
code the unittest didn't crash anymore. So what has been the reason for 
the crash?

- Matthias -

Re: [Pyode-user] Trimesh (was: Fwd: PyODE)

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

Timothy Stranex wrote:
> I think there is a problem with the dGeomTriMeshDataBuildSingle
> declaration. The ODE 0.5 manuals says:
> 
> dGeomTriMeshDataBuildSingle (TriMeshData,

Well, actually the manual says the function is called 
dGeomTriMeshDataBuild() which isn't defined in the header, so I had a 
glimpse in the ODE source and saw the "*Single" function. Unfortunately, 
I've missed the difference between Single and Single1 (now I just wonder 
why it did compile here....?).

By the way, has anybody tried out the trimesh stuff? For me, it only 
works on some meshes whereas sometimes it seems ODE is just ignoring 
about half of the triangles.
I have put a couple of meshes in XODE format online at 
http://i31www.ira.uka.de/~baas/xode/
The files only contain the geom definition and the corresponding mass 
structure. If I drop the sphere or the torus knot at a box, I get some 
penetrations that shouldn't occur (as if half of the geom wasn't there).
On the other hand, the bunny seems to be ok.

- Matthias -

[Pyode-user] Fwd: PyODE

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

Hello,

I think there is a problem with the dGeomTriMeshDataBuildSingle
declaration. The ODE 0.5 manuals says:

dGeomTriMeshDataBuildSingle (TriMeshData,
        // Vertices
        Bodies[BodyIndex].VertexPositions,
        3*sizeof(dReal), (int) numVertices,
        // Faces
        Bodies[BodyIndex].TriangleIndices,
        (int) NumTriangles, 3*sizeof(unsigned int),
        // Normals
        Bodies[BodyIndex].FaceNormals);

But collision_trimesh.h has the following definitions:

/*
 * Build TriMesh data with single pricision used in vertex data .
 */
void dGeomTriMeshDataBuildSingle(dTriMeshDataID g,
                                 const void* Vertices, int VertexStride, int VertexCount,
                                 const void* Indices, int IndexCount, int TriStride);
/* same again with a normals array (used as trimesh-trimesh optimization) */
void dGeomTriMeshDataBuildSingle1(dTriMeshDataID g,
                                  const void* Vertices, int VertexStride, int VertexCount,
                                  const void* Indices, int IndexCount, int TriStride,
                                  const void* Normals);

I've changed the declaration in declarations.pyx and the call in trimeshdata.pyx to
dGeomTriMeshDataBuildSingle1 to allow it to build.

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

Re: [Pyode-user] XODE test crashes

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

Timothy Stranex wrote:
>>When I run the unit tests I get a crash at the end (after the tests 
>>succeeded). Doesn't this happen on Linux, too?
> 
> It does. While I was writing each unit test, it would sometimes crash
> and sometimes not. When it did crash, it always crashed at the end of
> the tests so I guess its a deallocation problem.

I tracked it down to the Space object. The crash appears in 
dSpaceDestroy() which is called in the __dealloc__() method. But I have 
absolutely no idea why it does so... it seems the space is already 
deallocated when the destructor is called, but why?

By the way, in the ODE manual I saw for the first time that spaces have 
a cleanup flag which is set by default and that this means they destroy 
the geoms contained in them. This could also lead to geoms being 
deallocated twice. So I called dSpaceSetCleanup(self.sid, 0) in the 
constructor of the Space, but this didn't change anything to our crash.

I also find it weird that it only happens in the unit test, I've found 
no other example that crashed....?

- Matthias -

[Pyode-user] XODE test crashes

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

Hi,

I was just trying out the new XODE reader (cheers to Timothy! :)
When I run the unit tests I get a crash at the end (after the tests 
succeeded). Doesn't this happen on Linux, too? I don't think it's the 
XODE reader as it is implemented in pure Python. I guess it's me who's 
to blame because I haven't checked for errors in all cases. I'll see if 
I can also create unit tests for the classes in the ode module to find 
out where the crash occurs.

So to anyone who already knows cases in which the ode module crashes: 
please post them here so I can add appropriate error checks.

- Matthias -

Re: [Pyode-user] AMotor in cvs

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

Timothy Stranex wrote:
> Good idea. I've created a pyode-commits mailing list and directed the
> CVS repository to send an e-mail to it for every commit. I'm not sure if
> it's working but we'll see after the next commit...

It works! :) I've just commited a new version of mass.pyx that has 
updated doc strings. Now you can actually see the method arguments in 
the epydoc output.

- Matthias -

Re: [Pyode-user] AMotor in cvs

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

On Sun, 2004-07-04 at 23:17, Matthias Baas wrote:
> By the way, could you set up a mailing list that'll be used by cvs to=20
> post messages whenever there was a commit? I've seen that on other=20
> projects and I think it's the easiest way for someone to be informed=20
> about code changes. I don't know where this is set up on the SF admin=20
> page, so if you don't know either I can ask an admin of another project=20
> which has this feature.

Good idea. I've created a pyode-commits mailing list and directed the
CVS repository to send an e-mail to it for every commit. I'm not sure if
it's working but we'll see after the next commit...

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

Re: [Pyode-user] AMotor in cvs

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

Timothy Stranex wrote:
> I've been working on the XODE module and testing it with the examples.
> I'll commit it when it does everything tutorial2.py needs.

Sounds good!

By the way, could you set up a mailing list that'll be used by cvs to 
post messages whenever there was a commit? I've seen that on other 
projects and I think it's the easiest way for someone to be informed 
about code changes. I don't know where this is set up on the SF admin 
page, so if you don't know either I can ask an admin of another project 
which has this feature.

- Matthias -

Re: [Pyode-user] AMotor in cvs

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

On Sat, 2004-07-03 at 19:09, Matthias Baas wrote:
> I've just commited the changes that add the AMotor class to the binding.=20
>   The cylinder class is not yet included in the official ODE API. It's=20
> still in the contrib directory, so I won't add it to the binding right no=
w.

Cool.

> By the way, has everyone been able to compile the module and run the=20
> examples?

I just had to make a symlink to my ODE sources and then it compiled
fine. The examples all work too.

I've been working on the XODE module and testing it with the examples.
I'll commit it when it does everything tutorial2.py needs.

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

[Pyode-user] AMotor in cvs

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

Hi,

I've just commited the changes that add the AMotor class to the binding. 
  The cylinder class is not yet included in the official ODE API. It's 
still in the contrib directory, so I won't add it to the binding right now.

Is there any news about XODE and the trimesh support?

By the way, has everyone been able to compile the module and run the 
examples?

- Matthias -

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 -

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

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

I've taken Matthias' list and organized it into related activities...

New Features:
- Add AMotor class
- Add Cylinder class (not the capped one)
- Trimesh support
- XODE reader

Review:
- Check the ODE API for new (or so far unsupported) functions and add them 
to the respective class
- Review the design and improve whatever has to be improved (like the 
global lookup dictionary).

Cleanup:
- Do more error checking.
- Add some __str__() methods that output useful data
- Make the documentation (doc strings) complete
- Add a proper file header on all the .pyx files

Packaging:
- Update all the files that are necessary for a proper release (readme, 
license, changelog, ...)
- Write more examples, demos, tutorials. :)

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.

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

I'm not sure if this is necessary or not, and would be inclined to not 
bother with it unless someone
asks for it.

How does all that sound?


--
   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] The Pyrex version is ready to be checked in

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

Timothy Stranex wrote:
> I agree with Bernie: move the existing code to "pyode_previous" and put
> the new code into "pyode".

ok, done.
I just noticed a slight disadvantage in reusing the pyode directory. 
There's the subdirectory "include" which isn't necessary anymore, 
however as cvs doesn't allow to remove directories it will remain 
there... oh, well.

The text files README, INSTALL, etc. are still the old ones, they have 
to be updated eventually.

Here's an incomplete list of things that still have to be done:

- Check the ODE API for new (or so far unsupported) functions and add 
them to the respective class

- Trimesh support

- Add some __str__() methods that output useful data

- Make the documentation (doc strings) complete. By the way, I noticed 
that the epydoc markup @param can't be used because epydoc doesn't see 
the argument names. Is there a way to get around this?

- Add AMotor class

- Add CylinderClass (not the capped one). Is that already officially 
available? There's no section in the docs, but it's mentioned as a geom 
type.

- Do more error checking. Currently, it's still possible to crash the 
interpreter if you do "wrong" calls.

- Review the design and improve whatever has to be improved (like the 
global lookup dictionary).

- Make the objects pickleable?

- XODE reader

- Update all the files that are necessary for a proper release (readme, 
license, changelog, ...)

- Add a proper file header on all the .pyx files

- Write more examples, demos, tutorials. :)

But at least the current version can be compiled and is fully 
functional. I hope it'll also compile on Linux. To compile you can just 
call "setup.py build" (by the way, as I've checked in the stuff on 
Windows the setup script won't have the executable flag set.... darn, 
and I believe now it's too late to change that in the repository. Oh, 
and you have to set the proper path to ODE in the setup script (the 
variable ODE_BASE)...)

- Matthias -

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

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

Cool, looks like things are moving fast!  As far as the license is concerned, i'd recommend doing
it the ODE way (GPL and BSD dual license).
Thanks Matthias and everbody,
-brett



		
__________________________________
Do you Yahoo!?
Yahoo! Mail - 50x more storage than other providers!
http://promotions.yahoo.com/new_mail

Re: [Pyode-user] XODE

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

Timothy Stranex wrote:
> 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.

Does the class already create ODE objects when I call parseString() or 
parseFile()? How do I get the contents of the file? There is the 
getPartByName() method but what are the names I have to pass? How do I 
find out how many and what objects were specified in the XODE file?
Can you give a short example how the class is typically used?

- Matthias -

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

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

I'm in a rush today (spending time with family), so this will be brief...

First off -- great work, Matthias!  It sounds like things will be much 
easier to maintain now.

Yes, I had originally started adding the setData() routines before I 
noticed how you had done things.  I went back and removed the routines I'd 
added, but I must have missed one.  Thanks for catching it!   :-)

I like your proposed organization of the repository.  I would suggest 
moving the code that's there now into something like "pyode_previous" and 
making the Pyrex version the "pyode" one (with perhaps a readme.txt file 
explaining things).

As to licensing, I think it makes sense to use the exact same licensing as 
ODE itself.  Being more restrictive would just make it less likely for 
people to use PyODE, and being less restrictive is pointless (since PyODE 
won't work without ODE).

Anyway, I'm off... will try to check my email later...


At 04:32 PM 6/27/2004 +0200, Matthias Baas wrote:
>[...]
>
>Now how should we organize the cvs repository? Currently I have a main 
>directory where the setup script is and a subdirectory "src" where the 
>.pyx files are. My tutorial source files (which serve as a "regression 
>test" right now) are in a subdirectory "examples". So shall I commit 
>everything into a new top level directory "pyode2" or would you rather 
>like to reuse the current pyode directory?
>
>By the way, what license are we using? GPL? BSD? Or both (as ODE is doing)?
>
>- Matthias -

--
   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] The Pyrex version is ready to be checked in

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

Hi,

I've brought my files into a state that makes them ready to be checked 
in. Here's what I did:

- The main Pyrex file "ode.pyx" is split into into several parts:

   body.pyx - Contains the Body class

   contact.pyx - Contains the Contact class

   declarations.pyx - Contains all external declarations (mainly the 
stuff from ode.h. Hopefully, there will be a time some day when this 
file can be generated automatically).

   geoms.pyx - Contains all geom classes

   joints.pyx - Contains all joint classes and the JointGroup class

   mass.pyx - Contains the Mass class

   ode.pyx - Main file. All the other files are included here. All 
constants and functions are still in this file

   space.pyx - Contains the Space class and the C part of the collision 
callback

   world.pyx - Contains the World class

- The German comments are removed or translated (I hope I got them all)

- The geoms and joints have been restructured so that geoms and joints 
have a common base class now (this wasn't possible in earlier versions 
of Pyrex). The base classes are GeomObject and Joint.

- I've added Bernie's modifications (by the way, you have added 
setData()/getData() to the sphere geom. In Python the 
setData()/getData() aren't necessary as you can add arbitrary data as 
new attributes to the objects. So instead of geom.setData(spam) you can 
do geom.spam = spam on any geom object)

- The World object now contains the quickStep stuff.

- The setup script determines ODE's precision setting automatically by 
reading the user-settings file and create a file "_precision.pyx" that 
contains the declaration of "dReal" (which has to be either float or 
double). This generated file is included in declarations.pyx.

- Sporadically I added some doc strings or error checks.

Everything compiles fine here on Windows using the latest binaries from 
the ODE site (I didn't bother to recompile ODE myself). I've tried both, 
SINGLE and DOUBLE precision and both works fine. So I'd say the files 
can be checked in and then we can all work on the same repository.

Now how should we organize the cvs repository? Currently I have a main 
directory where the setup script is and a subdirectory "src" where the 
.pyx files are. My tutorial source files (which serve as a "regression 
test" right now) are in a subdirectory "examples". So shall I commit 
everything into a new top level directory "pyode2" or would you rather 
like to reuse the current pyode directory?

By the way, what license are we using? GPL? BSD? Or both (as ODE is doing)?

- Matthias -

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

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

Last message for this morning... I promise!   :-)

I notice from the documentation that array objects have a buffer_info() 
method that returns the address and size of the array.

This of course makes things very easy.


At 12:01 PM 6/26/2004 -0400, Bernie Roehl wrote:
>The only complication would be passing the array object through Pyrex and 
>making it accessible
>as a regular C array.  Matthias -- any thoughts on this?

--
   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: Trimesh support (was: [Pyode-user] Initial (re)design questions)

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

Matthias raises some good points.

Coming from a background of doing real-time 3D rendering in memory- and 
processor-limited environments,
I instinctively cringe at the thought of having the vertex and triangle 
data stored twice in two separate files.

However, as Matthias points out, there are advantages to doing so.  The 
most compelling is that the two
meshes may not be identical.

Still, I don't think we want to *require* users to use XODE whenever they 
have trimeshes, so I would want
us to support both XODE loading and direct passing of vertex/triangle data.

Thinking about this some more...

It occurs to me that the XODE implementor (hi, Timothy!) is faced with the 
double-to-float conversion issue
that we talked about d previously.  Since Python floats are in fact 
doubles, the XODE parser is effectively always
in double-precision mode.  We will need some way for the XODE parser to 
build an array of floats out of these
double-precision numbers in order to pass it to (a single-precision) PyODE.

In other words, two scenarios...

1) Someone has a graphics engine that provides vertices as strided arrays 
of single-precision numbers

     1a) they're using single-precision PyODE -- easy case

     1b) they're using double-precision PyODE -- they have to write some 
extra C code

2) Somone is writing a Python application (e.g. Timothy's XODE parser)

    2a) they're using double-precision PyODE -- easy case

    2b) they're using single-precision PyODE -- they need to do... something?

This is what brings me back to the "array" module in Python.  It already 
distinguishes between arrays of
floats (typecode 'f') and arrays of doubles (typecode 'd').

If someone is developing an application entirely in Python, or with the 
XODE loader, then they simply
build an array object using the appropriate typecode ('f' if they're using 
the single-precision PyODE or
'd' if they're using the double-precision PyODE).  If they're getting data 
from an engine, they will have
to copy the data into an array object (again using the appropriate typecode).

The use of array objects means that the single/double issue is extremely 
localized (just the typecode
of the array is different).  It also means that Python will handle the 
memory management of the array
for us, which is nice.  It also means that the vertex and triangle data is 
directly accessible from Python,
which may be handy in some cases.  And while it's true that we have to make 
a copy of the data that
the engine provides us, the fact is that we would probably have to do that 
anyway since most modern
engines use hardware vertex buffers that are not (efficiently) accessible 
from the application.

To summarize....

* XODE (or any Python application) builds a Python array object to 
represent the vertex data

* people interfacing to an engine do the same thing (probably entirely in 
Python, if the engine's Python
   interface already lets them read vertex data)

The only complication would be passing the array object through Pyrex and 
making it accessible
as a regular C array.  Matthias -- any thoughts on this?

I realize that I'm sort of rambling this morning, and waffling back and 
forth on how to do this.  I should probably
have read all the messages on the PyODE list first, then replied to them 
all at once in a more coherent way.

Oh well.  :-)




At 08:55 PM 6/25/2004 +0200, Matthias Baas wrote:
>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 -
>
>
>
>-------------------------------------------------------
>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

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