First Release of Python-Ogre

We are pleased to announce the first release of [b]Python-Ogre[/b], a completely new implement of python bindings for Ogre.

Python-Ogre uses a great tool in [b]Py++ [/b] to automate the creation of the bindings, which greatly simplifies ongoing maintenance

Please check out the initial Windows binary release. Full source is available via SVN access for Linux users and anyone using the CVS version of Ogre

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

Thanks

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

Can you provide a python2.4 compatible windows binary? Some of the libraries that I'm using still doesn't have a 2.5 build yet. And Great work!

Can you provide a python2.4 compatible windows binary? Some of the libraries that I'm using still doesn't have a 2.5 build yet. And Great work!

It should not be a problem. I tested the bindings with Python2.4 on Windows.

Here is what I get after installation. Any idea?


C:\Documents and Settings\John>python
Python 2.4.2 (#67, Sep 28 2005, 12:41:11) [MSC v.1310 32 bit (Intel)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import Ogre as ogre
Traceback (most recent call last):
File "<stdin>", line 1, in ?
File "C:\Python24\lib\site-packages\Ogre\__init__.py", line 1, in ?
from _ogre_ import *
ImportError: Module use of python25.dll conflicts with this version of Python.
>>>


Sorry I was not clear. It should not be a problem to upload Python-Ogre.
It is just a matter of time. Python-Ogre compiled for Python2.5 will not
work on any other Python version.

Ok. Keep us posted!

Nice! If Py++ works as well as it sounds, it seems like it would reduce a lot of the work needed, compared to the current SWIG bindings.

It would be interesting to know if there are any specific benefits or drawbacks of the bindings generated by Py++ compared to the SWIG bindings, with for example performance, memory use, stability, or debugging.

How functional is it? Does everything bind, or are there still some rules left to configure, or something? Have you tested it extensively?

If there are no major (or even minor) drawbacks from using Python-OGRE compared to PyOGRE, I personally think that it sounds like a better choice if only for the fact that we as the end-users are not as dependant on the binders (Dermont, Istari, and perhaps some more? ). Last year, Clay (and fog) were the ones maintaining PyOGRE, but their lives got in the way I guess, and there were times when PyOGRE wasn't maintained by anyone. I think all the binders have made a great job so far, but I'm just saying that if getting a new binding of a new release of OGRE is mostly a case of rerunning the rules, then that can mean a lot, imho.

Also, could one assume that the rules can be used for the OGRE addons? In some cases I guess that could be really useful as well.

How documented are the rules? That is, if you died tomorrow (;)), would someone be able to quickly understand how to expand or configure them for future OGRE releases? That's the risk with both bindings, if there aren't enough people that understand them, and the binders stop maintaining them, they might be hard to continue working on, I guess.

I'll stop rambling now. Anyways, great job! I haven't tried them yet, but I will.

Oh, one last question. How compatible are they with the current bindings? That is, how compatible is the code we have written, will we need to rewrite a lot to get it working with your bindings, if we want to try that?

You should find that converting PyOgre code to Python-Ogre to be very simple (if not automatic). There are a couple of things to watch for:

Python-Ogre follows the C++ library directly when it comes to case senisitvity, so it's sceneManager.AmbientLight=.. not sceneManager.ambientlight=..
or Position not position.

Typically the attributes have a leading Upper case character which is sometimes different to PyOgre

Also if you are passing a ColourValue or Degree (etc) to a function then you need to specifically do so as we haven't yet added the automatic Tuple=>ColourValue functionality

We have included a reasonably full demo set with the binary release (and in the SVN) - most of which are the original PyOgre demos converted to Python-Ogre.

We haven't looked at all the addons, however as an example wrapping OIS (needed for the CVS version of Ogre) with Py++ took about an hour (most of that testing), and shouldn't need any updating in the event that OIS is updated...

Basically the advantages of Py++are huge compared to hand wrapping or any other 'automated' tool I've seen -- and it's written in Python

Cheers
Andy

The one disadvantage is that some people do have trouble getting Boost.Python compiled but besides that Boost.Python is very good. A very slick way to make C++ extensions for python. This is good example from the docs:
object f(object x, object y) {
if (y == "foo")
x.slice(3,7) = "bar";
else
x.attr("items") += y(3, x);
return x;
}
object getfunc() {
return object(f);
}

The one disadvantage is that some people do have trouble getting Boost.Python compiled

May be in the past, but not now:
http://www.boost-consulting.com/download.html

It is more user friendly to use the groups.google.com interface you just go here and see the trac environment here.

You should find that converting PyOgre code to Python-Ogre to be very simple (if not automatic). There are a couple of things to watch for:

Python-Ogre follows the C++ library directly when it comes to case senisitvity, so it's sceneManager.AmbientLight=.. not sceneManager.ambientlight=..
or Position not position.

Typically the attributes have a leading Upper case character which is sometimes different to PyOgre



Personally, that sounds a bit strange to me, for two reasons I guess.
1) It makes PyOgre code incompatible with Python-Ogre code.
2) Making the first letter upper case doesn't feel very pythonic.

Now, 1) would be ok if there were some compelling reason for it, and 2) is more of a personal opinion than anything else... but it just feels like an "unnecessary" choice to make?

I assume that when you say "Python-Ogre follows the C++ library", you mean that the upper-case letter matches the one in the corresponding API-call, i.e. Position <==> setPosition()... or possibly that there is a member variable in the c++-class that is called Position or m_Position , or something. If that assumption is incorrect, please enlighten me , but I think that the two reasons I stated weigh heavier than that. I'd love to hear what more people have to say about this.

Since Python-Ogre is still quite young, simple changes like this is easy to make, if some kind of consensus can be reached in our small forum community (and if you, as the developers of Python-Ogre want to follow it ).

We've been discussing this further on the python-ogre developers mailing list and will release an update (probably over the weekend) that has both leading upper case (or more specifically matches the C++ scheme) AND all lowercase attributes to solve this problem.

This way people can use either

Cheers

Andy

So.. it will be valid to do both
ogrenode.position = ...
and
ogrenode.Position = ...

?

What if you do dir(ogrenode), will both position and Position show? Are there any performance or memory "problems" with this solution?

So.. it will be valid to do both
ogrenode.position = ...
and
ogrenode.Position = ...

Yes

What if you do dir(ogrenode), will both position and Position show?

Yes

Are there any performance or memory "problems" with this solution?

There are no performance or memory problems at all.

There are no performance or memory problems at all.

Doesn't increasing the number of methods on an object in theory increase the amount of time it takes python to look up that method?

It shouldn't. Python uses dicts to hold member data for objects, and dicts are hash maps.

Then depending on the hash algorithm and implementation you should get pretty close to constant search time. I'm convinced .

Looks cool. Definitely gonna check this out. Thanks for the effort!

We are expecting to release the next version (binary build for windows, source for windows and linux always available via the SVN) over the weekend.

Main change is the addition of all lower case properties (in addition to properties with ogre 'C++' names) which will make it more compatible with existing pyogre code.

Also a couple of bugs fixed and (probably) CEGUI support.

Cheers

[b]Python-Ogre Development Team[/b]

That is good to hear, I was hoping to proptype a PythonOgre + PyODE application, and having CEGUI will make things nicer.

I hope that this means it will be easier and more feasible to get other Ogre addons wrapped, like PLSM2 and OgreNewt. Keep up the good work!

OgreNewt

That would be a dream and judging by how little code they actually have (besides that odd shared_ptr business) I think other Ogre pluggins might start falling like dominoes. Once enough people get Py++ experience of course.

I think other Ogre plug-ins might start falling like dominoes.

Today we already have Python bindings for: Ogre, OIS, CEGUI. I think, Andy is working on ODE. . If you are interested in Python bindings for other libraries consider to join us.

We made few improvements to the development environment. Basically there is no need to install GCC-XML. Python-Ogre SVN contains XML files for the projects. This makes dependency list shorter:
* Boost.Python ( http://www.boost-consulting.com/download.html )
* Py++ and pygccxml ( http://language-binding.net/index.html ).

It should be relatively easy to start working on Python bindings for a project.

I just read through most of the Py++ documentation (Haven't had a chance to look at the EasyBMP example wrapper) and I hope I can give Py++ a try. I think might give wrapping Log4Cpp as a test because I need a way to have unified logging in a Python + C++ application.

What has this to do with pyOgre? Perhaps you you should post on the py++ / python-ogre forums. Try the above steps on linux/mingw/VC8 and see the results.

Sorry I got off topic slightly, we went from pyOgre -> Python-Ogre -> Py++ Rocks -> Lets wrap every Ogre plugin! -> I hope I can use Py++ soon.

Besides all that I think you assume I am having trouble with Py++, I am not I was just musing about possible future uses of it (Much sexier than Swig). If I were, the Python-Ogre google group would be where I would ask for help.

</offtopic>

Will the Python-Ogre and pyOgre bindings exist together indefinitely? The only thing I could see causing a rift if is plugin support: Will Boost.Python wrapped Ogre plugin's be compatible with the Swig based pyOgre?

Sorry, didn't mean for that to come across so rudely. Anyway good luck with Python-Ogre.

This does bring up the question of what happens with two sheriffs in town. Is this town big enough for both?

I'm sure that having work split between two projects aiming for the same goal isn't the best thing. Is there interest or use in choosing one over the other and focusing all energies there instead of dividing effort?

I suppose it's incumbent upon PythonOgre (as the newer solution) to prove itself as a long term player before making a decision like that, but it still warrants discussion, IMHO.

I´m glad to see projects like this....
I made a wrapper for lua some time ago butr it haven´t been of much use, so i decided to stop working on it for some time, but then one day simply My machine refused to boot and i had to format it...

but well... the past is the past... also í´ve decided to switch to python..


I'm sure that having work split between two projects aiming for the same goal isn't the best thing. Is there interest or use in choosing one over the other and focusing all energies there instead of dividing effort?

i think so... and Python-Ogre seems a cool aproach for me , if i can get it to work
the problem is this one:

seci = config.getSectionIterator()
RuntimeError: unidentifiable C++ exception

That´s what the interpreter throws in the _setUpResources function...
any idea of why is it perhaps i´m having a Version disorder:I´m using
-OgreSDK version 1.2.3
-Python-Ogre Version 0.5.1
-Python version 2.5

First ensure you are using the VC 7 OgreSDK, NOT the VC8 version!!! This is normally what causes this problem (and I'll update the FAQ on the web ste

If this doesn't solve your problem then I'd suggest you delete your /python25/lib/site-packages/Ogre directory and reinstall Python-Ogre as the fix to make:
config = ogre.ConfigFile()
config.load('resources.cfg' ) #, '', False )
seci = config.getSectionIterator()
while (seci.hasMoreElements()):.......
work was in 0.5.1 but not in 0.5.. If you had tried 0.5 initially the 0.5.1 version may not have installed correctly.

Let me know if this helps..

First ensure you are using the VC 7 OgreSDK, NOT the VC8 version!!!
As I feared...
I really can´t use the VC 7.0 SDK, because i don´t have broadband in my PC for now, so downloading the 30 megs isn´t a choice....

are you planning on releasing a VC 8.0 compatible version sometime soon?

I think that I will load resources.cfg manually(with ResourceGroupManager.addResourceLocation) until a better way appears...

Ok, it works for me... (but i can´t use resources.cfg for now, not a problem for me.. in fact, it is easier to parse a XML file with python that with c++, hehe...)

SkeletalAnimationDemo isn´t working, i tink it doesn´t have to do with python-ogre..
after dinner i will check it out...
Good stuff!thanks!

There are no 'gaurantees' if using the VC8 SDK as I suspect it will cause a variety of strange behaviours...

The reason we are using VC7 is due to Python, which (as far as I know) only supports VC7 extensions, due to the fact that this is the compiler it is compiled with...

I've tried previously to get VC8 extensions to work with Python without success, hence this is why we are sticking with VC7..

It is likely that the next binary release of Python-Ogre will include all the Ogre (etc) dll's so this issue will go away.

Cheers
..........

no, SkeletalAnimationDemo doesn´t work, it crashes in
trackIter = anim.getNodeTrackIterator()
but it´s not a problem for me by now



my best wishes for python-Ogre
( i think i will begin learnning how to use Py++, as it appears to be must-have tool for creating wrapper fast,hehe)

It's definitely a VC8 SDK issue - basially you have to use the VC7 Ogre SDK with Python-Ogre (at least today )

Have anyone try this binding on Linux?

yes, it's been fully ( ) tested with Linux.

You'll need to grab the SVN version etc, and let us know if you have any problems

Cheers

mailto://python-ogre-developers@googlegroups.com

It is quite a good news that python-ogre support both Linux and Windows.
I will try it later, on Debian + AMD64.

But there is still one question: How about cegui?
I didn't find cegui module in python-ogre, is cegui fully supported in this binding?

But there is still one question: How about cegui?
I didn't find cegui module in python-ogre, is cegui fully supported in this binding?

I am not sure about fully. The bindings are pretty new. CEGUI demo should work.
Related links:
http://python-ogre.python-hosting.com/browser/trunk/python-ogre/code_generators/CEGUI
http://python-ogre.python-hosting.com/browser/trunk/python-ogre/demos/CEGUI/

Yes the CEGUI in the SVN does seem to be pretty good - we might have missed wrapping a widget or two (if so let us know), and the way subscribeevent is handled is slightly different to pyogre.
.subscribeEvent(CEGUI.PushButton.EventClicked, self, "handleQuit")
.subscribeEvent(CEGUI.PushButton.EventClicked, freefunction, "")
First attribute needs to be a fundemental CEGUI."widget" event, and then either specify 'instance', "method" ; or 'freefunction', ""
Check out the examples for further information..

Please note that OIS is part of the SVN and is working, as is OgreRefApp (check out the BSPCollision demo) , however ODE is work in progress.

VC7.1, not VC7. VC7 is a horrid compiler, no updates from VC6. VC7.1 had a complete make-over and is now one of the most complient out. Do not compile it with VC7, just 7.1 as that is what Python is compiled with.

Agreed, my mistake in not being clear - VC 7.1 it is........

can I ask for a little favor?
could it be possible for anyone to upload another Windows binary of Python-Ogre, but including the CEGUI bindings?
(i cant use Py++ for now, so I would be very grateful if someone did it for me)

I have used an extension I created (using SWIG) and compiled with VC8 for Python 2.4. It works without issues. So, are you sure that VC8 extensions are the problem with Python-Ogre?

I'd like to be able to try it out, but I only have VC8 available to me (and I don't really want/need VC7.1 anyway, other than for this).

We'll put out a new windows binary version in the next week or so (it might be sooner, but no promises) with CEGUI (and more )...

Cheers

Python-Ogre Development Team

Is there any progress on the binary release?

being tested by the team as we speak - all things going well there will be a release in the next 6-8 hours..

Lots of improvements

Cool!!