20f3e74643
The first bug is that the terrain tiles will page out to a lower LOD when they are right in front of you. The issue appears to be with the blacklisting heuristic which forces a tile to LOD 1, commenting out the usage of blacklisting with the LOD Nodes fixes our problem. This code change was made to line 29 of TXPPageLOD.cpp. The second bug we were experiencing is that the database reader options never make it through to the archive loader. The use case for us appeared when the FID codes for the terrain were no longer on the materials. As it turns out the archive was being created twice, once by TXPNode and once by the ReaderWriterTXP on getArchive() so the options never actually got set on the archive that was being loaded. The fix is to first create the archive by calling getArchive on the ReaderWriterTXP, which stores it in a map for reference later, and then passing that archive into the TXPNode for it to set its internal member. With this code change we only create one archive (not sure what creating two did) and our options flags get set properly on the database. The changes made are in TXPNode.h line 72 where the TXPArchive is now passed in. In the TXPNode.cpp the loadArchive(TXPArchive*) was changed to have the default behavior if NULL is passed in, if an archive is passed in then it does not load it since all the loading is done in the ReaderWriterTXP::getArchive(). The only other place that loadArchive is called is in TXPIO.cpp where a modification was made to pass in NULL which will have the same behavior as it used to. The last change is the little block of code starting on line 57 of ReaderWriterTXP.cpp, this was changed so that it first calls getArchive() which caches the archives in a map does some loading stuff and returns a pointer to it which is then passed in as a parameter to TXPNode::loadArchive(). The performance changes were made to TXPParser.cpp line 163 where we use to osgUtil::Optimizer on the node before passing it off, and on line 1456 we changed the geometry to use display lists. These small changes actually made drastic performance increases for us, as much as 1000% on certain laptops. As far as testing goes, we have tested these changes with at least 5 txp databases on a variety of different computers including Mac OS and Linux. The base version used is 2.4." |
||
|---|---|---|
| applications | ||
| CMakeModules | ||
| doc/Doxyfiles | ||
| examples | ||
| include | ||
| packaging/pkgconfig | ||
| PlatformSpecifics/Windows | ||
| src | ||
| Xcode | ||
| AUTHORS.txt | ||
| ChangeLog | ||
| CMakeLists.txt | ||
| configure | ||
| genwrapper.conf | ||
| LICENSE.txt | ||
| NEWS.txt | ||
| README.txt | ||
| runexamples.bat | ||
Welcome to the OpenSceneGraph (OSG).
For up-to-date information on the project, in-depth details on how to
compile and run libraries and examples, see the documentation on the
OpenSceneGraph website:
http://www.openscenegraph.org
For the impatient, read the simplified build notes below. For support
subscribe to our public mailing list:
http://www.openscenegraph.org/projects/osg/wiki/MailingLists
Robert Osfield.
Project Lead.
25th April 2008.
--
How to build the OpenSceneGraph
===============================
The OpenSceneGraph uses the CMake build system to generate a
platform-specific build environment. CMake reads the CMakeLists.txt
files that you'll find throughout the OpenSceneGraph directories,
checks for installed dependenciesand then generates the appropriate
build system.
If you don't already have CMake installed on your system you can grab
it from http://www.cmake.org, use version 2.4.6 or later. Details on the
OpenSceneGraph's CMake build can be found at:
http://www.openscenegraph.org/projects/osg/wiki/Build/CMake
Under unices (i.e. Linux, IRIX, Solaris, Free-BSD, HP-Ux, AIX, OSX)
use the cmake or ccmake command-line utils, or use the included tiny
configure script that'll run cmake for you. The configure script
simply runs 'cmake . -DCMAKE_BUILD_TYPE=Release' to ensure that you
get the best performance from your final libraries/applications.
cd OpenSceneGraph
./configure
make
sudo make install
Alternatively, you can create an out-of-source build directory and run
cmake or ccmake from there. The advantage to this approach is that the
temporary files created by CMake won't clutter the OpenSceneGraph
source directory, and also makes it possible to have multiple
independent build targets by creating multiple build directories. In a
directory alongside the OpenSceneGraph use:
mkdir build
cd build
cmake ../OpenSceneGraph -DCMAKE_BUILD_TYPE=Release
make
sudo make install
Under Windows use the GUI tool CMakeSetup to build your VisualStudio
files. The following page on our wiki dedicated to the CMake build
system should help guide you through the process:
http://www.openscenegraph.org/projects/osg/wiki/Support/PlatformSpecifics/VisualStudio
Under OSX you can either use the CMake build system above, or use the
Xcode projects that you will find in the OpenSceneGraph/Xcode
directory.
For further details on compilation, installation and platform-specific
information read "Getting Started" guide:
http://www.openscenegraph.org/projects/osg/wiki/Support/GettingStarted