Tag Archives: Ogre3D

XCode packaging bundles with Ogre using xcconfig files

I have been banging my head against the table trying to port some code from ubuntu to mac os x using both the ogre and openNI libraries. Although I used XCode quite a lot, its never to create gui type applications, and when it has been its been using GTK graphics libraries. So it seems that Ogre requires access to the Cocoa API to run on OS X, much to my original thought that I could get away with not using object-c. In my pursuit I discovered a few useful tricks about XCode that are worth remembering.

Firstly the project setting tool in XCode is perfectly functional but sometimes a bit hard to navigate and lacking in the ability to source control the configuration. There is a more elegant and effective alternative though. Reading this great post it explains how to use xcconfig files, as a text based settings file that you can add comments to, and of course source control. This simplest way to start is to create a new xcconfig file, and literally cmd+c cmd+v from the settings window in to the file. It then translates the settings window parameters in to the variable names. Using this as a base you can configure and specifics yourself. Then when you have your config file ready, open the settings for your target, and in the bottom right there is a small drop down to assign a config file to that target’s build.

It can be as simple as this

//
//  Shared.xcconfig
//  OgreCocoa
//
//  Created by AstroBoy on 22/04/2012.
//  Copyright 2012 __MyCompanyName__. All rights reserved.
//
 
ARCHS = $(ARCHS_STANDARD_32_64_BIT)
SDKROOT = macosx10.6
ONLY_ACTIVE_ARCH = YES
 
PREBINDING = NO
 
HEADER_SEARCH_PATHS = /opt/local/include/ /usr/include/ni /usr/include/nite /OgreSDK/Dependencies/include
LIBRARY_SEARCH_PATHS = /usr/lib /opt/local/lib/ /OgreSDK/Dependencies/lib/Release
 
GCC_OPTIMIZATION_LEVEL = 0
GCC_C_LANGUAGE_STANDARD = gnu99
GCC_WARN_ABOUT_RETURN_TYPE = YES
GCC_WARN_UNUSED_VARIABLE = YES

The second thing I noticed is that there is a naming conflict between openframeworks and ogre3d. Openframeworks provided a good easy way to install the openNI libraries with an ofaddon, but it was cheating a little bit. So I have just used to installed openNI drivers from openNI.

Finally whilst trying to ignore objective-c and use normal c/c++ I tried to link to the Ogre library files without using the framework provided by the ogre sdk, I came up against rpath(unix) issues, or LD_DYLIB_INSTALL_NAME(Xcode). rpath is a parameter applied to a library at compilation then determines where the library can be found during execution. So for example, this works well with the XCode bundle system where you can place your libraries in the ../Plugins folder. This means the system LD_LIBRARY_PATH does not need to be set to the location of the libraries, because when you compile the main executable against the library it will know where to look during execution. Of course, this works when you set it during compilation of the library, and realise you needed to do so. If you are unsure of where an executable is going to look for its dependencies you can use ldd(unix) or otool(mac) on the file to display the search paths (see a previous post). Anyway, if for any reason you want to set this in XCode, there is a setting called D_DYLIB_INSTALL_NAME, which should be set to something like @executable_path/../Plugins/libx.dylib, if you are going to place libx.dylib in the plugins folder of the bundled. Also make sure you place this library in a copy build phase within XCode.

Next time I should finally have a working example of openNI working with Ogre3D through XCode as a distributable application.

 

 

Ogre3D Mac OS X SDK Build

I might be using Ogre3D as a rendering tool for a kinect project. Ive used it on windows and linux a couple of years ago but not mac os x 10.6.8. Here is how to build from source with XCode.

  1. Download 1.7.4 source for linux/os x and dependancies http://www.ogre3d.org/download/source
  2. Follow ogre_src_v1-7-4/BuildingOgre.txt. The pre-built dependancies were enough for me.
  3. Open Ogre xcode project created by cmake in the new build directory
  4. I noticed in one of the cmake file I looked at “# CMake 2.8.2 has a bug that creates unusable Xcode projects when using ARCHS_STANDARD_32_BIT” … so make sure make only for 64 bit.
  5. If not all the targets build in one go, then build them individually starting with ogre main.
  6. The samples are built as libraries kept in lib, and the demo application is in bin.

see….!