PyOgre on Mac OS X
Is it just me or does compiling pyogre on mac os x require a link to the source code? When I compiled everything last night I had to add a couple steps to the process, so I figured that I'd post it here in case anyone else runs into the same situations.
When compiling ogre in xcode, even after adding the required frameworks to /Library/Frameworks and making sure the framework packages in xcode were pointing to the appropriate place I still had SDL compilation errors (some of the constants were determined to be out of scope). I posted this problem in the Help forum and Sinbad suggested I update SDL. Trying again using the latest SDL framework yielded the same result. Only adding /Library/Frameworks; /System/Library/Frameworks; ~/Library/Frameworks to the framework search path in the project settings finally allowed the compiling to succeed. The root cause of this, I'm still not sure; but it would seem to me that if the proper directories were pointed to for each specific framework that this shouldn't have happened. Anyway, Ogre.framework compiled and I copied it to /Library/Frameworks.
Following the instructions in the Mac os build README in the pyogre src (downloaded from trunk at berlios) the build also failed and complained about not finding OgreSystemFile.h. Looking in the ogre.framework, there is no OgreSystemFile.h, but it does exist in the OgreMain src. Including the path to the Ogre src fixed this problem. Next, as jacknutting has stated in other threads; the installation requires libng, which is not stated anywhere that it's needed. For now removing the -framework libpng fixes this; though as jack said, this will likely cause problems with png files. Finally an _ogre.so and ogre.py are generated properly. These were then moved to a pyogre directory I created in my site-packages directory in my Python 2.4 installation. This allowed the importing of python into either the interpreter or a source file.
Reading the remainder of the pyogre mac osx readme, it says that the cocoa appkit isn't used for handling windows at this time, and therefore makes it impossible to run any of the samples. Is anyone working on a solution to this, or should I start poking around?
Nobody is working on it yet. I'd be happy to try and get this figured out. I'm new to Mac development, but I'll do whatever I can to help. Jacknutting said that when he gets out from under a pile of work he might jump in too. So if we all put in some time, I'll bet we can get it working.
I got it all built, but as you said, the samples fail to run. I tried using py2app to see if that would magically help but it didn't.
That's kinda what I had gathered. I have a little bit of cocoa experience, and am working on gaining more. The majority of my programming experience is C/C++ java c# and python... objective-c is a little lax in my mind at the moment. Surely between those of us that are able to do a little here and there, some progress can be made. Once I get the chance to investigate a little more, I'll see what I can come up with. Until then, even a point in the right direction of what I should be looking at first would be a good start. Perhaps fog or clay have some insight into a good starting point?
Hmmm. I really wish I had a mac to try this myself. If you found some parts of the mac os x readme that need updating would you mind making the changes and submitting them on the bug/patch tracker? I'm thinking about moving all build notes to the wiki so that the community can change it as needed. I'll try to get that done tomorrow.
As far as none of the examples working.... PyOgre uses Ogre's underlying windowing code. If the Ogre demos work, then PyOgre's demos should work, but I don't have a mac to test on personally. Do the Ogre demos work at all, and if not do they give the same error message?
I'm not sure about a starting point without knowing what's wrong with the demos.... What kind of error messages do you get from running a pyogre demo?
By the way, does anyone know how good the Mac Mini's graphics card is? I'm not looking for something to rival my desktop, but is a Mac Mini at least enough to run the basic demos so that I can test it if I need to?
The following is the system output while attempting to run the Terrain Demo. This error is in fact mentioned in the readme (one of those "good luck getting this to work" errors). Without the primary developers having a mac for testing, this type of result is understandable. I'll post here my progress running the general ogre samples, and any progress with pyogre in the process.
Creating resource group General
Registering ResourceManager for type Material
Registering ResourceManager for type Mesh
Registering ResourceManager for type Skeleton
Loading library OgrePlatform.bundle
OverlayElementFactory for type Panel registered.
OverlayElementFactory for type BorderPanel registered.
OverlayElementFactory for type TextArea registered.
Registering ResourceManager for type Font
ArchiveFactory for archive type FileSystem registered.
ArchiveFactory for archive type Zip registered.
DevIL version: Developer's Image Library (DevIL) 1.6.5
DevIL image formats: bmp dib cut dcx dds gif ico cur jpg jpe jpeg lif mdl mng jng pcx pic pix png pbm pgm pnm ppm psd pdd psp pxr sgi bw rgb rgba tga vda icb vst tif tiff wal xpm raw
Registering ResourceManager for type HighLevelGpuProgram
Loading library .RenderSystem_GL
/Users/adam/Projects/ogrenew/Mac/XCode/Ogre/../../../OgreMain/src/OgreDynLib.cpp(82): ogre error 9: Could not load dynamic library .RenderSystem_GL. System Error: Unknown Error
This is what I get when I run the Terrain Demo from xcode (regular ogre.. not the py variety pack)
Texture: spot_shadow_fade.png: Loading 1 faces(PF_R8G8B8,128x128x1) with 5 hardware generated mipmaps from Image. Internal format is PF_X8R8G8B8,128x128x1.
Fatal signal: Segmentation Fault (SDL Parachute Deployed)
Terrain has exited with status 245.
From what I remember from the other forums, is that this issue has been seen before; though I don't remember the exact cause or if there was a solution.
Edit: Actually, this could have something to do with the lack of libpng.framework. I'll try that and see what happens.
I installed libpng3 via Fink/FinkCommander and the Ogre Samples work just fine. Attempting to run the pyogre samples failed in the same manner. I believe this is due to the fact that I compiled pyogre without the -framework libpng option (as have other people). I'm going to recompile pyogre with libpng and try again. If it turns out that this was really the only issue, an update to the Mac OS X README is all that would need to be done. If it doesn't work... welcome to the potentially long road ahead of cocoa programming.
I'm betting the error is occurring because of the lack of libpng though... stay tuned.
Ok thanks for the update =)
@Clay: I develop on a Mac Mini, so it's definitely enough to do testing with. It's not a monster, but it has a decent ATI card in it. For $500 it's a great investment. (Add $50 for a KVM switch and you can share your PC's monitor, mouse, and keyboard. Ok, also tack on $100 for the 512MB memory upgrade, but still it's a deal.)
@illza: I hope the only thing wrong is the libpng factor. That would be fantastic. If I get some time in the next couple days I'll try some experiments, too, and report here.
I got pyogre to install with libpng. To do that I had to include the path to the libpng framework in devIL -> IL.framework. However, the demos fail in much the same manner. I'm looking at more of the source code for ogre now to see if I can find anything. In Dynlib::load it makes reference to how dlopen works on linux, as in not appending .so to the library name. I'm wondering if it operates the same way on a mac. I would imagine that this is called no matter what platform you run on though, and since the samples from ogre work on my mac, I wonder what the difference is. Since python tries to load the library from site-packes, do you think it's possible that python on mac also needs the .so appended to the library? Sometime I'm going to try that to see what happens, unless anyone can come up with a reason that I shouldn't.
Edit: nope... that's not it. Doing it this way messes up the dynamic loading of any .bundle that mac uses. (still poking around).
Will Thimbleby has been making some really good progress on the Ogre frameworks for Mac OS X and Xcode over here:
. ... 53&start=0
Some of us have been helping out with either moral support or testing and validation. For instance, we've also got a nice drop-in Xcode project template based on Will's OgreTest as a stub app. It's a good beginning. Note that Will's changes are not yet patched into CVS, but I am hoping they are soon.
Of course, I'd really love to see PyOgre compile and work on Mac OS X. The abililty to write Ogre applications on a Mac with PyOgre and PyObjC has a pretty huge value.
I've checked out the latest SVN from http://svn.berlios.de/svnroot/repos/pyogre/trunk
and followed the instructions in docs/build_macosx.txt. Not much love there, unfortunately.
FWIW, I am thinking PyOgre should take into account the latest dev tools on Mac OS X 10.4.4 (Tiger) which means gcc 4.0 rather than gcc 3.3. Also, even though Tiger ships with Python 2.3; I am guessing we really want to be using Python 2.4, which is an easy install with DarwinPorts, for example. PyObjc is also easy to install from source for Python 2.4, rather than the installer packages for 2.3. (Blender runs on 2.4 as well.)
Can someone involved point me in the right direction? I'd like to get this off the ground again and am willing to take a stab at it. I am a C++ newbie, but am competent with Python and have good general purpose hacking skills.
Obviously I need to get familiar with SWIG and C++, which I am happy to do. I am guessing there may be differences in Will's changes to the Ogre headers that must be reflected in pyogre/ogre/ogre.i?
I need to get going to work; but if there is some interest and feedback on this, I can update with how I am trying to build and what errors I am getting.
Something to think about:
I was chatting with Bill Bumgarner and we came to the realization that probably the best way to go about getting a functional "PyOgre" on Mac OS X might not be with SWIG.
The thing to do might be to create ObjectiveC wrappers for all the Ogre C++ classes. This would be conceptually similar to Coin3d's Sc21.
In this way, at least as far as OS X is concerned, we get two API's for the price of one.
We'll have ObjectiveC wrappers for Ogre. Then by virtue of the PyObjC bridge, we'll get Python bindings to the ObjectiveC wrappers for free.
I realize this his a lot of work and it ignores the SWIG effort. Also, there's a lot of C++ classes for Ogre and they would all have to be wrapped and maintained manually.
But the benefits would be worth it, I think: ObjectiveC and Python Ogre APIs for Mac OS X that are integrated pretty transparently.
What's wrong with SWIG?
I'm not sure what the implications are of using ObjectiveC (I have very little knowledge of it or how it fits into development on the Mac), but it seems that splitting efforts and requiring maintenance of two separate projects is a waste of resources. It makes sense to me to leverage PyOgre's maturity and previous effort rather than fragment things into totally separate projects and possibly wait many months for the ObjC binding to catch up. I plan to do some work with SWIG on the Mac eventually if nobody else gets to it before I can. It's very close to working right now.
Either way, good luck! Python + Ogre = Power.
Well, nothing's wrong with SWIG, except that it's not exactly working for PyOgre on OS X right now. And that can be fixed for sure.
FYI, Objective C is the foundation of Cocoa, Apple's collection of frameworks and APIs along with Carbon that form the basis for developing native applications on OS X. That means, if you want to write a native app for OS X, you're going to write it in Objective C.
Since Mac OS X 10.1, the Mac version of GCC has had support for Objective C++, which allows intermixing Objective C and C++ code. It's this feature that makes writing Objective C wrappers for C++ a fairly simple proposition.
This is relevant to the current discussion because, as far as I know, SWIG does not generate bindings for Objective C. One could argue, if you can just intermix Objective C and C++, why bother with wrappers? I guess I would say if you really want to intermix, knock yourself out. I'd rather have a pure Objective C interface any day.
I think that Objective C wrappers are intrinsically valuable because you get another language that you can code an Ogre application in. And you just happen to get Python APIs for *free* via PyObjC.
At the same time, I totally hear you. SWIG certainly has it's place in Ogre especially for Linux and Windows. And I am defintely not suggesting anybody dump SWIG. What I am saying is that the wrapped C++/PyObjC method also has value and is *possibly* a better way to implement Python operability for Ogre on Mac OS X, mainly because the Python Objective C bridge is pretty wicked. That is, you are getting a lot more out of PyObjC than just Python bindings. You are getting reams of interoperability with Cocoa, like Cocoa Bindings and Core Data.
This is not to say that PyOgre from SWIG and PyObjC cannot exist side by side; because they certainly can. I am just suggesting that if the Ogre code were wrapped in Objective C classes, the integration of Ogre with Cocoa would be that much tighter and the consequent operability via PyObjC would be that much greater.
The introduction to PyObjC here is pretty illuminating: http://pyobjc.sourceforge.net/doc/intro.php
I mean, if the SWIG bindings on OS X are brought up to date and they work, I can get beind that. But I can also get behind Ogre Objective C wrappers and PyObjC. To me, one way of looking at this is to determine the most efficient way to manage and maintain Ogre code, which SWIG represents. Another way of looking at this is to determine what makes Ogre most accessible to the widest audience, while not compomising quality. Seeing as Ogre and PyOgre on OS X is in need of some attention, which it is now getting more of, I think that options and flexibility are good things.
...one way of looking at this is to determine the most efficient way to manage and maintain Ogre code, which SWIG represents. Another way of looking at this is to determine what makes Ogre most accessible to the widest audience, while not compomising quality.
That's really my main concern, since it's already difficult to keep one project alive. I'd just hate to see a lot of effort spent on both projects and then one fade away, leaving those relying on that missing project to find another route. It seems easier to maintain both/all platforms from a single source so that in the event of a maintainer disappearing (where has Clay gone, btw?) someone else can easily support all platforms involved.
That said, PyObjC sounds good for native Mac development. I'm not knocking that in and of itself.
But IMHO the ability to keep a project alive is the most important factor, and splitting it into separate branches adds risk to that.
Just my $.02. Any effort (whatever form it takes) to get PyOgre running on Mac is a good thing!
If the SWIG bindings get working os OS X then you can write you app in pure python and PyOgre and have a cross platform application. If were to use a special set of incompatible Mac bindings for your project your code we become un-protable. I think the level of integration with the OS would be cool, but the bindings you want to create don't sound like PyOgre. They sound like PyObjCOgre. Which is both a good and bad thing.
That's a very good point.
Offhand, I would say again that both methods have value and it depends on what type of application you want to write.
If you want something highly portable, then you will certainly want to use the SWIG bindings; and you'll have to accept that your application will be a bit odd, at least from the Mac OS X Human Interface Guidelines perspective.
Take Blender as an example. It's *highly* portable. But it's interface is totally not Mac OS X HI compliant. I don't think it complies with any interface guidelines but it's own, actually, because it's so specialized. There's nothing wrong with that; it's just the compromise for making Blender portable. Hail Blender!
On the other hand, if you want your app to be a really good Mac citizen with HI Guideline conformance, then wrapped Objective C Ogre with PyObjC (PyObjCOgre as you coin it), would be the way to go.
Personally, I look forward to being able to write a PyObjCOgre application, if this idea comes to fruition. I like the idea of writing a pure Mac application in Python using XCode and Interface Builder, Cocoa Bindings and Core Data.
Well you could use wxPython and PyOgre and that would be a proper Mac citizen and confirm to the applic HI guildines.
And if you're talking about games, most of those don't use the native interface anyway.
As far as the HI guidelines are concerned, yeah, the toolkit does not have to be an issue. I was just using Blender as an example of portability at the sacrifice of a consistent interface across applications on a given platform.
Games, of course, have highly customized interfaces; so the HI guidelines don't necessarily apply.
But that's all beside the point.
I could use wxPython, but I don't necessarily want to learn or use another GUI toolkit. I don't think that's unreasonable either. For the sake of argument, say that I don't care about being cross-platform. Say I just want to write a Cocoa app (game or not), I want to use Ogre and I don't want to write it in C++ and I want more than what the SWIG generated Python bindings give me, because I'm a Mac developer and I'm spoiled.
That's the beauty of PyObjC. It allows me to write a Cocoa app in Python rather than Objective C; because it's integrated with the Apple development environment in ways that SWIG bindings or wxPython cannot even approach, to be frank.
All I am proposing is the ability to write an Ogre based Cocoa app in Objective C. Then the ability to write an Ogre based Cocoa app in Python is the bonus because PyObjC comes for free when you have an API in Objective C.
So it does occur to me that this idea really does not belong on this thread anymore, because I recognize that what I am really proposing is and Objective C interface to Ogre. However, since the end result via PyObjC could be a free Python API, I thought the Mac developers in the PyOgre realm would interested. That's all.
Go for it!
As I said before, any form of PyOgre on Mac is a good thing.
Sorry to resurrect such an old thread, but I didn't see the point in starting a new one.
Has there been any progress on getting PyOgre to work on Mac OS X? PyOgre seems like the ideal tool for what I want to accomplish, but I need Mac support.