what's the relationship between pyogre and python-ogre?

Are they totally separate projects or is python-ogre a new solution by the same team?

Since there's lotsa hypes on python-ogre lately and it uses a later version of ogre. Also using py++/boost.python means it's a lot easier for it to catch pace with the ogre engine updates. I'm wondering if python-ogre is to replace pyogre and if all the development effort will be redirected to it. Or will pyogre continue to be maintained and developed.

Python-Ogre was started by a group of PyOgre users who were frustraded with the usability of the Swig based wrappers. Judging by the speed at which Python-Ogre is wrapping not just Ogre, but its addons as well I am starting to wonder if PyOgre is needed anymore.

Python-Ogre still has some rough edges (no tuple to Vector3 or Colour transformation) but it is still very cool. I finally have a good enough Linux box to run Ogre so I can report more on Linux usability soon.

I am not trying to say the work on PyOgre was useless it just seems that Py++ & Boost.Python are a better (if somewhat heavier weight) wrapping solution than for C++ with python than Swig.

i agree with Game_Ender, python-ogre still has some rough edges, that's why it isn't version 1 yet.

IMHO python-ogre is going to be more up-to-date and would have more support than pyogre. but in the meantime, pyogre is more stable to develop on with. hence.. im sticking first with pyogre but am also planning to test my codes with python-ogre.

i agree with Game_Ender, python-ogre still has some rough edges, that's why it isn't version 1 yet.

IMHO python-ogre is going to be more up-to-date and would have more support than pyogre. but in the meantime, pyogre is more stable to develop on with. hence.. im sticking first with pyogre but am also planning to test my codes with python-ogre.

It could be nice if you can say what do you mean by "rough edges". We plan to release next version pretty soon, so you have a chance to get the desired functionality working. I am aware to the next problems:
1. It is not possible to call all exported functions. I think, we will fix almost all bugs in this area.
2. Missing convenience functionality ( constructing VectorX and Color from tuple )

What do you think should be fixed or improved for the next release?

A fully integrated build system is the only other thing I can think of. Something where you download the source. Install all the needed dependencies, adjust environment.py to point to them, and then type "scons", or "make" and in a little while you will have PythonOgre. Preferably this would work on Windows, Linux and Mac.

Heh, it is kinda funny to dig back through the history of the python bindings.

May 2001 - Trying SWIG
http://www.ogre3d.org/index.php?option= ... 0&Itemid=2

June 2001 - Switching to Boost
http://www.ogre3d.org/index.php?option= ... 8&Itemid=2

April 2005 - Boost too hard, switching to SWIG
http://www.ogre3d.org/wiki/index.php/In ... _to_PyOgre

Oct 2006 - Someone else decides SWIG too hard, back to Boost
http://www.ogre3d.org/phpBB2addons/viewtopic.php?t=2511

Makes me not feel bad about not being able to decide between SWIG/Boost on my own project...

To be fair it's not really about the merits of SWIG vs Boost - but all about the build tools available for each.

SWIG is a great wrapper, however anything you do with it (from a python perspective) requires lots (and lots) of manual work

And Boost until recently was the same. Although it is more "modern"? in that it is based on C++, makes extensive use of templates etc etc

However, Python-Ogre really started with Roman creating Py++, and Larkin then creating the first verison of Python-Ogre using Py++.

Py++ allows the wrappers to be "automagically" created, which means it's much easier to keep things up to date (the maintainence on the Py++ based wrapper is tiny compared to any other system I've used). It also allows us to wrap other libraries fairly easily.

The current release of Python-Ogre seem to be very solid - problems are related to stuff we haven't tested/checked more than any basic instability - and there will be a new release before Christmas that should expose everything (nearly) else

Practically speaking, how much breakage can I expect when moving between the two?

Are the developers actively trying to keep the python code compatible (except for the tuple->ogre.XXXX conversions, which are just a minor annoyance in my code at least), or is it a whole different ballgame? I'm especially curious about the "propertification" that pyogre does, is it matched in python-ogre?

I'm not planning to switch the "release" version of my project over just yet, but I intend to try and port it and see how it shapes up.

I have found it more difficult to create a standalone app in Python-Ogre (ie: one that does not use the sampleframework) than in pyOgre. I still have not managed to do this, which is annoying I think part of the problem is that sampleframework is actually quite embedded in the python-ogre library making it difficult to un-pick.

that said, I'm majorly impressed with the amount of functions it includes, and native 'out-of-the-box' support for physics is a great bonus. I'll definitely be using python-ogre in the future, but would appreciate if someone could do an example without the sampleframework.

The sampleframework that is used by the demos in Python-Ogre is basically the same as that used in pyogre so there isn't any real difference here.

Also converting between the two is fairly straightforward, as it's the underlying library calls that are being exposed and these are consistant.

If you want an example that doesn't use the Sample Framework that this is very doable, what would you like it to do and I'll add it to a future release..

Cheers
Andy

Well, something like the pyogre example that simply displays a blank ogre window would be great, just something to get started with.

I'll just take this opportunity to say thanks for all your efforts getting python-ogre together, its really great, and I'm sure it will be spectacular when we reach 1.0 (oooh ... )

I am now part of the Python-Ogre .

I have a standalone Python-Ogre application and yes it did take me several hours to sort through the multiple frame listeners and sample framework classes to extract that exact initialization sequence. I should also note its the only second Ogre application I have ever made and I had to learn OIS, CEGUI, and Ogre 1.3 in the process.

I will try and post a practical/minimal Python-Ogre application and post on the Python-Ogre wiki. I will need to do this anyway because my application which works on Windows, shows a blank screen on Linux (yes the demos do work).

So that will get on my list along with getting OgreNewt working better.

That would be awsome thanks!

finally, i've translated my old pyogre code completely to python-ogre, yes it's stand alone also. removed pyODE and is now using OgreNewt. removed pygame's input & pyogre's input handling to OgreOIS. i'm using pySonic now, added mysql connectivity and non-blocking udp networking capability via asyncore. no cegui yet though. everything's going great and right now the progress on my project is extremely slow because of the exponential growth of complexity with regards to the number of lines of code. haha

i based the stand-alone-ish of my app from the pygame & pyogre snippet i used before (it's somewhere in this forum/wiki). the structure's still the same because im rendering on pygame's double-buffed-hardware-supported-fullscreen which is exceptional nonetheless. tried to tweak the window creation from the ogre's init dialogue, and now it can't get the resolution from the dialogue.

i can put this in the python-ogre as well too if you guys want. a kind of python-ogre and pygame combined sample structure. havent tested on linux though, my linux box doesn't work anymore

Cool jintal. I managed to get python-ogre to play nice with pygame as well, although I am using pygame for input and sound, as I like it's input api much better than ois, and for now pygame's sound is good enough. It was a bit of work to get the window set up correctly, and I had to parse the config file manually to get the resolution due to the configuration bug (which I think is fixed in the next release).

A sample structure to work off of designed for pygame would have helped a lot to start out with.

sorry saluk, should've posted my sample struct sooner.

i will later though, after i go to the gym.