Terrian model?

Home Forums AR Sandbox Forum Terrian model?


This topic contains 23 replies, has 15 voices, and was last updated by  Cartonaut 11 months, 4 weeks ago.

Viewing 9 posts - 16 through 24 (of 24 total)
  • Author
  • #102922


    The shared Python tool appears to generate a *.grid file which the SARndbox accepts, yet what is resolved is the software signaling the construction of a level sand surface.

    The currently modified *.asc elevation file has approx. min./max. of -107/-75 respectively in an attempt to reflect the box configuration range of -114 to -105.
    The original elevations were 116 to 165 (MASL).

    Should the *.asc inputs elevations be associated with the sandbox elevation plane distance from the kinect, or is perhaps some other normalization necessary?




    @siki… I’m getting an error – usage: dem2grid.py [-h] [-o OFFSET] [-s SCALE] ARSand.dem [ARTest.grid]
    dem2grid.py: error: too few arguments

    Can you help, please?



    So I’ve had success with @sharned C++ code and generating grid files for the Sandbox but have been having a difficulty getting it to display – read that as it does not display. I double checked with @oliverkreylos Lake Tahoe sample grid file but to no avail.

    When the menu is accessed within the sandbox program and a grid file is selected, literally nothing happens. What am I missing?



    The menu item should open a dialog box to select the grid file. When you select the file, that file becomes assigned to the key you pressed to display the menu. So, you need to press the same key again to display the grid file you selected. (You would press it once more to “turn it off”.)

    This seems a little unintuitive to Windows users, but there is an advantage to it. You can assign grid files to different keys and have them load just with a single key press, avoiding the menu and dialog display. In the VR world that VRUI was designed for, this would be helpful, but that’s less obvious in the AR Sandbox environment.

    Hope this helps.
    S. Harned



    @sharned thanks for the response. That makes complete sense and that then explains that I was seeing what I should when the whole thing went blue which would indicate that the grid file is completely below the level of the sand correct? I’ve read Kreylos’ discussion on the changing the grid elevation and getting the depth right.

    Have you (or anyone) found a simple way to do this? Is there something in the code that needs to be tweaked to make it recognize the correct elevation each time? Inputting a new grid fie and then having to tweak the correct elevation seems cumbersome hence the reason why I think I’m making more work for myself that I should!


    D. Thesenga



    @dthesenga You’re on the right track if you saw the terrain turn blue. Dr. Kreylos described the way to make adjustments in this post earlier in this topic. Basically, you want to save the “input graph” to a file so you can edit it in a text editor. You need to find the tool you created to load the grid file, then add the demVerticalShift line as he descried. There is also a demVerticalScale value you can add, if you have extremes in the terrain data. Try it and see.

    I found that I could Alt+Tab between the ARSandbox and the Text Editor where I changed the demVerticalShift value. Then you only need to reload the input graph (right-click the mouse, select Devices, Load Input Graph, select the file you just edited/saved in the Text Editor).

    Once you have found the right value for the vertical shift, it’s about the same for most grid files. It shouldn’t vary by much (I think). Your results might differ from mine.

    S. Harned



    Thanks for the info in this thread, just posting to share what I have learned about the DEM loader.

    I noticed that the demVerticalShift depends on how you have calibrated your sandbox’ base-plane. If in Step 8 of the Complete Installation Instructions you placed a flat surface over the walls of your sandbox to extract the base-plane, your demVerticalShift will be approximately equal to the distance between this flat surface and the leveled-out sand. You will also need to select a vertical shift if you changed the base-plane equation in any way (i.e. to raise your height map scale). However, if you calibrated your base-plane simply by leveling out the sand, and did not alter the output base-plane equation, then your vertical shift should be close to zero.

    If your sandbox, in DEM mode, is instructing you to build a flat surface, that means either your DEM is too flat (adjust demVerticalScale), or it was not loaded correctly. For me, with SARndbox 2.3 the DEM would not load correctly if I selected “Load Input Graph”, when the input graph did not specify a demFileName. This causes the sandbox to prompt me to select my DEM, and happily accepts it, but fails to render it correctly. To fix this, set demFileName within your input graph.



    Would there be any reason why this DEM tool might not work well with other planetary coordinate system raster’s (Mars for example)?
    Having difficulties getting anything other than a red map motivates this question.



    Hi all,

    I’m trying to wrap my head around this and the other tools for DEM creation and management I have at my disposal.

    I’ve read the posts above and the 32 bit restrictions, but what I don’t understand is how a rectangle selection from the OpenTopography site, results in a DEM of correct aspect or pixel proportions.

    I have other ways to generate and export to Arc ASCII grid (ArcGIS for example) and was hoping someone might clarify this.


Viewing 9 posts - 16 through 24 (of 24 total)

The forum ‘AR Sandbox Forum’ is closed to new topics and replies.

Comments are closed.