PyOgre 1.2

Hi folks,

since ogre version 1.2 is thrown out now, when can we "pythons" await a downloadable version of PyOgre 1.2 ?

Thanks for your immense work, cculver and fog !!

Regards
Bernd

Bump, I am also very interested in a response

I'm also extremely interested. Further, I'd be willing to help in anyway possible ...

I fear the worst... Clay hasn't replied to any forum posts in a very long time.

I fear the worst... Clay hasn't replied to any forum posts in a very long time. :cry:

Oh my God, you mean he's .... switched to Ruby?

I think he might be finishing up his degree this semester... I guess we'll only find out after April.

It's a bit worrisome that pyOgre development is stalled with Clay's hiatus. Hopefully it's temporary, but what if it's not? Are the changes that came with Dagon so enormous that we can't bring pyOgre up to date without Clay's help? After all, the majority of what he's done will still work, and should provide excellent tutorials on how to handle the changes.

(As I only need a few things from Dagon, maybe my best solution is to backport these mods and tweak pyOgre correspondly.)

I've already posted a patch here on the updates that I made to port the bindings to pyOgre1.2 for pyOgre and pyCegui.

http://developer.berlios.de/patch/?func=detailpatch&patch_id=942&group_id=3464

So far all the existing ogre and cegui demos run. I've also added Ogre's new facial animation demo.

I've only tested that they compile on mingw/gcc.

Primarily I've concentrated on getting it to compile and adding new functionality as I saw it. There's still a bit of work to do in terms of adding missing features and fixing errors I've probably introduced. I'm hoping to start on those this weekend.

This should be taken as a WIP, there's no guarantee that Clay will accept any of changes I made, and as such I provide the link for those considering updating the bindings themselves.

Any feedback, comments or help would be greatly appreciated.

Thank you for the efforts!

I'm relatively new to ogre/pyogre, but I definately intend to take advantage of it for my projects.

So just want to show my support.

I tried building CVS pyOgre against a source build of Dagon and (no surprise) it spit the proverbial dummy. I then applied Dermont's patch (see above) and pyOgre compiles (in the "-c" sense ;-) That's a huge step forward; thanks Dermont for your work in this respect.

I'm having trouble linking it though. This is with VC++ 2005 Express. Here's the build log. Any suggestions are much appreciated ...

1>------ Build started: Project: pyogre, Configuration: Release Py24 Win32 ------
1>Linking...
1> Creating library Release Py24/pyogre.lib and object Release Py24/pyogre.exp
1>ogre_wrap.obj : error LNK2019: unresolved external symbol "__declspec(dllimport) public: __thiscall Ogre::MaterialScriptCompiler::MaterialScriptCompiler(void)" (__imp_??0MaterialScriptCompiler@Ogre@@QAE@XZ) referenced in function __wrap_new_MaterialScriptCompiler
1>ogre_wrap.obj : error LNK2001: unresolved external symbol "protected: virtual void __thiscall Ogre::MaterialScriptCompiler::executeTokenAction(unsigned int)" (?executeTokenAction@MaterialScriptCompiler@Ogre@@MAEXI@Z)
1>ogre_wrap.obj : error LNK2001: unresolved external symbol "protected: virtual void __thiscall Ogre::MaterialScriptCompiler::setupTokenDefinitions(void)" (?setupTokenDefinitions@MaterialScriptCompiler@Ogre@@MAEXXZ)
1>ogre_wrap.obj : error LNK2001: unresolved external symbol "public: virtual class std::basic_string<char,struct std::char_traits<char>,class std::allocator<char> > const & __thiscall Ogre::MaterialScriptCompiler::getClientBNFGrammer(void)" (?getClientBNFGrammer@MaterialScriptCompiler@Ogre@@UAEABV?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@XZ)
1>ogre_wrap.obj : error LNK2001: unresolved external symbol "public: virtual class std::basic_string<char,struct std::char_traits<char>,class std::allocator<char> > const & __thiscall Ogre::MaterialScriptCompiler::getClientGrammerName(void)" (?getClientGrammerName@MaterialScriptCompiler@Ogre@@UAEABV?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@XZ)
1>ogre_wrap.obj : error LNK2019: unresolved external symbol "__declspec(dllimport) public: virtual __thiscall Ogre::MaterialScriptCompiler::~MaterialScriptCompiler(void)" (__imp_??1MaterialScriptCompiler@Ogre@@UAE@XZ) referenced in function "public: virtual void * __thiscall Ogre::MaterialScriptCompiler::`scalar deleting destructor'(unsigned int)" (??_GMaterialScriptCompiler@Ogre@@UAEPAXI@Z)
1>..\..\..\pyogre/_ogre.pyd : fatal error LNK1120: 6 unresolved externals
1>Build log was saved at "file://c:\cygwin\home\darran\Ogre\pyOgre\trunk\scripts\vc80\pyogre\Release Py24\BuildLog.htm"
1>pyogre - 7 error(s), 0 warning(s)
========== Build: 0 succeeded, 1 failed, 0 up-to-date, 0 skipped ==========

I've already posted a patch here on the updates that I made to port the bindings to pyOgre1.2 for pyOgre and pyCegui.

A naive question. What is the syntax for applying such a patch that spans files in different directories? I manually went to each directory and applied it but no doubt there's an easier way ...

There are some errors for the meantime just comment out the compilerPass / Composisition stuff in ogre.i:

// Compiler Pass / Composition Pass/Technique
//%include OgreCompiler2Pass.i
//%include OgreCompositor.i
//%include OgreCompositionTargetPass.i
//%include OgreCompositionTechnique.i
//%include OgreCompositionPass.i

// Script Compilers
//%include OgreCompositorScriptCompiler.i
//%include OgreMaterialScriptCompiler.i

// Compositor

//%include OgreCompositorInstance.i
//%include OgreCompositorChain.i
//%include OgreCompositorSerializer.i
//%include OgreCompositorManager.i

futnuh wrote
A naive question. What is the syntax for applying such a patch that spans files in different directories? I manually went to each directory and applied it but no doubt there's an easier way ...

Probably my fault should have created the patch from the top pyogre directory.

I've made a few changes and zipped up the interface files. Someone else had problems but managed to compile pyogre but is still having problems with pyCegui.

Either PM me your email I'll send you the zipped files or later today I'll update the patch accordingly.

I'm having the same problem -- patch doesn't like the multi-file format for some reason, so I have to break the patch apart and apply each one individually. There are quite a few.

If you can upload the zips somewhere, that would be great. Or send them to me, and I'll gladly host them for others.

Okay, I've made some progress.

It turns out that the cygwin patch command isn't smart enough to turn '/' into '\' in pathnames, so I had to manually edit the patch to get it to work. I was also running the version of the PyOgre source from the download site, rather than the latest svn version. I got the svn version, applied the patch, and went to compile under VC 7.1.

I now run into the error:

object file format limit exceeded: more than 65,279 sections

Anyone seen this before?

I used dermont's patch (worked perfectly, thanks!) and made some packages. This is my first time building pyogre, so I hope I didn't screw anything up. I used VC8. Let me know if they work for you.

I uploaded one Win32-ready package with DLLs:
http://www.cse.buffalo.edu/~pkdawson/fi ... -win32.zip

And one package with no DLLs:
http://www.cse.buffalo.edu/~pkdawson/fi ... 1.2rc1.zip

Neat, I'll be sure to check them out. I've just started going through the interface files in some detail. I've already made some updates, namely:


a) implemented BillboardChain::Element (stolen from Rastaman's dotnet)
b) updated LightingDemo.py for RibbonTrails
c) Added some missing classes
d) Added custom attributes for OgreRenderTarget
- Added specific custom attributes
getRealCustomAttribute
getIntCustomAttribute
getBoolCustomAttribute
getStringCustomAttribute

Example
-------
hwnd = self.renderWindow.getIntCustomAttribute("HWND")[0]
print "Windows Handle Value is",str(hwnd)

e) bits and bobs cleaned up some get/set's
f) checked through Ogre classes S-Z



Still lots to do hopefiully can get to them this weekend. Since your hosting the files if you PM me your email address I'll send the .i files directly and
update the SVN patch to point this thread.

Thanks.

object file format limit exceeded: more than 65,279 sections

Had that error too, until I got VC 8.0

I used dermont's patch (worked perfectly, thanks!) and made some packages.

Could you tell us how you successfully applied the patch across multiple files? Is there some command line trickery ...

As I've already mentioned the patch problem across mulitple files was my screw up. I didn't create the patch from the root pyogre directory. I have already updated the patch. As for applying the patch I use TortoiseSVN on windows. Check details here for applying a patch using TortoiseSVN:

http://blog.ftwr.co.uk/archives/2005/11/03/windows-wordpress-toolbox/

Just apply the patch from the main trunk directory.

I used dermont's patch (worked perfectly, thanks!) and made some packages.

Could you tell us how you successfully applied the patch across multiple files? Is there some command line trickery ...

cd pyogre
patch -p0 -i path_to_patch_file.patch

The patch command is not available on windows.

OvermindDL1

The patch command is not available on windows.


I've always used the version of patch that ships with UnxUtils:
http://unxutils.sourceforge.net/

Thanks! I downloaded these, and the worked first time.

I think the problem I ran into was because I'm using VC 7.1 instead of VC 8.

The patch command is not available on windows.

If you download cygwin, you can use the patch command that comes with it. Be aware, though, that you have to manually edit the patch file to reverse the direction of the slashes. Otherwise you'll get errors about not being able to find the files.

Specifically, any line that begins with "Index:", "---" or "+++" should have any /'s turned into \'s.

So, to summarize...

1) Start with the version of PyOgre from the SVN repository, not the one on the download site (other wise you'll get errors when you try to apply the patch)

2) Apply demont's patch, replacing /'s with \'s in the patch file if necessary (depending on what implementation of patch you use)

3) Compile under VC8 (not VC7), to avoid the "object module size" problem

I've also noticed that in some of the cegui examples, I had to put a str() around the first argument to subscribeEvent(). Some examples had this, some didn't, but in the ones that didn't I would get an error saying the first argument had to be a string. I'll be looking at the code more closely over the weekend to find out why this is needed.

Many, many thanks to Demont for getting this going. I'm a huge fan of both Python and Ogre, and the combination of the two makes for very rapid development. I look forward to helping out in any way I can.

I updated my pyogre packages, thanks to more of dermont's work.

Functionality added since initial patch SVN:
a) implemented BillboardChain
b) updated LightingDemo.py for RibbonTrails
c) Added OgreRotationalSpline and OgreSimpleSpline
d) OgreRenderTarget
- Added specific custom attributes
getRealCustomAttribute
getIntCustomAttribute
getBoolCustomAttribute
getStringCustomAttribute

Example
-------
hwnd = self.renderWindow.getIntCustomAttribute("HWND")[0]
print "Windows Handle Value is",str(hwnd)

e) bits and bobs cleaned up some get/set's
f) checked through Ogre classes S-Z

http://www.cse.buffalo.edu/~pkdawson/files/pyogre/

By the way, I used patch from Cygwin, and it didn't mind about the slashes. The patch applied cleanly as-is. *shrug*

Download:
Source
Binaries
Binaries + Windows DLLs

Useful tools, will get them, and I don't like Cygwin personally, would rather just restart into my FreeBSD OS, or just start up FreeBSD in a VPC if I don't need the raw speed.

I don't like Cygwin either, personally on windows I use MSYS.

BAH, I thought I knew most utils out there and everyone here keeps listing more things off. MSYS is?

BernieRoehl wrote:

I've also noticed that in some of the cegui examples, I had to put a str() around the first argument to subscribeEvent().


Yep I stated that on the comments on the SVN. This only became an issue
with >Swig1.3.28. I only updated some examples as a temp fix. It probably shouldn't be too difficult to fix. Any help you can contribute would be greatly appreciated.

OvermindDL1 wrote:

MSYS is?


From the mingw site:
http://www.mingw.org/
MSYS: A Minimal SYStem to provide POSIX/Bourne configure scripts the ability to execute and create a Makefile used by make.

Theres even instructions on installing/building Ogre from MSYS:
http://www.ogre3d.org/wiki/index.php/Build_OGRE_dependencies_using_MSYS

For me MSYS is more akin to a Linux shell - maybe just a personal thing.

I updated my pyogre packages, thanks to more of dermont's work.


I get this error with your build:

Description: Could not load dynamic library .\RenderSystem_Direct3D9. System Error: The specified module could not be found.

No matter what PluginFolder I use, including an absolute path.

What version of DirectX 9 are you using?. I believe that pkdawson is using
the February 2006 Update. Installing D3DX9_29.DLL from here solved it for me:

http://www.threelights.de/index.php?page=projects/d3dx9_xx_dll_files.php

BernieRoehl wrote:

I've also noticed that in some of the cegui examples, I had to put a str() around the first argument to subscribeEvent().

Dermont wrote:
Yep I stated that on the comments on the SVN. This only became an issue
with >Swig1.3.28. I only updated some examples as a temp fix. It probably shouldn't be too difficult to fix. Any help you can contribute would be greatly appreciated.


Ok, the str thing has been resolved. Comparing with a previous version of cegui.py

cegui.py(Previous)
EventAlphaChanged = _cegui.cvar.Window_EventAlphaChanged
..
EventAlphaChanged = "AlphaChanged"

cegui.py(Current)
EventAlphaChanged = "AlphaChanged"
..
Window.EventAlphaChanged = _cegui.cvar.Window_EventAlphaChanged

Seems like the ignore in cegui_string never really worked and with the different order it's now picking up the Event name as a cegui str.

Anyway the inelegant solution was to add ignore's to the associated cegui's *.i files. This also highlighted a couple of missing event names (presumabely introduced in 4.1) which have been rectified.

What version of DirectX 9 are you using?. I believe that pkdawson is using
the February 2006 Update. Installing D3DX9_29.DLL from here solved it for me:

http://www.threelights.de/index.php?page=projects/d3dx9_xx_dll_files.php

That did it. Thanks!

any news about pyogre 1.2 ?

Regasrds
Bernd

The current status is that for Ogre 1.2RC2 I've updated the swig bindings so that pyOgre compiles and runs. That's it really. There are lots of errors,problems and things still to do. Each individual class / method has to be gone through tested and updates made accordingly.

With Clay no longer involved in the project, and I don't know Fog's intentions, there isn't AFAIK anyone else working on this. I don't really have much time to spend on this nor the swig/python experience of either Clay/Fog, so I can't really say when it will be complete.

If there's someone with more experience in swig/python/ogre then perhaps they should contact Clay or Fog.

Failing that if anyone is interested in continuing this project I'll post any updates that I make as a patch to the berlios site until such time pYOgre is stable enough to be tagged.

puh, that's not good news. PyOgre just started to become my favorite 3d development toolkit, but if the constructors are off, it is somewhat disappointing.

Regards
Bernd

puh, that's not good news. PyOgre just started to become my favorite 3d development toolkit, but if the constructors are off, it is somewhat disappointing.

Regards
Bernd

DITO!!!!!

Double ditto. If I had the time and ability I'd take up the task. I really love PyOgre.

Bad, bad news indeed.

Maybe we could create a donation fund and then use the money to pay someone to take on the task? Would anyone be willing to donate to such a fund? Money gets things done, you know.

Hi all. I think I can help with creating Python bindings for Ogre.

First of all, let me introduce my self:
my name is Roman and I am the author of pyplusplus Python package:

home page:
http://www.language-binding.net/pyplusplus/pyplusplus.html

tutorials:
http://www.language-binding.net/pyplusplus/tutorials/module_builder.html.

SourceForge page:
http://sourceforge.net/projects/pygccxml/.

I believe, that using pyplusplus you can dramatically improve
the time needed to develop Python bindings.

Using pyplusplus I created bindings for few projects:
boost.date_time ( you can download it from SourceForge )
EasyBMP ( you can download it from SourceForge )

Next projects are in SVN:
boost.random
boost.crc
boost.rational

I can post links to the scripts, that create bindings
for those libraries.

External projects:
Python Computer Graphics Kit
http://cgkit.sourceforge.net/

What so special in pyplusplus? pyplusplus allows you to work
on whole project at once. More over it allows you to reuse
coding standards and conventions. Also you are able to setup
few roles, that will work even after code is changed.
It does not matter wether you add new function or class.


What do you think?

Roman

P.S. sorry for such "self-advertising" posts

Anything that will get the job done is great. Doing it more efficiently and elegantly using your tool is all the better! I look forward to your contributions.

Would you also be able to work on a Mac version?

I am sure I was not clear enough. I am not going to create next version
of PyOgre. I can work with somebody who knows ogre very well, in order
to create bindings. I can help him to start and produce bindings, using
pyplusplus and boost.python

I can help him to start and produce bindings, using pyplusplus and boost.python

So you have made another pyste?

So you have made another pyste?

It's depends: another boost.python code generator - yes.
Another pyste - no. Here is a link that compares Pyste and pyplusplus
http://www.language-binding.net/pyplusplus/comparisons/pyste.html

How does boost.python with pyplusplus compare to swig?

Regarding the future of pyOgre, if Clay/Fog doesn't freely come back to rescue his love-child, either paying him or someone else to continue development is an option. I can't offer any guarantees in this regard but, having recently started an interactive VR company http://www.edmstudio.com that is heavily dependent on Ogre/pyOgre, we can't afford to let it die. Over the next month we'll be moving into our studio space and beginning to demo 3D content on our hardware - all with the aim of attracting paying clients. Some of this income will be directed back into the open source community.

Also, anyone reading this shouldn't shy away from the existing pyOgre. We are doing commercial quality work thanks to Dagon's support for asymmetric view frustums (needed for stereo), Clay's pyOgre and Dermont's patches. Jump in ... it really is an amazing toolkit.

I think there's a few people willing to help (including myself), but IMHO we need some leadership. My problem is that I'm not sure what still needs to be done (mostly because I've been pretty satisfied with PyOgre 1.0.6). I'm willing to contribute if there's somebody that can manage contributed patches, maintain a TODO list, etc.

I'm willing to put some time and effort into maintaining pyogre. I can't commit to maintaining it completely by myself. However, I'm currently dissappointed at the state of the swig bindings, as I've utterly failed to get them working on Linux(Ubuntu) with the fglrx (ATI) drivers. I know that there are a number of posts on this subject in this forum, and the general consensus is that it just doesn't work. If this has changed with the pyogre 1.2 bindings, then please let me know.

As such, I'm investigating the pyplusplus stuff that Roman talked about. However, instead of hijacking this thread, I'll start a new one to discuss how those bindings are going. Please understand that I'm only doing this because the SWIG bindings don't work for me on every platform, and I believe that we should have python bindings working on every platform that ogre works with.

I'll try to keep everyone here posted as I go along, and report my impressions.

I'm willing to put some time and effort into maintaining pyogre. I can't commit to maintaining it completely by myself. However, I'm currently dissappointed at the state of the swig bindings, as I've utterly failed to get them working on Linux(Ubuntu) with the fglrx (ATI) drivers. I know that there are a number of posts on this subject in this forum, and the general consensus is that it just doesn't work. If this has changed with the pyogre 1.2 bindings, then please let me know.


ATI drivers under Linux are generally reported to be buggy.
I would see that being the root of the problems you are experiencing
rather that SWIG itself.
If the cause is in the way bindings are made, may be fixing them would
involve less work then starting over again with boost.
(AFAIR, boost was abandonned for SWIG because of issues as well).

I am not very familiar with pyplusplus, but that looks like a C++ code
generator framework (i.e., optimization hell - and for real-time code
that can have a very significant cost). That could always be worked
out by people who want that outside pyOgre.

I see that the ctypes module is going to be part of the default python
install with the coming version 1.5... that would be pretty handy
(for a minimal interface to Ogre).


As such, I'm investigating the pyplusplus stuff that Roman talked about. However, instead of hijacking this thread, I'll start a new one to discuss how those bindings are going. Please understand that I'm only doing this because the SWIG bindings don't work for me on every platform, and I believe that we should have python bindings working on every platform that ogre works with.


On that line, the current pyogre requirement for psyco forbids the
use of pyOgre on 64 bits platforms.


I'll try to keep everyone here posted as I go along, and report my impressions.

Please do.
I will see if I can spare some time to look what is currently done with SWIG.

I'm willing to put some time and effort into maintaining pyogre. I can't commit to maintaining it completely by myself. However, I'm currently dissappointed at the state of the swig bindings, as I've utterly failed to get them working on Linux(Ubuntu) with the fglrx (ATI) drivers. I know that there are a number of posts on this subject in this forum, and the general consensus is that it just doesn't work. If this has changed with the pyogre 1.2 bindings, then please let me know.


ATI drivers under Linux are generally reported to be buggy.
I would see that being the root of the problems you are experiencing
rather that SWIG itself.

Well, OGRE itself runs fine on my platform. Sure, there are the odd issue here and there with ATI drivers. But it's typically something to do with a particular shader not working correctly, or something being much slower. There are very few crash related bugs with Ogre on a linux and ATI card.


If the cause is in the way bindings are made, may be fixing them would
involve less work then starting over again with boost.
(AFAIR, boost was abandonned for SWIG because of issues as well).


The problem which is encountered when using the current pyogre on my platform is a crash during the window initialization. It never gets to a point where things are displayed. I had given some thought and a fair bit of debugging time to fixing this, but was quickly lost. The crash was in the std::string's ctor, and I couldn't figure out why. My current thoughts are that it might have to do with using two versions of C++'s std library in different dynamically linked objects and passing strings between them. (Similar to the problems experienced with the mingw version of ogre on windows). Although I have no idea how to track it down.

If dermont, clay or fog want to work with me in tracking this issue down, I'd be happy to submit backtraces, and other sorts of information regarding the problems.


I am not very familiar with pyplusplus, but that looks like a C++ code
generator framework (i.e., optimization hell - and for real-time code
that can have a very significant cost). That could always be worked
out by people who want that outside pyOgre.


I'm not terribly familiar with this process. However, since I'm working with Roman (the creator and maintainer of pyplusplus) directly, there is a good chance that things will go well, and problems can be addressed quickly.


I see that the ctypes module is going to be part of the default python
install with the coming version 1.5... that would be pretty handy
(for a minimal interface to Ogre).


As such, I'm investigating the pyplusplus stuff that Roman talked about. However, instead of hijacking this thread, I'll start a new one to discuss how those bindings are going. Please understand that I'm only doing this because the SWIG bindings don't work for me on every platform, and I believe that we should have python bindings working on every platform that ogre works with.


On that line, the current pyogre requirement for psyco forbids the
use of pyOgre on 64 bits platforms.


I'll try to keep everyone here posted as I go along, and report my impressions.

Please do.
I will see if I can spare some time to look what is currently done with SWIG.

I should note that I don't view the SWIG bindings in a bad light. clay, fog and dermont have put alot of work and time and effort into them, and they are great for me on windows. They should be commended for the work they've done and I sincerely hope that they continue with their work.

One of the major reasons I want to do this is to learn about different ways to bind C++ stuff to python. I've tried using SWIG and got frustrated, and tried Pyste and got frustrated. If pyplusplus' rule-based approach works well, it'll be much less of a maintainer's nightmare. This interests me. And because I can't use the current pyogre's bindings on my primary development platform, I have motivation to look at alternative routes.

On a side note, I've gotten this impression for SWIG, maybe someone who is more knowledgeable on them can comment and prove me wrong:
SWIG concentrates on bindings for all sorts of scripting languages. This is a noble goal, and they have done an amazing job, but my gut instinct tells me that this situation results in a less than ideal interface, and resulting code. But I have no proof of that.

Of course, the ideal situation is for the underlying library (in this case Ogre) to have a built-in run-time reflection/introspection mechanism. That is, the library itself is able to enumerate its entire class hierarchy, the methods available for each class, and the types (and ideally acceptable values) of every parameter in every method/function. This might sound like a lot of work for the authors of the library but the pay-off is huge: both in terms of easily writing wrappers for your language of choice, and (de)serialization of objects for storage and network transfer. I believe OpenSG has such an introspection mechanism, and it was recently added to OpenSceneGraph.

A clever colleague at my former employer wrote such a python wrapper around the old SGI Cosmo scenegraph. It was complete, cross-platform and uncrashable - and only possible because the SGI engineers had the reflection mechanism built-in.

A group of these SGI engineers later started a company called Intrinsic with an awesome scenegraph engine called Alchemy. A commercial product for the games world, it was cross-platform for PC (Windows and Linux), XBOX and PS2. Their class hierarchy was described with a lisp-like syntax from which the C++ headers were generated by a pre-compiler. All of the reflection-stuff was generated automagically.

How does boost.python with pyplusplus compare to swig?

I am not SWIG user, so it is very difficult to me to compare pyplusplus + boost.python with SWIG.

As for me the main difference is next:

boost.python is C++ library, that allows you to export C++ code to
Python. It also allows you to embed Python code within C++ one.
I am almost sure, SWIG does not provide this functionality.
You don't have to use a code generator, in order to expose C++ code
to Python. You can get more information here
http://www.boost.org/libs/python/doc/tutorial/doc/html/index.html

pyplusplus is code generator, that allows you to work with the whole project at once. You can create few rules, that will continue to work,
even after C++ code has been changed. pyplusplus generates human
readable code, that uses boost.python to export C++ code to Python.

I hope, that new project, PyOgre using pyplusplus, will show us the
difference between those projects.

Of course, the ideal situation is for the underlying library (in this case Ogre) to have a built-in run-time reflection/introspection mechanism. That is, the library itself is able to enumerate its entire class hierarchy, the methods available for each class, and the types (and ideally acceptable values) of every parameter in every method/function. This might sound like a lot of work for the authors of the library but the pay-off is huge: both in terms of easily writing wrappers for your language of choice, and (de)serialization of objects for storage and network transfer. I believe OpenSG has such an introspection mechanism, and it was recently added to OpenSceneGraph.


There is a project - PyOpenSG.
https://realityforge.vrsource.org/view/PyOpenSG/WebHome.
Allen Bierbaum, the author of the project, choose pyplusplus and
boost.python to create Python bindings for the project.

On a side note, I've gotten this impression for SWIG, maybe someone who is more knowledgeable on them can comment and prove me wrong:
SWIG concentrates on bindings for all sorts of scripting languages.


I cannot pretend of an in-depth knowledge (outside hacking bits and pieces
of already existing swig definitions), but to my understanding this is the
case.


This is a noble goal, and they have done an amazing job, but my gut instinct tells me that this situation results in a less than ideal interface, and resulting code. But I have no proof of that.

In fact, following my last post I looked at what were the other bindings for Ogre.
The idea is to have a common definition for an interface (which would be helpful here, since we are apparently short on ressources).
The ogre-java folks have considered SWIG, but seem to prefer Doxygen:
http://ogre4j.org/drupal/node/85
(however, the project do not seem very active :/)

OgreDotNet is using SWIG
http://www.ogre3d.org/wiki/index.php/In ... OgreDotNet
and is apparently working with Ogre 1.2 (from what I read,
I have not tried).
(there are people with a different approach with .NET, but their
arguments would be the same for any sort of interface building
http://dundee.cs.queensu.ca/wiki/index. ... e_and_.NET
)

Looking at a comparison between boost and SWIG, I found the following
interesting (although it is from 2003):
http://seal.web.cern.ch/seal/SEAL_1_4_0 ... eport.html

Threads like the following one seem to show that there are strong advocates for either SWIG or BoostC++
http://aspn.activestate.com/ASPN/Mail/M ... ig/1811091

To my understanding, the important points are:

BoostC++:
- metaprogramming/introspection/automagic parsing of C++ that lowers
maintainance
- metaprogramming/introspection/automagic parsing of C++ requires
quite some understanding of advanced BoostC++ aspects
- metaprogramming/introspection/automagic parsing of C++ makes it
a debugging hell
(the one of us that ever had to stick their node into code generated by
code-generator frameworks will know what it can be like ).
- python only
- pyplusplus is quite recent and advertised to address the points 2 and 3

SWIG:
- require manual configuration files in many cases (the configuration
files are made to 'explain' headers to the interface builder)
- multiple languages (couldn't something in common be made
with the .NET folks ?... and may be there are a handful of Lua supporters
ready to give a hand as well...


Just my two euro-cents,



RM

The problem which is encountered when using the current pyogre on my platform is a crash during the window initialization. It never gets to a point where things are displayed. I had given some thought and a fair bit of debugging time to fixing this, but was quickly lost. The crash was in the std::string's ctor, and I couldn't figure out why. My current thoughts are that it might have to do with using two versions of C++'s std library in different dynamically linked objects and passing strings between them. (Similar to the problems experienced with the mingw version of ogre on windows). Although I have no idea how to track it down.


We are drifting away from the ATI/SWIG guilty combo...


Did you try using 'ltrace' ?
(or it might just be faster to recompile things against the same version of
the C++ std library ... or if you have a precompiled version of pyogre,
this might be a mismatch between your version of python and the one
it was compiled against. I remember experiencing funky stuff with blender, and it was the cause of it).

- multiple languages (couldn't something in common be made
with the .NET folks ?

It could be done. It was proposed by Clay (in december I think). I followed its idea for my framework: having a common set of interface files (*.i) for each target language, using some #ifdef when the specificities of each target language enters into play. I also have a custom tool that parse the XML file produced by SWIG to generate some target language-specific interface files that automatically rename the classes, methods and public class members according to some rules, and also that add (read-only, write-only, full access) attributes to the target language' classes when a getXXX() and/or a setXXX() method is found.

At generation time, it's a bit longer (3 steps instead of one), but apart for some problematic C++ parts I don't have to write a lot of *.i files.

FIY, the 3 steps are:
- .i (common files, ignore list, custom rename list) -> .xml
- .xml -> target language specific rename list and target language specific attributes list
- .i (common files, ignore list, target language specific rename list, target language specific attributes list) -> wrapper


boost.python [...] also allows you to embed Python code within C++ one.
I am almost sure, SWIG does not provide this functionality.

It's right that SWIG doesn't do it for you, but it isn't hard to do by using the Python library. For example, I can either my applications from a Python script and from C++ and also at the same time execute Python commands from C++ via my Scripting Manager or transparently via SWIG's directors when applicable.

boost.python is C++ library, that allows you to export C++ code to
Python. It also allows you to embed Python code within C++ one.
I am almost sure, SWIG does not provide this functionality. Both Boost.Python and SWIG require you to use the Python/C API to call Python code from C/C++. And with SWIG's director classes Python classes can inherit form C++ classes and override their virtual functions. So the difference in the libraries is not that great.

pyplusplus is code generator, that allows you to work with the whole project at once. You can create few rules, that will continue to work,
even after C++ code has been changed. SWIG also has this feature, it's called typemaps. However typemaps require the person maintaining the bindings to write Python/C API code.

SWIG makes it rather easy to change it's behaviour based on what language it is made to generate bindings for. So it could be possible to use the OgreDotNet effort and simply change it's behavior where it gets language specific.// from some OGRE wrapper definition

#ifdef SWIGCSHARP
// do .NET stuff
#endif
#ifdef SWIGPYTHON
// do Python stuff
#endif

This is a noble goal, and they have done an amazing job, but my gut instinct tells me that this situation results in a less than ideal interface, and resulting code. But I have no proof of that. SWIG takes C++ classes and creates functions so that they can be manipulated from C. e.g. class SomeClass; makes SWIG create the following functions "SomeClass* swig_new_SomeClass()", "void swig_delete_SomeClass(SomeClass*)", ... After that is done the destination language wrappers kick in and create wrappers for these functions. And finally with Python shadow classes enabled, Python code is generated to call these wrapped functions while emulating the C++ classes with Python classes. The slowest parts of this equation are the Python classes, but you are already manipulating C++ classes with Python code so I don't think that it is a major concern.

- require manual configuration files in many cases (the configuration
files are made to 'explain' headers to the interface builder) In many/(most?) cases you can get away with just importing the header into the wrapper definition file, and then only fix what SWIG can't do transparently.

I know SWIG a little and I'm fairly good with C++ so I would be willing to assist with maintaining/developing the existing SWIG wrappers or adapting the OgreDotNet wrappers to Python. But I don't know OGRE well enough to know what needs to be done.

SWIG also has this feature, it's called typemaps. However typemaps require the person maintaining the bindings to write Python/C API code.

I realy don't want to start in this thread technical thread what is better.
( I did not work with SWIG at all ).
But I think you've got me wrong. I will give you an example of rule
I am talking about: Ogre classes have public member functions, that their
name starts with '_'. In general those member functions solve some issues
and should be considered private. Using pyplusplus it is exaclty 1( one ) line of code to exclude all those functions from being exported to Python.

In many/(most?) cases you can get away with just importing the header into the wrapper definition file, and then only fix what SWIG can't do transparently.

From what I undesrtand, right now there is a problem to maintane those
places. In my opinion, using pyplusplus allows to cut maintenance time. I could be wrong. We will find out .

Any way, I think PyOgre users will appriciate any help.

- multiple languages (couldn't something in common be made
with the .NET folks ?

It could be done. It was proposed by Clay (in december I think). I followed its idea for my framework: having a common set of interface files (*.i) for each target language, using some #ifdef when the specificities of each target language enters into play. I also have a custom tool that parse the XML file produced by SWIG to generate some target language-specific interface files that automatically rename the classes, methods and public class members according to some rules, and also that add (read-only, write-only, full access) attributes to the target language' classes when a getXXX() and/or a setXXX() method is found.


Do you know what happened to Clay's proposal ?
(OgreDotNet people were not interested ? Agreement that it was a nice
idea but people had not so much time to work on that ? else ?)

I will look at the SWIG definition for OgreDotNet (since this is working
for Ogre v1.2).
(...it makes me think that I have to learn some more about SWIG on
the way ).

Much of this discussion would be moot if Ogre was able to (self)describe its API via a C++ interface. Why don't we start there? For example, as a proof of concept to the Ogre developers we could try adding reflection/introspection to a small part of the existing Ogre ...

Do you know what happened to Clay's proposal ?
(OgreDotNet people were not interested ? Agreement that it was a nice
idea but people had not so much time to work on that ? else ?)

In http://www.ogre3d.org/phpBB2addons/viewtopic.php?t=147&highlight=, he discusses the idea of merging the two source trees. EagleEye (who was one of the maintainer at this time) dismissed the idea.

In http://www.ogre3d.org/phpBB2addons/viewtopic.php?t=218&highlight=, he speaks about the automatic generation of the %rename commands from the XML file.

I thought he said that he will begin the merge as a proof-of-concept in one of those threads, but it seems that I dreamed that part...

Having something at the level of Ogre itself would be tremendous...

However to my understanding, self-description by introspection would not
be automagic and could serve a python API only (or did I get it
wrong). I do not think that Ogre Core will accept it readily.

(note that the headers themselves contain an exhaustive description
of the API)

One more paper:
http://repositories.cdlib.org/cgi/viewc ... ntext=lbnl

The authors trend to complain about SWIG's complexity...

I am ready to help out and learn, and I guess I would follow the majority.

Sorry for the verbosity, I have been on other projects in the past
- under other nicks - and I think more helpful to make everyone
speak out and see how robust a solution can be against individuals
(.i.e, avoid solo runs as people can be busy periods keeping them away
from the project.... and undiscussed solo runs can be the seed for
forks of the project).

Dermont added me as a developer for the existing bindings so I guess I will be the one administrating that project.
I have branched the trunk into http://svn.berlios.de/svnroot/repos/pyogre/branches/dev-1.2.0/ I have applied Dermont's patches, and I will start off from there.

I am using VS8/VS7.1 so that will probably recieve the most testing. I can't make any promises for the Linux side and I don't have access to, or know anything about development on, Mac OS X.
I will start now by reading over the existing code, see if I get any trouble compiling it, and get a better feel for how it's put together, after that I will start going over the TODO list.

Yep I primarily added you as a developer. You should have the same administration rights that I do. Let me know if there is a problem. Feel free to update your Role/Position and my admin rights as you see fit.

You'll probably need some time through all of this and decide for yourself. If you want I'll try to look after the linux side of things, pyCegui and hopefully contribute to the current bindings.

With regards to the TODO list - let me know if you need more info or if you prefer I raise a bug report with a more detailed report on each item.

Also, the pyOgre site currently has no moderator so I've PM'd sinbad with a request that he install you as moderator.

i would be willing to help with the OS X build, if people point me to the right documentation to compile and install ogre and pyOgre on OS X? has there previously been a pyOgre build running on OS X in that regard?

i'm currently looking into a 3d engine with bindings for python for OS X (mainly at this point in time, but maybe cross platform later) and did have a look at Panda3d. i would like to test Ogre/pyOgre in that regard and willing to compile and test any latest version available.

feel free to send me a PM if you are interested.

cheers,
kaweh

Dermont added me as a developer for the existing bindings so I guess I will be the one administrating that project.
I have branched the trunk into http://svn.berlios.de/svnroot/repos/pyogre/branches/dev-1.2.0/ I have applied Dermont's patches, and I will start off from there.

I am using VS8/VS7.1 so that will probably recieve the most testing. I can't make any promises for the Linux side and I don't have access to, or know anything about development on, Mac OS X.
I will start now by reading over the existing code, see if I get any trouble compiling it, and get a better feel for how it's put together, after that I will start going over the TODO list.

Excellent news and congratulations !

I tried compiling a fresh checkout against Ogre 1.2, but the
python setup.py build dies with the first error below...


creating build
creating build/temp.linux-i686-2.4
creating build/temp.linux-i686-2.4/pyogre
creating build/temp.linux-i686-2.4/pyogre/ogre
gcc -pthread -fno-strict-aliasing -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -fPIC -I/usr/local//include -I/usr/local//include/OGRE -I/usr/include/python2.4 -c pyogre/ogre/ogre_wrap.cxx -o build/temp.linux-i686-2.4/pyogre/ogre/ogre_wrap.o
gcc: : No such file or directory
cc1plus: warning: command line option "-Wstrict-prototypes" is valid for Ada/C/ObjC but not for C++
pyogre/ogre/ogre_wrap.cxx: In function ‘Ogre::TextureUnitState::TextureAddressingMode Ogre_TextureUnitState_textureAddressingMode_get(Ogre::TextureUnitState*)’:
pyogre/ogre/ogre_wrap.cxx:5292: error: invalid cast from type ‘const Ogre::TextureUnitState::UVWAddressingMode’ to type ‘Ogre::TextureUnitState::TextureAddressingMode’


Am I the only one ?

I can't even get that far when I try to compile PyOgre on Linux (Ubuntu - Dapper Drake) and I can only get Ogre to compile against sdl, not glx.

The build_linux.txt file in the docs directory suggests that setup.py doesn't work.

Istari wrote:

The build_linux.txt file in the docs directory suggests that setup.py doesn't work.


It worked OK for version1.0.6, the build_linux.txt file needs to be updated. There is a problem with setup.py and version 1.20 as noted in pyOgreTODO.

http://svn.berlios.de/wsvn/pyogre/branc ... rev=0&sc=0

@Risky.Martin: what version of gcc / swig /distro etc. are you using?. As Istari indicated I'm suprised the build process got so far.

On gentoo (gcc 3.3.5) the steps I took to compile are:

1) Updated setup.py to include EventSystem.cxx:

# build the extensions
ext_ogre = pyogre_Extension("pyogre._ogre",
["pyogre/ogre/ogre.i",
"pyogre/ogre/VertexBufferProxy.cxx",
"pyogre/ogre/IndexBufferProxy.cxx",
"pyogre/ogre/EventSystem.cxx"],
pkg_config_module='OGRE')


2) pyCegui balks at the tuple helpers:

a) in ogre.i add #define _OGREWRAP before ogre_attributes.i / ogre_typemaps.i

#define _OGREWRAP
%include ogre_attributes.i
%include ogre_typemaps.i

b) ogre_typemaps.i wrap the tuple manipulation helpers with:

#ifdef _OGREWRAP
// Manipulation of tuples, TODO wrap as typemap
...
...
#endif


3) Update attributes for:


i) OgreGpuProgram.i
%ogre_attribute(GpuProgram, Ogre::ushort, numberPosesIncluded, getNumberOfPosesIncluded)

ii) OgreFont.i
%ogre_attribute(Font, Ogre::uint, trueTypeResolution,
getTrueTypeResolution, setTrueTypeResolution);


To run issue setup.py build, when it fails copy and paste the command and run from the shell. In addition, for the following step, add an include to pyogre/ogre eg.


i686-pc-linux-gnu-gcc -pthread -fno-strict-aliasing -DNDEBUG -fPIC -I/usr/local/include -I/usr/local/include/OGRE -I/usr/include/python2.4 -Ipyogre/ogre -c pyogre/ogre/ogre_wrap.cxx -o build/temp.linux-i686-2.4/pyogre/ogre/ogre_wrap.o


The remainder of the build and install should be fine. I'll try and look into what the actual problem is.

edit: BTW, on my system, from earlier versions of pyOgre until now I've never been able to get SDL working.

Istari wrote:
@Risky.Martin: what version of gcc / swig /distro etc. are you using?. As Istari indicated I'm suprised the build process got so far.


mmmmhh... in that particular case, I do not remember doing
anything special
Ogre 1.2 (compiled with GLX AFAIR)
Ubuntu 6.06 (Dapper Drake - to be released soon)
gcc (GCC) 4.0.3 (Ubuntu 4.0.3-1ubuntu5)
SWIG Version 1.3.27
Python 2.4.3

I'll have a go at what you suggest (and see if I can make progress).
Thanks.

No I meant that there is a known problem with the current setup.py and pyogre1.2.

Also update your version of swig to 1.3.29. If your still encountering problems I'll try compiling on Debian gcc 4.0.3. Failing that I'll try installing Ubuntu (only as a last resort) and compiling pyOgre there.

No I meant that there is a known problem with the current setup.py and pyogre1.2.

Also update your version of swig to 1.3.29. If your still encountering problems I'll try compiling on Debian gcc 4.0.3. Failing that I'll try installing Ubuntu (only as a last resort) and compiling pyOgre there.

I see that there is an other thread that is becoming more appropriate
for that. I'll have my next post over there
http://www.ogre3d.org/phpBB2addons/viewtopic.php?t=1334

I get the newest version of SWIG 1.3.29, and I did what you suggest (expect modifying OgreFont.i as I could not find it).
I ran python setup.py build, and it died with:


pyogre/ogre/ogre_wrap.cxx: In function ‘Ogre::TextureUnitState::TextureAddressingMode Ogre_TextureUnitState_textureAddressingMode_get(Ogre::TextureUnitState*)’:
pyogre/ogre/ogre_wrap.cxx:6771: error: invalid cast from type ‘const Ogre::TextureUnitState::UVWAddressingMode’ to type ‘Ogre::TextureUnitState::TextureAddressingMode’

blablablabla errors blablbablablabla



When I copy/paste the compilation command (adding -Ipyogre/ogre),
it just died the same way

I finally managed to compile Ogre with glx.
After installing swig 1.3.29 and making a few changes to setup.py and two other files, I can get _ogre.so after issuing the "python setup.py build" command 3 or 4 times.

It seems to halt after each item in the source list for the extension.

The modifications have been committed to the repo.


pyogre/ogre/ogre_wrap.cxx: In function ‘Ogre::TextureUnitState::TextureAddressingMode Ogre_TextureUnitState_textureAddressingMode_get(Ogre::TextureUnitState*)’:
pyogre/ogre/ogre_wrap.cxx:6771: error: invalid cast from type ‘const Ogre::TextureUnitState::UVWAddressingMode’ to type ‘Ogre::TextureUnitState::TextureAddressingMode’

blablablabla errors blablbablablabla



When I copy/paste the compilation command (adding -Ipyogre/ogre),
it just died the same way

This is the same result I get.

By the way, does anyone know how to add -Ipyogre/ogre to the gcc command via setup.py? I tried this:


ext_ogre = pyogre_Extension("pyogre._ogre",
["pyogre/ogre/ogre.i",
"pyogre/ogre/VertexBufferProxy.cxx",
"pyogre/ogre/IndexBufferProxy.cxx",
"pyogre/ogre/EventSystem.cxx"],
pkg_config_module='OGRE',
swig_includes=["-Ipython/ogre"])


but that didn't seem to do it.

By the way, does anyone know how to add -Ipyogre/ogre to the gcc command via setup.py?

Answered my own question


Index: setup.py
===================================================================
--- setup.py (revision 332)
+++ setup.py (working copy)
@@ -169,7 +169,8 @@
ext_ogre = pyogre_Extension("pyogre._ogre",
["pyogre/ogre/ogre.i",
"pyogre/ogre/VertexBufferProxy.cxx",
- "pyogre/ogre/IndexBufferProxy.cxx"],
+ "pyogre/ogre/IndexBufferProxy.cxx",
+ "pyogre/ogre/EventSystem.cxx"],
pkg_config_module='OGRE')

ext_cegui = pyogre_Extension("pyogre._cegui", ["pyogre/cegui/cegui.i"],
@@ -194,4 +195,5 @@
data_files=[],
packages=['pyogre'],
cmdclass={'build': pyogre_build, 'build_ext': pyogre_build_ext},
+ include_dirs = ['pyogre/ogre'],
ext_modules=[ext_ogre, ext_cegui])


I finally managed to compile Ogre with glx.
After installing swig 1.3.29 and making a few changes to setup.py and two other files, I can get _ogre.so after issuing the "python setup.py build" command 3 or 4 times.

It seems to halt after each item in the source list for the extension.

The modifications have been committed to the repo.

Hmm, I'm using the latest from SVN and still not getting anywhere. I have SWIG 1.3.29, Python 2.4, gcc 4.0.2, CEGUI 0.4.1, and OGRE 1.2.0RC1

Hmm, I'm using the latest from SVN and still not getting anywhere. I have SWIG 1.3.29, Python 2.4, gcc 4.0.2, CEGUI 0.4.1, and OGRE 1.2.0RC1

Sorry for the repeated self-replies. I just upgraded to OGRE 1.2 (no RC) and I still have the same problem with the compiler:


gcc -pthread -fno-strict-aliasing -DNDEBUG -fPIC -I/usr/include -I/usr/include/OGRE -I/usr/include/python2.4 -Ipyogre/ogre -c pyogre/ogre/ogre_wrap.cxx -o build/temp.linux-i686-2.4/pyogre/ogre/ogre_wrap.o
pyogre/ogre/ogre_wrap.cxx: In function ‘Ogre::TextureUnitState::TextureAddressingMode Ogre_TextureUnitState_textureAddressingMode_get(Ogre::TextureUnitState*)’:pyogre/ogre/ogre_wrap.cxx:6770: error: invalid cast from type ‘const Ogre::TextureUnitState::UVWAddressingMode’ to type ‘Ogre::TextureUnitState::TextureAddressingMode’
etc, etc, etc


Hmm, I'm using the latest from SVN and still not getting anywhere. I have SWIG 1.3.29, Python 2.4, gcc 4.0.2, CEGUI 0.4.1, and OGRE 1.2.0RC1

Sorry for the repeated self-replies. I just upgraded to OGRE 1.2 (no RC) and I still have the same problem with the compiler:


gcc -pthread -fno-strict-aliasing -DNDEBUG -fPIC -I/usr/include -I/usr/include/OGRE -I/usr/include/python2.4 -Ipyogre/ogre -c pyogre/ogre/ogre_wrap.cxx -o build/temp.linux-i686-2.4/pyogre/ogre/ogre_wrap.o
pyogre/ogre/ogre_wrap.cxx: In function ‘Ogre::TextureUnitState::TextureAddressingMode Ogre_TextureUnitState_textureAddressingMode_get(Ogre::TextureUnitState*)’:pyogre/ogre/ogre_wrap.cxx:6770: error: invalid cast from type ‘const Ogre::TextureUnitState::UVWAddressingMode’ to type ‘Ogre::TextureUnitState::TextureAddressingMode’
etc, etc, etc


I used to get that, but eventually get it to compile
after recompiling CEGUI and OGRE 1.2
(note that the python setup.py build dies several times,
and that stubbornly gets one to go through the compilation).

The compilation being not-so-clean, I tried to look into things...
and simplifying setup.py appeared like a first good step.
Well, here is a warning to others: distutils is seemingly quite
unfriendly (read 'buggy') to the combo SWIG/C++ (and clay/fog deserve quite
some respect for making it somehow work). Moreover, there does not
seem to be much effort in fixing distutils.

The new kid on the block for python packages installation
is apparently 'setuptools' (likely to be distributed with python 2.5), and
I am currently trying to figure out how to port setup.py for setuptools,
as the following features could be helpful:

1. 
   - building/distributing pre-compiled binary packages (aka 'eggs')
   
   - handling submodules/plugins with their respective dependencies
   (I remember seeing pieces of code for having pyogre and pygtk, or pyogre
   and wxPython... that would nice to have all that centralized).
   [/list:u]
   
   A second step would be to try understanding why the build breaks
   (and cleaning up the numerous warnings from SWIG and compiliing
   the SWIG-generated interface might be necessary).

@mikejedw: I just did a clean checkout of the branches/dev-1.2.0 repo and it, for me at least, compiles. I have:

1. * gcc 4.0.3
   * SWIG 1.3.29
   * Python 2.4.3
   * Ogre 1.2.0[/list:u]Basically a standard Ubuntu 6.06 except for SWIG and Ogre.
   
   I need people to check if exceptions are working correctly, I have made changes to OgreException.i and they should work now. Both for exceptions raised by Ogre and exceptions raised in Python code called by Ogre.

@mikejedw: I just did a clean checkout of the branches/dev-1.2.0 repo and it, for me at least, compiles. I have:

1. * gcc 4.0.3
   * SWIG 1.3.29
   * Python 2.4.3
   * Ogre 1.2.0[/list:u]Basically a standard Ubuntu 6.06 except for SWIG and Ogre.

Aha! Ok, I'm an idiot. I was using trunk instead of branch/dev-1.2.0

I need people to check if exceptions are working correctly, I have made changes to OgreException.i and they should work now. Both for exceptions raised by Ogre and exceptions raised in Python code called by Ogre.

Exceptions don't seem to be working. This is what I get:


File "/usr/lib/python2.4/site-packages/pyogre/ogre.py", line 231, in __init__
this = _ogre.new_Exception(*args)
NotImplementedError: No matching function for overloaded 'new_Exception'


Also, I can't seem to run tutorials beginner_2.py, beginner_4.py, beginner_5.py with ninja.mesh. When I replace it with dragon.mesh, they work fine. It's some kind of problem with softwareVertexBlend, which seems like an Ogre problem more then PyOgre and is probably related to this:

http://www.ogre3d.org/phpBB2/viewtopic.php?t=19686

I need people to check if exceptions are working correctly, I have made changes to OgreException.i and they should work now. Both for exceptions raised by Ogre and exceptions raised in Python code called by Ogre.

I had a working build of PyOgre just before you fixed the exceptions, and everything is still working perfectly. All the exceptions are printed cleanly in python, and nothing crashes anymore.

Nicely done!

Alex

@mikejedw: Are you trying to instantiate an Ogre Exception?

The exception constructor is ignored because OgreException is intended to allow Python code to catch exceptions, not raise them.
Any Python exception will do for director classes, so OgreException isn't needed there.

@mikejedw: Are you trying to instantiate an Ogre Exception?

The exception constructor is ignored because OgreException is intended to allow Python code to catch exceptions, not raise them.
Any Python exception will do for director classes, so OgreException isn't needed there.

It actually appeared in the context of this Tutorial:
http://www.ogre3d.org/wiki/index.php/PyOgre_Tutorial3

so that code may be out of date. Would it be more appropriate to just raise a regular Python exception in that case?

I looked again and it seems I was wrong, it is possible to instantiate Ogre Exceptions. However they only accept two parameters, not three. So the code is outdated.

I can't see a reason to use Ogre's exception classes for exceptions that are raised and handled inside Python.

That's the problem I believe not all exceptions are handled/raised in Ogre/pyOgre. Surely using Ogre's Exception class allows localisation of such errors. The probable problem in this case is Sampleframework's showDebugOverlay:
raise ogre.Exception(111, "Could not find overlay Core/DebugOverlay") #, "SampleFramework.py")

which indicates clearly that that the media isn't being correctly picked up by resources.cfg. I would have thought the more exception checking the better.

Try running a demo and pressing the Left arrow key and Right Mouse Button at the same time. This happened in previous versions so I don't think it is due to the 5000+ compile warnings in VC2005:

pyogre\ogre\ogre_wrap.cxx(175912) : warning C4101: 'e' : unreferenced local variable

When this exception in showDebugOverlay is raised in SampleFramework the call stack will look something like this: __main__
SampleFramework.Application.go
SampleFramework.Application._setUp
SampleFramework.Application._createFrameListener
SampleFramework.FrameListener.showDebugOverlay <- exception is thrown hereAt no point does this particular call stack go through PyOgre, so here a native Python Exception will do fine.

Swig will allow any exception in director methods, but seems to mess up the traceback a bit. Perhaps I can take a better look at this.

The unreferenced variable 'e' is because of the changed exception handling code.catch (Swig::DirectorException &e) { SWIG_fail; }
It could probably be fixed by something like this.catch (Swig::DirectorException &e) {
if (&e == &e) // to make VC++ shut up
SWIG_fail;
}Or a #pragma to ignore this particular warning.

The bug you are talking about seems to happen when Camera::yaw or Camera::pitch are called with a floating point value instead of an Ogre::Degree or Ogre::Radian
These methods do not raise exceptions so that would explain why they die without an explanation. Perhaps there is a buggy typemap at work here. The solution would then be in ogre_typemaps.i

Boost has a wonderful static typing constraints system. Fails compile if the type isn't exactly what you want, among other things.
Really only used in templated things though...

Istari wrote:

When this exception in showDebugOverlay is raised in SampleFramework the call stack will look something like this:
Code:
__main__
SampleFramework.Application.go
SampleFramework.Application._setUp
SampleFramework.Application._createFrameListener
SampleFramework.FrameListener.showDebugOverlay <- exception is thrown here

Ok a native Python Exception here would probably suffice.

Istari wrote:

Swig will allow any exception in director methods, but seems to mess up the traceback a bit. Perhaps I can take a better look at this.

The unreferenced variable 'e' is because of the changed exception handling code.
Code:
catch (Swig::DirectorException &e) { SWIG_fail; }

Thanks I'm aware of swig's handling of exceptions in directors with the changed exception handling code. That's why I included it in the pyOgreTODO ( taken from the swig manuals). It's the VC 2005 handling of the unreferenced variable I was unsure about.

Istari wrote:

It could probably be fixed by something like this.
Code:
catch (Swig::DirectorException &e) {
if (&e == &e) // to make VC++ shut up
SWIG_fail;
}
Or a #pragma to ignore this particular warning.

Yep that removes the warnings


Agreed on the Ogre::Degree / Ogre::Radian.

Anyway nice job on resolving the problem with exceptions. Regarding the pyOgreTODO do you have an updated copy of what needs to be done.

Thanks I'm aware of swig's handling of exceptions in directors with the changed exception handling code I know, I was just thinking aloud.

I use the pyOgreTODO in the repository root, because I'm using multiple machines to work on this.

I know, I was just thinking aloud.

No problem

Is anyone else apart from you working on this. If not perhaps it would be an idea to create a sticky so others can volunteer and avoid duplication of effort. I'll start off on stuff that you may not have already begun.

1. 1. Update the cegui demos Horizontal and Vertical Resolution to allow auto scaling. On higher video modes they look really bad.
   
   2. Update the cegui Exception stuff to that of ogre's director handling.
   
   3. Update the MeshViewer.py
   
   4. Update the Composition Stuff
   
   5. create CompositorDemo.py
   
   6. create an ogre addon - easiest one to start of with pyDotSceneOCtree (based on rastamans dotnet version) as a means of testing modularisation of pyOgre. [/list:u]

I know that kaweh was interested in the OS X part, but I haven't heard anything more from him about it so I don't know. I haven't heard from anyone else so I suppose no one else is working on this.

Excellent idea about the sticky, I'll do that.

I'll start off on stuff that you may not have already begun.
Great to hear that, I will be looking more at why Swig truncates the traceback and if I can fix that. After that I'll take a look at the Ogre::Degree typemap.

As such, I'm investigating the pyplusplus stuff that Roman talked about. However, instead of hijacking this thread, I'll start a new one to discuss how those bindings are going. Please understand that I'm only doing this because the SWIG bindings don't work for me on every platform, and I believe that we should have python bindings working on every platform that ogre works with.

I'll try to keep everyone here posted as I go along, and report my impressions.

Rather than hijack this thread, I've posted a new topic to discuss my progress with the pyplusplus bindings.

http://www.ogre3d.org/phpBB2addons/view ... =9505#9505