I have had success with producing a *.grid file capable of being opened in the SARndbox viewer with this Python utility.
However, I am having difficulty in establishing the appropriate DEM offset to make it usable with the current SARndbox plane.
Has anyone resolved a simple means of addressing this other than using a GIS calculator to make several .grid surfaces with a gradually adjusted coefficient to find the proper range?
Thanks!
↧
Reply To: DEM Help
↧
Reply To: Terrian model?
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?
Thanks.
↧
↧
Reply To: DEM Help
See my earlier reply. DEM tools have to applicable settings: demVerticalShift and demVerticalScale.
demVerticalShift moves the DEM up or down to match the total amount of sand in the sandbox. demVerticalScale applies vertical exaggeration to the DEM. If the DEM appears to be flat or just noise, it is probably using a different unit of measurement for the vertical than for the horizontal.
↧
Reply To: DEM Help
Thanks for reiterating those commands Dr. Kreylos.
I have experimented with [demVerticalScale, demVerticalShift] further, but the flat plane problem remains.
I am wondering if anyone out there would consider reviewing the input files in question.
The data is accessible via the link below, including original DEM, translated *.asc data, and conclusive *.grid input.
For vertical exaggeration of the original z-axis elevation offset of ~10 meters, neither pre-processing of the raster image in GIS software, or actively adjusting the demVerticalScale within the SARndbox program seems to help.
Consistently, the red/blue areal indications suggest the construction of a flat plane. This is so even when using exaggerations greater than 10 (the provided inputs are at 20x) and upwards of 1000.
The input elevation data (z-axis) is in meters, and the horizontal (x,y-axes) are in UTM (meters).
It seems as though I might be missing a simple step in this process and remain hopeful to resolve.
Again, thanks.
↧
Reply To: Complete Installation Instructions
i try to run with kinect V2 model 1595 but can not work ~ but i see “Kinect-3.2 (252KB) (SHA1=ec66e9c085dc3b16e91b24a8f53ef1e4e340505f) Requires Vrui-4.2-001 or newer. Contains experimental support for second-generation Kinect-for-Xbox-One, and support for Intel RealSense cameras through Intel’s librealsense library.” but i can’t fixed by usb problem ~ so did any body have experience ? thx
↧
↧
Reply To: USB problems with Kinect
hi~ i run with kinect v2 but cant work ~it’s show terminate called after throwing an instance of ‘std::runtime_error’
what(): Kinect::Camera::Camera: Less than 0 Kinect camera devices detected Aborted ~and i cand fixed with Aforementioned step ~ @@ did anyone have expenrice? thx
↧
Reply To: DEM Help
Update;
One possible source of complication was the (column x row) pixel resolution of the input dataset shared previously.
The files have been updated with 480 x 640 (to respectively reflect the Kinects’ capabilities as previously mentioned by Dr. Kreylos), and are available for troubleshooting at the following link:
https://drive.google.com/open?id=0B4hmYjvNucnIeE5YbjFRZm50ZE0
(includes OG elevations and per-processed vertical exaggerations)
Even with these changes, the sandbox continues to suggest a flat DEM surface construction.
Are the *.grid elevation values related to the surface plane measurements for the Kinect calibration?
Also, the (appreciated) LakeTahoe.grid file distributed by Dr. Kreylos exhibits the same problem.
This might indicate that the shared datasets are sufficient, yet this particular sandboxes configuration and/or exaggeration is improper?
↧
Reply To: Weird pattern
Pardon reviving an old thread…
As Dr. Kreylos mentioned, this is a hardware nuance of the Kinect, but would like to encore the last question in this posting;
Is this something that can be mitigated through software easily?
↧
Reply To: DEM Help
I don’t know. I looked at your original DEM, which is a bit flat for the sandbox and for which I would recommend a vertical exaggeration around 5x, and at your scaled DEM which appears to have a 20x factor baked in.
I use the Lake Tahoe DEM I made available on my web server at 4x vertical exaggeration, and it works fine then.
Just for clarification: what do you actually see when you run your scaled DEM, or the Lake Tahoe DEM at 4x?
↧
↧
Reply To: DEM Help
Dr. Kreylos,
The following screenshots were both captured from the SARndbox in full-screen mode.
In the left image, the LakeTahoe.grid file was loaded with demVerticalScale: 4.0, and demVerticalShift: -20.
In the right image, the most recently submitted OG-Elev_CedarLakeDam was loaded with demVerticalScale: 4.0, and demVerticalShift: -12.
It appears both images suggest the construction of a planer sand surface. Also, the two projections do not exhibit any indications of varied topography, which is contrary to their true representation when opening the associated *.dem data in GIS software.
To aid diagnostics, the following pasted text was extracted from this SARndboxes BoxLayout.txt file.
(-0.00618249, 0.027504, 0.999603), -110.904
( -49.2924, -37.6834, -106.106)
( 50.3001, -38.25, -105.131)
( -49.7734, 38.0511, -107.141)
( 51.0307, 37.0223, -104.757)
For general context, an image of the entire apparatus is also included, taken at the time of the above tests.
Glad to provide any other data which might help solve this issue, and enable this great SARndbox feature!
↧
Reply To: DEM Help
Hard to tell what’s going on. Can you mold the sand surface until the color map is white-ish everywhere, and then see what it looks like? Also, just in case, demVerticalShift and demVerticalScale are case-sensitive. Here is a relevant tool section from my configuration file:
section DEMTool2
toolClass DEMTool
bindings ((Mouse, 4))
demFileName /home/okreylos/Projects/Sandbox/LakeTahoe.grid
demVerticalScale 4.0
demVerticalShift -1.5 # Positive values make it blue-er, negative values red-er
endsection↧
Reply To: DEM Help
Dr. Kreylos,
You are a steely-eyed missile man.
It turned out that manual loading of the DEM in an already active SARndbox simulation was causing the error(s).
The following script failed (manual browse and load while SARndbox is running);
section Tool2
toolClass DEMTool
bindings ((Mouse, m))
demVerticalScale 4.0
demVerticalShift -1.5
endsectionPre-loading the DEM source to the mapped key results in successful DEM-interactivity.
The following script succeed for both discussed DEM files (LakeTahoe and CedarLakeDam);
section Tool2
toolClass DEMTool
bindings ((Mouse, m))
demFileName /home/siu-geology/src/SARndbox-2.3/<relevant *.grid file-name here>
demVerticalScale 4.0
demVerticalShift -1.5
endsectionGreat appreciation Dr. Kreylos.
↧
Reply To: Automating drainage key mapping
Hi Dr Kreylos,
When I try and load a saved view on our 2 screen setup (LCD display and Projector) using your instructions in this thread I get the following error:
~/src/SARndbox-2.3/bin $ ./SARndbox -uhm -fpv -wi 1 -uhm -uhs -rws -loadInputGraph front.inputgraph -vruiVerbose
…
…
…
Terminated Sandbox due to exception: Misc::File: Error opening file /home/sandbox/src/SARndbox-2.3/bin/front.inputgraph in mode rt
Am I doing something obviously wrong?
(Running Mint 18.1, SARndbox 2.3, Vrui 4.2-006, Kinect 3.2)
Thanks in advance.
↧
↧
Reply To: Automating drainage key mapping
Vrui is not finding a file it needs, and is looking in a strange place.
Before trying to fix that, please look at this guide on a simpler way to set up additional AR Sandbox features, including binding water keys.
↧
Reply To: Anyone recommend a good Projector?
I just went and double checked, that is the exact model I have: BenQ MW632ST 3,000 Lumens
It does in fact have a 4:3
That model seems to have an even shorter throw than the originally recommended MX631ST projector, which seems to imply it would have to be mounted closer to the surface of the sand. What is the height of both your sand surface from the floor and the projector from the sand? Also, is that an “above-axis” projection model like the MX631ST – i.e. must it be mounted at the edge of the sandbox?
↧
Reply To: Anyone recommend a good Projector?
The BenQ MW632ST’s native resolution is 1280×800, which yields a 16:10 aspect ratio. If you feed it a 4:3 1024×768 video signal, it might do the right thing and pad the signal on all sides so that you get a 4:3 inset of the native display panel. With DLP’s high contrast, you might not notice the overprojection.
Oliver, would building a sandbox in a 16:10 aspect ratio instead of 4:3 work, or does the software assume a 4:3 aspect ratio for both projector and sensor? Mounting the sensor at a height which covers the longer dimension would “waste” some sensor resolution on either side of the shorter dimension, but aside from the wasted sensor area, would this pose any problem?
In other words, instead of exactly matching aspect ratios for the sensor and projector, would it be possible to “fit” the projection within the sensor area?
-Steve
↧
Reply To: Anyone recommend a good Projector?
The MX 631 ST projector is out of production. Has anyone found a replacement? Must be short throw and 4:3 aspect. Thanks
I’m currently assisting another science center with an AR Sandbox installation and came across the following projector which looks quite promising…
It has a 1.2 throw ratio, which means it must either be mounted a bit higher or a mirror must be used. Being 8-10 inches higher would not necessarily be a bad thing IMO. It also has slightly higher lumens, a better contrast ratio, and is a bit cheaper than the BenQ MW632ST. Anyone have firsthand experience with the Optoma W345 projector?
And oh yeah, it also has a 3-year warranty. I can’t find much in the way of reviews, but perhaps that’s because it was released rather recently. Other models of the Optoma brand do seem to get good reviews though.
-Steve
↧
↧
Reply To: Anyone recommend a good Projector?
The AR Sandbox can run at any aspect ratio, but I would recommend running it at 4:3 because the Kinect’s resolution is already a limiting factor. I think it’s better to throw away some display pixels by overprojecting than to reduce resolution even further by overscanning.
The Optoma projector requires a projection distance of 57″ +-5% to fill a 40″x30″ sandbox, which is approx. 17″ more than the old BenQ (and the Kinect). Apart from that, it should do a fine job.
↧
Reply To: Anyone recommend a good Projector?
Thanks for the info, Oliver. I’m a bit puzzled by the following though…
The Optoma projector requires a projection distance of 57″ +-5% to fill a 40″x30″ sandbox, which is approx. 17″ more than the old BenQ (and the Kinect).
The specs indicate a throw ratio of “1.18 – 1.54”. I assume that means it’s adjustable. If set to the low end of that range, wouldn’t that be just 48 inches above the sand?
Thanks for the clarification.
EDIT: Oh wait, is it because of the difference in aspect ratio between the projector and sandbox – i.e. the projector has to be farther to fill the smaller sandbox dimension?
-Steve
↧
Reply To: Anyone recommend a good Projector?
To fill a 40″x30″ sandbox, you have to overproject to a size of 48″x30″ due to the projector’s 16:10 aspect ratio. At maximum zoom, that yields a distance of 48″ * 1.18 = 56.64″. There’s a projection calculator available from the product page you linked where you can try different projection sizes.
↧
