keckcaves / crusta Goto Github PK

When using the color palette editor, after using the "Layer Settings" dialog to clamp a particular layer (the globeFile for the topography for example), it is suppose to be possible to add a control point to the color palette by clicking on the topography. There does not seem to be a way to do this, or it is assigned to an unknown button in the provided mouse.cfg file.

Can we add a button to the 'layer' settings and/or that can be assigned to the keyboard/wand/mouse that allows you to turn off all color layers at once?
(show bare surface button)

this would be useful for quickly switching between just looking at the DEM versus the imagery.

Map lines disappearing is a symptom of mapping not being fulling implemented with the caching scheme used by the color layers.

So, map line rendering needs to be completed for this to be fixed.

Hi,
My OS is centos 6.2 . I have installed vrui2.4-003,and I can run the ExamplePrograms.Then I have installed crusta according to "http://keckcaves.org/software/crusta/sourceinstall",but when I run "/home/hyjy/Crusta/bin/crusta ",there is an error:
Caught exception Gpu2dAtlasCache: could not accommodate cache of size 1024 while initializing rendering windows
I do not know why. please help me.

Chen Zhao

A suggestion (really for VRUI): Add a secondary light ('reading light') that will shed light on menus when they are in shadow (especially for desktop use). The flashlight can be used for this purpose, but we want a light that can be left on.

Currently crusta will just crash if certain graphics extensions cannot be used; try to instead give a helpful message and exit cleanly.

For some of the work with the LakeViz project, we would like to expand the area of data that crusta displays at full resolution. So rather than just the area at the cross hairs loading, we would like the whole area of the screen to appear the same. Oliver says that this is possible, but that it is something that has to be changed at a higher level than just merging in a config file. Ideally we'd have this version running on wizard since that's where John and I make the example movies, and then also distribute this version to the LakeViz team.

Oliver's comments are:
Just like LiDAR Viewer, Crusta uses a focus+context LOD model where
areas away from the focus (screen center) are drawn at reduced
resolutions. Unlike LiDAR Viewer, the focus+context drop-off factor
is hardcoded and cannot be changed via the UI.

Ideally, there would be two configurable parameters, not necessarily
via GUI:

• focus area size: area in which tiles are drawn at screen
  resolution. This should be expressed as a multiple of Vrui's
  reported display size.
• focus area weight: scale factor how quickly resolution is reduced
  depending on distance from the focus area. This is usually a number
  =0, with 0 meaning screen resolution everywhere

The focus+context computation is either done in a method preparing
for rendering, such as during an LOD computation traversal of the
node tree, or directly in the display method. I don't know which it
is.

I've had some issues trying to load shapefiles that were not originally produced in Crusta. I have followed the instructions on the Crusta page to assign z-values to the shapefile and assured that it has a vertical projection system. The spatial extent of the shapefile is much smaller than the spatial extent of the dem dataset loaded into crusta. I encountered two different errors:

1. Attempting to load in a shapefile with different columns in its attribute table than what is output by crusta - This produced a string of errors in the terminal window, repeating "ERROR 1:Invalid Index: -1" for every polyline. Crusta loaded a vector file that appeared to be a spiderweb of lines that covered the entire globe and promptly crashed.
2. Attempting to load same shapefile with same columns in its attribute table as what is output by crusta - This did not produce any errors in the terminal window and there was a message indicating that the polylines had been loaded. However, the spideweb of lines covering the globe appeared again.

If rotating the earth while moving using the mouse.cfg setup, sometimes the rotation of the view 'jumps' to a different one... not sure of the source of this.

When using the palette editor in Crusta, clicking on the "Load Palette" button results in the program freezing and eventually closing. This was printed in the terminal:

/usr/local/bin/crusta-desktop: line 2: 3559 Segmentation fault /usr/local/Cellar/crusta/1.0-70-g0dfb95a-1/bin/crusta -mergeConfig /usr/local/Cellar/crusta/1.0-70-g0dfb95a-1/share/vrui/mouse.cfg "$@"

Construo seems to "miss" pieces of input data, resulting in gaps in the output quadtree. It is like there are "gaps" between nodes of the quadtree, and if a piece of an input image falls into the gap and doesn't make it all the way into the next quadtree node, that piece gets lost.
Not the best description, but I don't fully understand the problem, obviously.

Implement subsurface historic earthquake visualization similar to that found in ShowEarthModel in the Vrui examples.

It would be nice if one could load a color palette file for a float layer or a DEM from the command line. For example;

crusta float_layer.globeFile palette.pal

If I start mapping, no lines appear, just the nodes of the active polyline segment. If I go to the menu and then "settings" and deselect "Decorate Lines" then a line appears, but it is a simple black line that also does not change if I change the map symbol. It also does not drape across the topography, it travels straight between nodes (so cuts through or hovers above topography depending on the elevation of the two nodes which define the segment).

I am using Crusta version 1.0-70-g0dfb95a-1 and using the Crusta Desktop configuration (by running crusta-desktop) on Mac OS X 10.6.8.

I installed crusta on a relatively new macbook pro and entered the correct command lines as used on other more powerful macs and i am having trouble. is this because the 13" is not capable of running crust?

If crusta can't read a given input, it silently skips it.
This makes it hard to know why the expected data does not show up.

If it is possible, it would be extremely helpful when interacting with the palette editor if in addition to the sliders, if there was a way to change the numbers by specifying a particular elevation value for a control point by typing a number. There are two reasons for this feature request.

1. In the case of a large dataset with bathymetry values, the inputed min and max values are extremely large. For example, a topography dataset including the open ocean and the himalayas has a min of < -6700 meters and a max of > 8000 meters. Trying to change these min and max value with sliders to useful values for most of the topography takes EXCEEDINGLY long. Thus, being able to bypass the sliders and type in a value would be nice.

2. Sometimes you want to specify a very particular value, which can be difficult to reach with slider. While the probing function allows for particular values based on points in the topography to be specified, sometimes a very particular numerical value is desired for a particular control point. For example, sea level, height of an old shoreline, estimated height of a flood, or some other threshold in the topography (minimum height of glaciers, etc). While you can get to specific values using the sliders, it can take a lot of practice and finesse. For example, it took me nearly five minutes of trial and error to get a particular dataset to simply give me a control point at exactly -27 meters, the modern height of the Caspian Sea level, and even after this amount of time I was not able to get it to exactly this value.

There appear to be some issues with the way Crusta deals with SceneGraphs. Specifically I have only tested importing profiles (so basically cross sections) but it appears to not be projecting them properly and is also dealing with elevations of the profile in odd ways. I have attached some screenshots and provide a link to the test files. There are two (potentially unrelated) issues:

1. Latitudinal shift of data: All data appears to be shifted latitudinally with respect to where it should appear. If a profile is north-south (along a line of longitude) it is aligned with this line of longitude, but the latitudinal positions of its beginning and ending points are shifted.

2. Elevations along profile: As near as I can tell, Crusta only correctly deals with the elevations at the beginning and ending of the profile. This is most noticeable when a profile crosses lines of latitude. So, if the top of a profile is at 10,000 meters at both ends, those ends appear at 10,000 meters elevation, but the top of the profile between those points is a straight line with non-constant elevation, and may even go through the surface of the earth depending on the length of the profile.

Link to test data:
https://www.dropbox.com/sh/7bf0gp9l3q0qhhp/gEOT--RXYq?m