FGFS-4.1/OpenSceneGraph
4
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

Ran the spell checker through the new documentation.

Browse Source
This commit is contained in:
Robert Osfield
2002-04-25 13:26:33 +00:00
parent 23f048884b
commit b5bd42674b
9 changed files with 1021 additions and 849 deletions
Download Patch File Download Diff File Expand all files Collapse all files

332
doc/install.html
View File

@@ -2,54 +2,55 @@
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
<meta name="GENERATOR" content="Mozilla/4.6 [en-gb]C-CCK-MCD NetscapeOnline.co.uk (Win95; I) [Netscape]">
<meta name="GENERATOR" content="Mozilla/4.77 [en] (X11; U; Linux 2.4.3-20mdk i686) [Netscape]">
<title>Installation instructions</title>
</head>
<body text="#000000" bgcolor="#FFFFFF" link="#0000FF" vlink="#990066" alink="#FF0000">
<img SRC="images/OpenSceneGraphBanner_Distribution.jpg" height=77 width=640>
<table>
<tr>
<td><a href="index.html">Index</a> </td>
<td><a href="introduction.html">Introduction</a> </td>
<td><a href="contents.html">Contents</a> </td>
<td><a href="install.html">Install</a> </td>
<td><a href="dependencies.html">Dependencies</a> </td>
<td><a href="demos.html">Demos</a> </td>
<td><a href="data.html">Data</a> </td>
<td><a href="sgv.html">Viewer</a> </td>
<td><a href="stereo.html">Stereo</a> </td>
<td><a href="plan.html">Plan</a> </td>
<td><a href="documentation.html">Reference Guides</a> </td>
</tr>
<tr>
<td><a href="index.html">Index</a></td>
<td><a href="introduction.html">Introduction</a></td>
<td><a href="contents.html">Contents</a></td>
<td><a href="install.html">Install</a></td>
<td><a href="dependencies.html">Dependencies</a></td>
<td><a href="demos.html">Demos</a></td>
<td><a href="data.html">Data</a></td>
<td><a href="sgv.html">Viewer</a></td>
<td><a href="stereo.html">Stereo</a></td>
<td><a href="plan.html">Plan</a></td>
<td><a href="documentation.html">Reference Guides</a></td>
</tr>
</table>
<h2><u>Compiling and installing the OpenSceneGraph</u></h2>
<p>
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.
</p>
<p>
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,
<h2>
<u>Compiling and installing the OpenSceneGraph</u></h2>
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.
<p>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.
</p>
<p>
The OSG also has a set of plug-ins which support non-native 3d database
<p>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 &amp; pic), while others (pfb,jpeg,gif,tiff) require other
libraries to be installed to compile them. If you don't already have them
@@ -60,146 +61,143 @@ 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
<i><a href="dependencies.html">
dependencies.html</a></i>
</p>
<p>
If you're coming across the OSG for the first time and want to get started
<i><a href="dependencies.html">dependencies.html</a></i>
<p>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.
</p>
<ul>
<li><a href="#Compiling under Windows with Visual Studio">Compiling under Windows with Visual Studio</a></li>
<br>
<li>
<a href="#Compiling under Windows with Visual Studio">Compiling under Windows
with Visual Studio</a></li>
<li>Compiling under Unix (including Mac OSX and Cygwin)</li>
<br>
<li>
Compiling under Unix (including Mac OSX and Cygwin)</li>
<p>
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/
</p>
<p>
Almost all of the unix compling is done simply with <b>make; make install</b> with <b>make help</b> to bring up help.
For platform specific details:
</p>
<p><br>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/
<p>Almost all of the unix compiling is done simply with <b>make; make install</b>
with <b>make help</b> to bring up help. For platform specific details:
<ul>
<li><a href="#Cygwin">Cygwin</a></li>
<li><a href="#Linux">Linux</a></li>
<li><a href="#Free BSD">Free BSD</a></li>
<li><a href="#Mac OSX">Mac OSX</a></li>
<li><a href="#IRIX">IRIX</a></li>
<li><a href="#Solaris">Solaris</a></li>
<li>
<a href="#Cygwin">Cygwin</a></li>
<li>
<a href="#Linux">Linux</a></li>
<li>
<a href="#Free BSD">Free BSD</a></li>
<li>
<a href="#Mac OSX">Mac OSX</a></li>
<li>
<a href="#IRIX">IRIX</a></li>
<li>
<a href="#Solaris">Solaris</a></li>
</ul>
</ul>
<hr>
<h3>
<u><a name="Compiling under Windows with Visual Studio">Compiling under Windows with Visual Studio.</a></u></h3>
<p>The Microsoft Visual C++ 6.0 workspace file is VisualStudio.dsw located
<a NAME="Compiling under Windows with Visual Studio"></a><u>Compiling under
Windows with Visual Studio.</u></h3>
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:
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 service 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 following:
<ol>
<li> Visual Studio .NET </li>
<li> Dinkumware's STL bug fix patches - <a href="http://www.dinkumware.com/vc_fixes.html">http://www.dinkumware.com/vc_fixes.html</a>.</li>
<li> STLport - <a href="http://www.stlport.org">http://www.stlport.org</a></li>
<li>
Visual Studio .NET</li>
<li>
Dinkumware's STL bug fix patches - <a href="http://www.dinkumware.com/vc_fixes.html">http://www.dinkumware.com/vc_fixes.html</a>.</li>
<li>
STLport - <a href="http://www.stlport.org">http://www.stlport.org</a></li>
</ol>
</p>
<p>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 <i><a href="dependencies.html">dependencies.html</a></i>
</p>
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 compilation the plugins, osgGLUT and
osgText one can download .zip archive will all the dependencies in it.
Further details on this .zip file can be found in <i><a href="dependencies.html">dependencies.html</a></i>
<p>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 :
</p>
<p>SET OSGFILEPATH=D:\OpenSceneGraph-Data;D:\OpenSceneGraph-Data\Images</p>
<p>SET OSGFILEPATH=D:\OpenSceneGraph-Data;D:\OpenSceneGraph-Data\Images
<br>SET PATH=C:\WINDOWS;C:\WINDOWS\COMMAND;D:\osg-0.8.43\bin;
<p>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
have been zipped up for your convenience, your find these on the OSG release
download directory.
<h3>
Using Visual Studio .NET</h3>
<p>
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.</p>
Looks like Microsoft have eventually got their act together on the compiler
front, the compiler looks Standard C++ compliant with a solid STL implement,
so this is the recommend route.
<h3>
Using Dinkumware STL</h3>
<p>
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 <a href="http://www.dinkumware.com/vc_fixes.html">http://www.dinkumware.com/vc_fixes.html</a>.
</p>
<p>
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.
</p>
<h3>Using STLport</h3>
</p>
The basic jist is that you'll need to download their STL implementation,
and follow their instructions of how to force VisualStudio to pick up the
new STL implementation. More details at <a href="http://www.dinkumware.com/vc_fixes.html">http://www.dinkumware.com/vc_fixes.html</a>.
<p>Once it is installed everything should compile fine and not crash, but
you won't be running at full speed since the build #ifdef'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.
<h3>
Using STLport</h3>
The OSG has been tested under Windows with STLport-4.5, which allows the
users to configure the type of STL support required for STLport itself.
The key configuration that the OSG needs to do is to enable the wrapping
of MS's own iostreams, than using STLport's own implementation. The later
is not required because this has not be problematic under Windows, it is
only the container classes and algorithms that need replacing (thanks to
MS's utterly hopeless implementation of these). Using the iostream wrappping
MS's utterly hopeless implementation of these). Using the iostream wrapping
option means the STLport can just be used on your include path, there is
no need to compile STLport itself, or link into any special libraries.
To configure STLport simply comment IN (its commented out by default),
the follwing line from STLport-4.5/stlport/stl_user_config.h so it should
the following line from STLport-4.5/stlport/stl_user_config.h so it should
look: # define _STLP_NO_OWN_IOSTREAMS 1 Then configure the includes path
in Visual Studio to pick up on STLport: Select the "Tools" menu. Select
"Options" In the Options dialog, select the "Directories" tab Under the
"include" option, add the path to STLport4.5, something like: D:/STLport4.5/stlport
Then press the up array to move the entry all the way to the top of the
list, thus overriding MS's own STL implementations.
</p>
<hr>
<h3><u><a name="Linux">Compiling under Linux</a></u></h3>
<h3>
<a NAME="Linux"></a><u>Compiling under Linux</u></h3>
Compile, from the OSG root directory, ('%' is UNIX csh prompt) type:
<blockquote><tt>% make</tt></blockquote>
Note, make should automatically detect linux and build optimized targets
for your system. And if you wish to install the OSG type:
<blockquote><tt>%&nbsp;make install</tt></blockquote>
<blockquote><tt>% make install</tt></blockquote>
or
<blockquote><tt>%&nbsp;make instlinks</tt></blockquote>
<blockquote><tt>% make instlinks</tt></blockquote>
To get full details of make options, type:
<blockquote><tt>%&nbsp;make help</tt></blockquote>
<blockquote><tt>% make help</tt></blockquote>
(highly recommended)
<p>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
the recent Mesa version have this as standard. Unfortunately not all Linux
distributions are up to 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 &amp; GLU1.3 for a quick way of installing
GLU1.3 in the right place.
@@ -226,63 +224,58 @@ a README in the tarball with some info on what the script actually does.
There's nothing wrong with OSG itself; the problem with Redhat 7.2 is that
it doesn't have GLU 1.3 by default, which OSG is now dependent on (for
osgText.) Good luck everyone. - Clay
<br>
<br>
<p>
<hr>
<h3><u><a name="Free BSD">Compiling under FreeBSD</a></u></h3>
<h3>
<a NAME="Free BSD"></a><u>Compiling under FreeBSD</u></h3>
Compile, from the OSG root directory, ('%' is UNIX csh prompt) type:
<blockquote><tt>% make</tt></blockquote>
Note, make should automatically detect linux and build optimized targets
for your system. And if you wish to install the OSG type:
<blockquote><tt>%&nbsp;make install</tt></blockquote>
<blockquote><tt>% make install</tt></blockquote>
or
<blockquote><tt>%&nbsp;make instlinks</tt></blockquote>
<blockquote><tt>% make instlinks</tt></blockquote>
To get full details of make options, type:
<blockquote><tt>%&nbsp;make help</tt></blockquote>
<blockquote><tt>% make help</tt></blockquote>
(highly recommended)
<br>
<br>
<p>
<hr>
<h3><u><a name="IRIX">Compiling under IRIX</a></u></h3>
<h3>
<a NAME="IRIX"></a><u>Compiling under IRIX</u></h3>
Since the OSG uses Standard C++ features such as STL it is important to
have an up to date version of the MIPSPro compilers, ie. 7.3 or later.
Support for MIPSPro7.2.1 has now been dropped since it was becoming to
unwildy to support and is very rarely used in the OSG commiunity. It is
unwildy to support and is very rarely used in the OSG community. It is
recommended to use MIPSPro7.3.1.1m.
<p>Compile, from the OSG root directory, ('%' is UNIX csh prompt) type:
<blockquote><tt>% make</tt></blockquote>
Note, make should automatically detect linux and build optimized targets
for your system. And if you wish to install the OSG type:
<blockquote><tt>%&nbsp;make install</tt></blockquote>
<blockquote><tt>% make install</tt></blockquote>
or
<blockquote><tt>%&nbsp;make instlinks</tt></blockquote>
<blockquote><tt>% make instlinks</tt></blockquote>
To get full details of make options, type:
<blockquote><tt>%&nbsp;make help</tt></blockquote>
<blockquote><tt>% make help</tt></blockquote>
(highly recommended)
<br>
<hr>
<h3><u><a name="Solaris">Compiling under Solaris</a></u></h3>
<h3>
<a NAME="Solaris"></a><u>Compiling under Solaris</u></h3>
Compile, from the OSG root directory, ('%' is UNIX csh prompt) type:
<blockquote><tt>% make</tt></blockquote>
Note, make should automatically detect linux and build optimized targets
for your system. And if you wish to install the OSG type:
<blockquote><tt>%&nbsp;make install</tt></blockquote>
<blockquote><tt>% make install</tt></blockquote>
or
<blockquote><tt>%&nbsp;make instlinks</tt></blockquote>
<blockquote><tt>% make instlinks</tt></blockquote>
To get full details of make options, type:
<blockquote><tt>%&nbsp;make help</tt></blockquote>
<blockquote><tt>% make help</tt></blockquote>
(highly recommended)
<br>
<hr>
<h3><u><a name="Mac OSX">Compiling under MacOS X (instructions written by Phil Atkin)</a></u></h3>
<h3>
<a NAME="Mac OSX"></a><u>Compiling under MacOS X (instructions written
by Phil Atkin)</u></h3>
For anyone who's ever used a Unix box for development it really is so simple
it's insane.
<p>You need to have installed the Developer tools from the CD that comes
@@ -293,7 +286,7 @@ OS rather than the Aqua gloss. The Mac comes with an app in Applications/Utiliti
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
which give away the real OS roots underneath the shiny paint work. 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
@@ -309,7 +302,7 @@ folder of the harddisk the machine booted from).
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
<p>cd $OSGHOME
<blockquote><tt>%&nbsp;make clean</tt>
<blockquote><tt>% make clean</tt>
<br><tt>% make macosx</tt></blockquote>
<p><br>And it sounds too good to be true but it is that simple. It's worth
@@ -323,11 +316,9 @@ built osg rgb 3ds and a couple others - will check and get back to you.
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 -
<blockquote><a href="http://www.macos.utah.edu/Documentation/macosx/security/enablerootuser.html
">http://www.macos.utah.edu/Documentation/macosx/security/enablerootuser.html</a></blockquote>
<blockquote><a href="http://www.macos.utah.edu/Documentation/macosx/security/enablerootuser.html">http://www.macos.utah.edu/Documentation/macosx/security/enablerootuser.html</a></blockquote>
Or alternately,
<blockquote><a href="http://www.thinkmacintosh.com/osxfaq.html
">http://www.thinkmacintosh.com/osxfaq.html</a></blockquote>
<blockquote><a href="http://www.thinkmacintosh.com/osxfaq.html">http://www.thinkmacintosh.com/osxfaq.html</a></blockquote>
<p><br>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
@@ -341,27 +332,24 @@ 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.
forewarned is forearmed.&nbsp;
<hr>
<h3><u><a name="Cygwin">Compiling under Cygwin</a></u></h3>
<h3>
<a NAME="Cygwin"></a><u>Compiling under Cygwin</u></h3>
To compile, from the OSG root directory, type: make Note, make should automatically
detect your system and build optimized targets for your system. And if
you wish to install the OSG type: make install Note that make symbolic
links don't seem to work under cygwin, so a make instlinks will simply
copy files just like make install. 'make install' places all files in /usr/local/OpenSceneGraph
under appropriate subdirectories. To get full details of make options,
under appropriate sub directories. To get full details of make options,
type: make help (highly recommended)
<p>OSGFILEPATH environmental variable
<p>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
<p>OSG_FILE_PATH environmental variable
<p>For the OSG to locate file data files easily an environmental variable
OSG_FILE_PATH 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
Add the following to your .cshrc (note paths separated by colon's): setenv&nbsp;
OSG_FILE_PATH ./:${OSGDATA}:${OSGDATA}/Images Or the following if you're
using a sh compatible shell : export&nbsp; OSG_FILE_PATH=./:${OSGDATA}:${OSGDATA}/Images:
Or under windows (note paths seperated by semi-colon's) : SET&nbsp; OSG_FILE_PATH=./:${OSGDATA};${OSGDATA}/Images
</body>
</html>