Hello Rich,
with Your provided data it's not possible to tell if You can do something.
Things to check:
1) the size of Your computational region. On 32bit system You might
hit a memory limits.
2) check Your OpenGL system. Does glxinfo and glxgears work fine?
3) run nviz under gdb and generate backtrace. Still You might need to
recompile GRASS with --enable-debug to get also debug symbols for all
GRASS parts. --enable-debug is harmless and wouldn't interfere with
normal working with GRASS, it will only help to track down bugs.
Here are some notes I have made for myself on running nviz under gdb
and valgrind:
gdb $GISBASE/etc/nviz2.2/nviz
run -f "$GISBASE/etc/nviz2.2/scripts/nviz2.2_script"
elevation=elevation.dem@PERMANENT
with Your provided data it's not possible to tell if You can do something.
Things to check:
1) the size of Your computational region. On 32bit system You might
hit a memory limits.
Maris,
Yep, this is the reason, and it occurred to me while eating dinner
last night that the 3m map was too big. 80,090 rows * 96444 columns =
7.724.199.960 cells. I'll thin it to 10m and try it again.
I'm building a new server/workstation but my existing one is the only
32-bit Slackware remaining here.
I need only one presentation map of all four drainage basins, and the cell
resolution can be much lower for that. A few analyses will be conducted on
all four basins, but most will be on a single basin so I can probably use
the higher resolution DEM.