Installation
Why doesn't SOAR compile under MSVC?
SOAR needs to be compiled in ANSI/ISO C mode (with the /Za option). By default, MSVC provides C extensions like "near" and "far" pointers, and has some additional quirks that will prevent SOAR from compiling properly. Please follow the installation instructions in the tar file carefully.
Another reason MSVC might fail is that older versions of GLUT depend on windows.h, even when compiling in ANSI mode. This may result in numerous error messages, e.g.,
C:\...\winnt.h(357) : error C2467: illegal declaration of anonymous 'struct'
This problem has been resolved in GLUT 3.7.
Why doesn't the libpng Windows DLL work with SOAR?
We wish we knew. There seems to be a compatibility problem with GLUT and libpng. Please compile SOAR with the static libpng library. Again, refer to the installation instructions in the tar file.
How do I install the tar.gz file on Unix/Linux?
To "untar" this file, type
gzip -c -d soar-1.11.tar.gz | tar xvf -
This should create a directory called soar-1.11 containing the source code. Read the file README in the tar file for further instructions.
Why doesn't make do anything on Unix/Linux?
On Unix, download the tar.gz file instead of the zip file. The text and source files in the zip archive have CR-LF terminated lines, which can throw off the make utility.
Runtime
What should I set the png2geo parameters to?
You need to provide the horizontal resolution in the xy-plane, in meters, as well as the vertical z resolution, also in meters. (You can safely substitute meters with feet, or whatever your world coordinate units happen to be.) NOTE: The horizontal resolution is not the dimensions of the height field image, but rather the post spacing between the samples, while the vertical resolution is the number of meters between consecutive pixel values, i.e., the scale factor that the quantized, integer elevation values get multiplied by. As an example, the sample data sets provided on the SOAR home page should be compiled as:
png2geo 160.0 160.0 0.1 ps_height_1k.png ps_height_1k.geo
How much disk space will I need?
For the linear matrix layout, you'll need five floats per sample (3 for vertex coordinates, 1 for the error term, and 1 for the bounding sphere radius) to store the height field geometry. This results in 20 bytes per vertex. For the quadtree layout, there is a 66% overhead (because of "holes" in the vertex array), which leads to 5/3 × 20 = 33.333... bytes per sample. As noted below, you may need more temporary RAM to preprocess the data. Also, additional disk space is needed for any PNG texture files.
Why does png2geo v1.10 crash on large data sets?
This is likely due to a lack of RAM. For the quadtree layout, png2geo needs 8/3 × 20 bytes of RAM per height field sample, e.g., 854 MB for a 4,097 × 4,097 height field. (These somewhat high memory requirements are due to having to maintain two copies of the height field in memory during preprocessing.) For the standard matrix (linear) layout, only 20 bytes per sample are needed. Unfortunately, there is a missing allocation test in png2geo v1.10 that can result in a crash if the allocation fails. This has been fixed in v1.11.
Why is png2geo v1.10 so slow on Windows?
Apparently dynamic memory allocation (using realloc) is very slow on Windows, which affects the performance of rearranging the data to the quadtree layout. Later versions make only a single allocation call, which results in a dramatic speed improvement.
Why isn't the number of triangles displayed in SOAR?
You've either disabled the display of statistics (hit the 's' key), or SOAR has not been compiled with statistics enabled (see the installation instructions in the tar file).
Why am I seeing "popping" and/or other visual artifacts in SOAR, even when geomorphing is on?
One possibility is that your graphics card does not have enough bits for z-buffering (24 bits or more is preferred), which can result in z-buffer aliasing. In this case, it may be possible to mitigate this problem by tweaking (increasing) the near clip plane distance in main.c.
Another possible reason for popping is due to our non-conservative view frustum culling, which sometimes results in pops near the edges of the window. This happens when vertices at the lowest level(s) of the level-of-detail hierarchy move into or out of the window, in which case the mesh may change instantly (without being morphed), possibly resulting in large screen space errors. This is especially noticeable when the terrain is flat shaded and either (1) the height field is small, (2) the viewpoint is near the ground, or (3) the screen space error tolerance is large, i.e. whenever the triangles become large, so do the pops. This issue is mentioned in the papers, although it seldom poses a problem for large data sets with reasonably small error tolerances, where the triangulation is refined enough that the resulting pops are small. You can disable view culling to solve this problem, although this will generally slow the frame rate down.