Compiling and installing the OpenSceneGraph

The scene graph depends upon Standard C++, STL and OpenGL so you need a C++ compiler up to the task and OpenGL or Mesa installed. The viewer depends upon GLUT which you'll need to download and install from the GLUT website. The OSG has it own native ascii file format, and .rgb image reader inbuilt which allows you read the example data with any dependencies other than C++, STL and OpenGL.

The osgText library adds the dependency of the freetype library for support of true type fonts, however it is not essential to the core library, so you can comment it out from compilation by modifying the src/Makefile, and src/Demos/Makefile. I you wish to use fonts then you can download freetype from www.freetype.org. The osgText library also requires an up to date GLU implementation which supports GLU1.2 tessellation routines. If you your current GLU is out of date you'll need to download the latest, for instance the sgi's sample implementation for GLU from the www.opengl.org website.

The OSG also has a set of plug-ins which support non-native 3d database and image formats, several have no dependencies on external libraries (flt,3ds,obj, lwo,dw, tga & pic), while others (pfb,jpeg,gif,tiff) require other libraries to be installed to compile them. If you don't already have them installed then don't worry, you'll still be able to use the OSG, just comment out the plugins you can't compile from the src/osgPlugins/Makefile. The core osg library and viewer has been designed to load the plug-ins at run-time only and if they are required to load a specific data set. If you don't need them for your datasets then it won't matter that you haven't been able to compile all the plug-ins. A full list of dependencies and where to download the required libraries are listed in the dependencies.html

If you're coming across the OSG for the first time and want to get started quickly, go right ahead and follow the compilation instructions. You can always later download the libraries which the plug-ins require if you eventually need them.

• Compiling under Windows with Visual Studio


• Compiling under Unix (including Mac OSX and Cygwin)



Building the OSG requires 'gmake', due to the extensive use of gmake directives in the Makefiles. You can get gmake from here if you don't already have it installed: http://www.gnu.org/software/make/

Almost all of the unix compling is done simply with make; make install with make help to bring up help. For platform specific details:

• Cygwin
• Linux
• Free BSD
• Mac OSX
• IRIX
• Solaris

Compiling under Windows with Visual Studio.

The Microsoft Visual C++ 6.0 workspace file is VisualStudio.dsw located in the VisualStudio below the OSG this root directory. The OSG will compile with the basic VisualC++6.0, but, and this is a big but, the STL version which comes with VisualC++6.0 is extremely buggy and unable to handle things even as simple as std::mamp without crashing, even the latest severice packs (which are recommended won't fix the STL bugs). This is a problem for the OpenSceneGraph since it makes proper use of Standard C++. One can struggle on with the MS's and expect crashes and optimization disabled, or adopt one of the follwing:

1. Visual Studio .NET
2. Dinkumware's STL bug fix patches - http://www.dinkumware.com/vc_fixes.html.
3. STLport - http://www.stlport.org

The OSG is composed of a number of scene graph libraries (with Core in front of the project names), executables (with Demos in front of the project names), and plugins which read and write 3D data formats and 2D image formats. To get the OSG running you'll need at least to compile Core osg,osgUtil,osgDB,osgGLUT, osgPlugin dot_osg and Demo sgv. The rest of the libraries and executables are optional and can be compiled if you need them, however for simplicity I would recommend doing a batch build of all the libraries and executables in the distribution, some of the plug-ins which support non native file formats may not compile due to dependencies on other libraries (such as libpng), you can ignore these compilation errors unless you need to load the related file types. To help the compilationon the plugins, osgGLUT and osgText one can download .zip archive will all the dependancies in it. Further details on this .zip file can be found in dependencies.html

To execute the viewer the file path for the .dll's and .exe, both compiled into the OSG's bin directory, need to be setup, such as by adding the PATH to your autoexec.bat, its also useful to add the OSGFILEPATH to your autoexec.bat to help the location of datafiles. For example :

SET OSGFILEPATH=D:\OpenSceneGraph-Data;D:\OpenSceneGraph-Data\Images

To help compilation of the image reader plugins, various image libraries have been zipped up for your convienice, your find these on the OSG release download directory.

Using Visual Studio .NET

Looks like Microsoft have eventually got their act together on the compiler front, the compiler looks Standard C++ compilient with a solid STL implement, so this is the recommend route.

Using Dinkumware STL

The basic jist is that you'll need to download their STL implementation, and follow their instructions of how toforce VisualStudio to pick up the new STL implementation. More details at http://www.dinkumware.com/vc_fixes.html.

Once it is installed everything should compile fine and not crash, but you won't be running at full speed since the build #odef's out some important state optimizations since the basic VisualStudio can't handle it. You can safely remove the #ifdef from src/osgUtil/Otimizer.cpp, Line 44. The #ifdef is smart enough to do this automatically when using VIsualStudio .NET and STLport so that modification by hand won't be required. Unfortunately there doesn't seem to be a special define associated with the Dinkumware STL for the #ifdef to pick up on.

Using STLport

Compiling under Linux

% make

% make install

% make instlinks

% make help

The osgText library now depends upon GLU1.3 functionality, and only the recent Mesa version have this as stanadard. Unfortnately not all Linux distribtions are upto date even recent ones. If you have problems compiling osgText due to GLU problems then check out the details at the bottom of this file, under the title RedHat7.1 & GLU1.3 for a quick way of installing GLU1.3 in the right place.

RedHat 7.2 & GLU1.3

English

1) Untar the tarball. It will create a directory called fixosg/
2) Change to the ReadHat7.2_fixglu/ directory
3) Become root
4) Run the script called fixglu

tar xvzf ReadHat7.2_fixglu.tar.gz
cd ReadHat7.2_fixglu/
su (your root password)
./fixglu
exit

Compiling under FreeBSD

% make

% make install

% make instlinks

% make help

Compiling under IRIX

Compile, from the OSG root directory, ('%' is UNIX csh prompt) type:

% make

% make install

% make instlinks

% make help

Compiling under Solaris

% make

% make install

% make instlinks

% make help

Compiling under MacOS X (instructions written by Phil Atkin)

You need to have installed the Developer tools from the CD that comes for free with OS X. This gives you compilers, headers, frameworks - stuff like GLUT and Carbon for developers.

Everything is done command-line, so you need to get to the underlying OS rather than the Aqua gloss. The Mac comes with an app in Applications/Utilities called Terminal - open up any Finder window (e.g double-click on your hard disk icon), click on the Applications icon at the top right of the window, then click on the Utilities folder to get access to all the grubby apps which give away the real OS roots underneath the shiny paintwork. Anyone developing will need Terminal so much they should put it in their Dock. You do that by grabbing the icon of the app in the Utilities folder and dragging it to the bottom of your screen, at which point the other app icons in the Dock slide away to leave a gap which when you release the mouse button leaves Terminal permanently available, just a mouse click away on your desktop. When you start Terminal it brings you up a csh running under Darwin (which is the BSD-with-knobs-on that underlies OS X), and does a cd to ~ (otherwise /Users/username of whoever you are logged in as, as far as the Finder in OS X is concerned you are in the Users/username folder of the harddisk the machine booted from).

Then you are in Unix land, and it's all very familiar.

You will need a .cshrc file with $OSGHOME (as above), and this is a filename that the Mac won't let you see from the Finder or in fact generate from an app, so I used vi to create that. Then I just went

cd $OSGHOME

% make clean
% make macosx

And it sounds too good to be true but it is that simple. It's worth doing some editing on the Makefiles in the Plugins and Demos directories so that it only tries to build a subset, otherwise the developer will have to dig out the support projects like jpeg etc. I have only built up to now sgv, hangglide, osgcube, osgreflect, osgviews and in the Plugins have built osg rgb 3ds and a couple others - will check and get back to you.

Tricky bit :

Installing the libdl.a is more trouble, as you have to enable the root account on the machine, which by default is switched off as the machines ship for security reasons. Rather than typing in and risking error through paraphrase, here is a link to a site which tells you how to do this -

http://www.macos.utah.edu/Documentation/macosx/security/enablerootuser.html

http://www.thinkmacintosh.com/osxfaq.html

One you have a root account enabled, you have to su root you cd to the directory which the Fink installer generates, and it puts libdl.a and the associated .h files in sensible system places so the compiler just finds them.

There is one oddball problem - if you rely on Path to find the resulting executables, a weird Core Graphics error occurs - so even though I set up my path to include $(OSGHOME)/bin, and when I cd to $OSGHOME and type for example hangglide, the application starts fine (so it is in the path), but at the point it tries to use GLUT to open a window it falls over with a CGS error (which is I think Core Graphics System). If you explicitly go bin/hangglide it works fine. Weird, it may be an OS X 10.04 issue which is gone in 10.1 or it may be a weirdy in the Mac GLUT implementation, but forewarned is forearmed.

Compiling under Cygwin

OSGFILEPATH environmental variable

For the OSG to locate file data files easily an environmetal variable OSGFILEPATH is used at run-time by the osgDB library. Note, for examples below substitute in the ${OSGDATA} directory with your own path where appropriate) Add the following to your .cshrc (note paths seperated by colon's): setenv OSGFILEPATH ./:${OSGDATA}:${OSGDATA}/Images Or the following if you're using a sh compatible shell : export OSGFILEPATH=./:${OSGDATA}:${OSGDATA}/Images: Or under windows (note paths seperated by semi-colon's) : SET OSGFILEPATH=./:${OSGDATA};${OSGDATA}/Images

Running the demos