PythonOgre, OgreODE, failure to create TriangleMeshGeometry

I'm thinking this is a wrappings issue. Maybe I'm passing the wrong arguments or maybe this function was never closely looked at when it was wrapped.

Here is my Python call:

trimesh1 = OgreOde.TriangleMeshGeometry(wall1Points, len(wall1Points), indices1, len(indices1), self._world, self._space)


Here is the C++ prototype:

TriangleMeshGeometry(const Ogre::Vector3* vertices,
unsigned int vertex_count,
const unsigned int* indices,
unsigned int index_count,
World *world,
Space* space = 0);


Here is the exception message passed to the command-line:

Traceback (most recent call last):
File "SnakeMotionModel2.py", line 214, in <module>
application.go()
File "C:\Python25\lib\site-packages\ogre\renderer\OGRE\sf_OIS.py", line 66, in go
if not self._setUp():
File "C:\Python25\lib\site-packages\ogre\renderer\OGRE\sf_OIS.py", line 107, in _setUp
self._createScene()
File "SnakeMotionModel2.py", line 182, in _createScene
self.walls = corridor.Corridor(self._world)
File "C:\Documents and Settings\Jacob\Desktop\OpaqueCode\corridor.py", line 43, in __init__
self.setupMyWorld(pnts1, pnts2)
File "C:\Documents and Settings\Jacob\Desktop\OpaqueCode\corridor.py", line 153, in setupMyWorld
trimesh1 = OgreOde.TriangleMeshGeometry(wall1Points, len(wall1Points), indices1, len(indices1), self._world, self._space)
Boost.Python.ArgumentError: Python argument types in
TriangleMeshGeometry.__init__(TriangleMeshGeometry, list, int, list, int, World, HashTableSpace)
did not match C++ signature:
__init__(struct _object *, class Ogre::Vector3 const * vertices, unsigned int vertex_count, int const * indices, unsigned int index_count, class OgreOde::World * world)
__init__(struct _object *, class Ogre::Vector3 const * vertices, unsigned int vertex_count, int const * indices, unsigned int index_count, class OgreOde::World * world, class OgreOde::Space * space=None)


Clearly, the problem is passing the lists and translating to const pointers. Particularly Ogre::Vector3 const *vertices and int const *indices. Both of these I passed as lists of the respective element but to no avail.

Is there a workaround to this?

wildmage

edit 1:
The error message had an irrelevant string argument that I added during my experimentation. I removed it since it's not relevant and confusing to the issue at hand.

It's a 'missing' in the wrapper -- unfortunately there isn't any smart way for the wrapper generator to know that the Ogre::Vector3* is intended to point to a list of Vector3's so it wraps assuming a single entity.

I hand wrapped something similar with getBoneVertices and will fix the TiangleMeshGeometry you've found, as well as the ComplexGeometry case..

Could you please raise a bug report on sourceforge so I have something to track this against..

thanks
Andy

I submitted the bug.

Your last binary distro saved me days of headaches. I had actually been struggling for 3 days to get an OgreODE python wrapping built, compiled, generated with no imminent success. The release a week ago evaporated all my problems.

I'm really not relishing doing a build again to include the fix and am hoping that a new binary release is around the corner

By the way, if you're curious, I am actually using python-ogre for a scientific simulation. I am porting my robotics simulator from ODE over to pure Python since a lot of my code is embedded python. I thought it would be a lot easier to have a pure python solution since I keep getting weird memory problems with embedded python.

Plus a superior visualization system (Ogre) is not too bad either and definitely a step up from ODE's drawstuff renderer

wildmage

I'm planning the next patch release in a week (next weekend) which will include the OgreODE fixes.........

Andy

Is the new binary release coming soon? I remember you said in the previous message that it was due this last weekend. Circumstances push it back?

Jacob

Got delayed a week as the OgreOde (go figure) C++ library was broken for MSVC -- turns out that there were a resonably significant set of updates in the CVS with some template quirks that didn't compile with MSVC

Anyway - got those fixed (have a look at the OgreOde forum if interested) and am testing an updated binary..

Andy

This must be the exact same problems I was having when trying to compile everything by hand.

Which is why I went for the binary release of python-ogre

I can't wait!

Jacob

There is a snapshot update you can try [b]here[/b]

You'll need 7-zip and extract it over your PythonOgre installation, then run "python setup.py install" from the PythonOgre directory to update the modules etc..

It's VERY UNTESTED -- and has a number of underlying changes (most are in the changelog) however should allow you to test the makeTriangleMeshGeometry and makeComplexGeometry helper functions.. Both take python lists for vertices and indicies...

Now that we are back to a semi-stable environment I can help in a more responsive manner to the OgreOde issues (I don't even have test code written for these new functions so that would be useful )

Andy

I tried the snapshot you gave but I couldn't locate either of the functions you mentioned:

makeTriangleMeshGeometry or makeComplexGeometry

I checked both ogre.renderer.OGRE and ogre.physics.OgreOde but neither module contained these functions.

Jacob

Can we switch this conversation to email -- you can mail me at andy at python-ogre.org

Do grab the latest http://downloads.sourceforge.net/python-ogre/PythonOgre_Update_14102008.7z

And ensure you overwrite the existing installation and run python setup.py install..

You can run python ReportVersion.py before and afterwards to confirm the versions you have installed.

thanks
Andy

Hi Andy, couldn't resist having a go with the snapshot

Just in case you didn't know, none of the ogre constant properties ( ogre.Vector3.NEGATIVE_UNIT_Y, ogre.ColourValue.White etc. ) seem to be working:


self.raySceneQuery = self.sceneManager.createRayQuery(ogre.Ray(self.camera.getPosition(), ogre.Vector3.NEGATIVE_UNIT_Y))
Boost.Python.ArgumentError: Python argument types in
Ray.__init__(Ray, Vector3, property)
did not match C++ signature:
__init__(struct _object *, class Ogre::Vector3 origin, class Ogre::Vector3 direction)

Its consistent across everything, so I guess its an easy fix. Substituting normal variable arguments fixes it though, ie: ogre.Vector3(0,0,0)

Looking forward to trying out the proper release, and thanks again for all your efforts

Thanks for testing this, and the change you are seeing is intentional -- yes I know, another API change -- check out the ChangeLog for this and other changes..

Basically the problem with the current constant properties access is that they aren't 'const' and can cause some really bothersome bugs.. For example
v=ogre.Vector3.ZERO
print v # everything is OK here v=(0,0,0)
v.x=1
print v # still OK v=(1,0,0)
w=ogre.Vector3.ZERO
print w # Hang on -- w = (1,0,0)
v=ogre.Vector3.ZERO
print v # v = (1,0,0)
What's really happening is that boost is giving you a point to the same Vector3 structure, whereas what you really want is a copy of that standard structure. So now you have to do
v=ogre.Vector3().ZERO
print v # everything is OK here v=(0,0,0)
v.x=1
print v # still OK v=(1,0,0)
w=ogre.Vector3().ZERO
print w # w = (0,0,0)
v=ogre.Vector3().ZERO
print v # v = (0,0,0)
Sorry for the change, however it was the only way I could get it to work in a relaible fashion..

Andy

Ah, got ya!

So is the new correct method to use ogre.Vector3(0,0,0) as opposed to ogre.Vector3.ZERO ( or colourvalue etc. ) ? Or can those properties be instantiated as in ogre.Vector3.ZERO() ?

If you can clarify I'll have a go at updating the demos to reflect the change.

The new usage is:
ogre.Vector3().ZERO
ogre.Vector3().NEGATIVE_UNIT_Y

Regards

Andy

Ah yes,

should perhaps have read your first post properly then

Well, I will happily go through and try to update some of the demos when I get a chance.

On another note, I spent some time today converting the PSSM demo from the showcase forum to python-ogre, and have just got it working ( it looks awesome! ). I can add that to the demos as well if you like, although it is not currently integrated with the main shadows demo.

Would be great if you can add it to the svn

Andy

Share the wealth man, i would love to pssm in python.

Comitted to SVN, go get him!

Seems to perform loads better on an ATI card than on NVIDIA, but hey it works at least