Python-Ogre V0.8 Release

Well it's been more than a month since our last release, so here we go again Version 0.8 of Python-Ogre, python bindings for Ogre (and other libraries) based upon Py++ is now available

This release further enhances support for the base OGRE library (there have been lots of updates in the underlying Ogre CVS code), CEGUI (Graphical user interface), OIS (input library), OgreRefApp (ODE Physics) and OgreNewt (Newton Physics). Plus this release adds initial support for sound in the form of OgreAL (plus FMOD is getting close), and an alternate physics library with OgreOde (we've put it out there without any demos which will be available soon). Look here for more specific on this release

As with previous releases we've included are all the necessary windows binaries based upon the latest CVS verison of Ogre. Full source is available via SVN access for Linux users and Windows users wanting to build from source

Downloads can be found here

Note that it's still early in the development cycle for Python-Ogre, so please be kind when reporting bugs and we'll do our best to get them resolved as soon as possible.

Please copy the python-ogre-developers@googlegroups.com with any problems or comments.

Thanks

The Python-Ogre Development Team
(Lakin, Roman, Andy, Game_Ender)

The Python-Ogre Development Team: Lakin, Roman, Andy, Game_Ender

Cool!
Downloading it now....

Thank you, thank you, thank you !!!!!!!

Please keep up with it !!

Regards
Bernd

cool, thanks for the new release. Ode + openAL etc. is ace!!

sorry to bear bad news ..

seems to be soe problems with the 2.4 release, I'm getting errors relating to displaying ogre exceptions for quite a few of the demos eg:

the procedure point <blah blah> ogre exception <blah blah> could not be located in ogre.dll.

traceback gets to the _ois_ import before bombing out with something like the above error. Am getting this mainly with ogreNewt demos, and some of the base ogre demos.

disregarding that - Thanks again for 0.8, great work! (guess i should move to python 2.5 then, will test out that later)

very nice! will try out as soon as i can

seems to be soe problems with the 2.4 release, I'm getting errors relating to displaying ogre exceptions for quite a few of the demos eg:

the procedure point <blah blah> ogre exception <blah blah> could not be located in ogre.dll.

Not good - could you capture the error output and send it to the Python-Ogre mailing list and I'll help you there..

Of course, before doing this can you do a completely clean install -- delete the /python/lib/site-packages/Ogre, OIS, OgreNewt, CEGUI directories then run python setup.py install and try the demos again..

Thanks
Andy

Cool, that seems to fix the problems i was having. I did the standard 'setup.py install' last time, but did not erase the previous version from site-packages, which would explain things

I'm planning to install py2.5 tonight and will properly test out this release if i get a chance, and will log anything i find in detail. Something I did notice already, is the ragdoll demo supposed to work yet? it loads up on my system, but the balls do not interact with the zombie (they just go through him, good for mr.zombie!)

anyways, thanks again for all your hard work, it is very much appreciated!

Glad to hear you fixed the problem..

Demo06_Ragdoll isn't completely finished (I'm happy to take a fixed version from anyone that wants to finish it).. The main reason is that it's a conversion from 'TinyXML' to the Python XML library, and the problem is in the Python Demo code, not in the Python-Ogre library

I'll update the wiki FAQ to reflect this....

Cheers
Andy

I have updated the Download and FAQ page to remind the user to uninstall the previous version before install the new one.

There is an updated demo file available in the download section of the Python-Ogre web site specifically to showcase the OgreOde wrapper..

Not perfect yet but pretty cool just the same -- and yes, it causes a window error on exit because I'm not deleting stuff correctly in the Python demo code

Cheers
Andy

Not perfect yet but pretty cool just the same -- and yes, it causes a window error on exit because I'm not deleting stuff correctly in the Python demo code

That is my current gripe/task with Python-Ogre. There is no documentation on what references should be explicitly dropped and in which order. I think I have figured most of it out but I am still not getting things to work perfectly on both windows and Linux. When I get it figured out I will post the information.

You know, python-ogre devs, you should just wrap many of those things with boost::shared_ptr's (which are perfectly compatable with python) and pass in a destructor of your own that adds things to a destruct list that is destructed when the children for a given object are destroyed. I have done this with my own engine with things I've exported to python, runs perfectly.

Would you happen to have some sample code you could share that shows this (as it sounds like a great idea)..

Perhaps post it to the Python-Ogre mailing list.. "python-ogre-developers@googlegroups.com"

Thanks

Andy

Andy, I fully understand what he( OvermindDL1 )is talking about,
Please contact me with description of the problem.

No time at the moment for a detailed explanation, but it is quite easy to do and near brain-dead obvious once it is finally noticed (should have seen what I was doing before-hand). Not to mention, makes things work well with python's reference counting and so forth (no forcing users to destroy things and so forth, a simple 'del var' works perfect then, even on things that should be passed to another instance somewhere to kill). Have to think pythonized when wrapping stuff.

Could someone please describe the technique of using shared pointers for Python objects a little more? I have a general idea of what it means, but more info would be much appreciated.

Could someone please describe the technique of using shared pointers for Python objects a little more? I have a general idea of what it means, but more info would be much appreciated.

The question is too general, so the answer. Basically it is possible and not that difficult to expose classes and the appropriate instantiation of the smart pointer classes in a such way that for Python user it will be transparent what he is using.

For example:

struct X{
void do_smth();
};

boost::shared_ptr<X> get_shared_x();
X get_x_by_value();

If you expose this code correct, than from Python the usage of the return value is same:

x = get_shared_x()
x.do_smth()

x = get_x_by_value()
x.do_smth()

Python-Ogre project uses this Boost.Python functionality to provide "expected" interface. The nice part of Python-Ogre solution is that it always works, even if Ogre team adds\removes new classes. See code:
http://python-ogre.python-hosting.com/f ... red_ptr.py

If you need more information consider to ask your questions on Boost.Python mailing list. Or take a look on online example I created:
http://language-binding.net/pyplusplus/ ... _ptrs.html

Thank you for all this information, Roman! I appreciate you taking the time to reply.