The first idea, and immediately workable, is to use xdotool. With xdotool:

1- move the mouse to a spring source
2- press the local water key
3- wait some time
4- release the key

Repeat this in a loop (in a script) with several spring sources.

As an example, here are xdotool commands to add water at three locations, each for a tenth of a second. (This assumes the ‘r’ key has been assigned to “Manage Local Water” in SARndbox.)

search --name "^SARndbox$"
windowactivate %1
mousemove --window %1 --polar 0 200
keydown 'r'
sleep 0.1
keyup 'r'
mousemove --window %1 --polar 90 200
keydown 'r'
sleep 0.1
keyup 'r'
mousemove --window %1 --polar 270 200
keydown 'r'
sleep 0.1
keyup 'r'

If there is not enough water from each spring, increase the rain strength with the -rs argument or patch your SARndbox to add the rainStrength pipe command.

The BenQ MX631ST looks to have a native 4:3 aspect ratio, so that should be simpler. Otherwise, it appears to be the same as the MW632ST.

I would try to disable any image processing by the projector. In the projector menus, set the aspect ratio to “Real” and disable digital zoom by setting it to “1.0”.

One possible way to do this is to cut out a hand silohuette. Just as a trial, I once cut out a trace of my hand on cardboard and stood it over the sand with a short PVC pipe. It worked to make an artesian well on the sand.

We do not use the hand silohuette because part of the fun is the interactivity and group effort. Assign a student to make the rain hand shape. Rotate student helpers as arms become tired.

Another way is to use the “Manage Water Locally” tool. Place the mouse cursor where you want the rain/spring and press the assigned key to add water at that spot. I believe this could be automated with xdotool (for Xorg or the similar ydotool for Wayland) to place the mouse pointer and virtually press the “Manage Water Locally” hot key. I think it would be possible to assign a command key in SARndbox to run a script for a local water source. I have not tried this.

@robbo I agree that turning the camera or projector is a solution. Calibrating the Kinect and projector as they are should also work.

I was wrong (darn faulty memory) to say the virtual disc will project onto the real disc after calibration, but the red cross-hairs will follow the center of the real disc. And the sandbox projection should match up with the sand forms.

Please post a transcript of a terminal session where you run the failing command and the errors you receive. Also, include the output of the terminal command ls -lR ~/src/scripts and the contents of /home/alfredo/src/scripts/weather.sh.

I suspect you have all the pieces in place and it is just a matter of patching them together.

Welcome to the forum.

Yes, the AR Sandbox should work on RHEL. There will be differences in the software installation steps. As a start, you can try the Build-Fedora.sh script instead of the Build-Ubuntu.sh script (Fedora is to RHEL as Ubuntu is to Linux Mint).

AR Sandbox installation has been widely tested and documented on Linux Mint. If you are a Linux novice and don’t have someone to help debug installation difficulties on RHEL, I recommend you try Linux Mint.

A little more information might help. What Linux distribution and version are you using? Which model GPU? Which GPU driver?

The following are ideas and questions that I might pursue, if it were my sandbox.

How much of the sandbox software is responsive during a freeze? Can you bring up menus?

What other programs freeze? Try the Vrui example ShowEarthModel app and leave the earth rotating, does the animation freeze? Does glxgears freeze?

If glxgears does not freeze on its own, run glxgears and SARndbox at the same time. Does glxgears freeze when the sandbox freezes?

Much of the above is to determine if the freeze is in the GPU or CPU.

I would try re-seating RAM and the video card in their motherboard slots. I’ve seen loose video cards cause intermittent hard freezes (i.e. only rebooting will restore the system).

@robbo

Doh! <slaps forehead> I see, now. Yes, my instructions above have an error. The pipe file name must match in all steps. So “SARndbox.fifo” in steps 4 and 5 should be “SARndbox.pipe”. Sorry.

Good catch. Will you be posting video anywhere of your sandbox running with alternate liquids and matching colors?

Updated/Fixed steps to change color maps in a running sandbox:

1) If not already done, add a control pipe in the folder you launch SARndbox. In a terminal window, run mknod SARndbox.pipe p to create a pipe you will use to control the running sandbox.

2) If not already done, tell SARndbox to use a control pipe. This is done with the -cp SARndbox.pipe option. I.e. SARndbox -uhm becomes SARndbox -uhm -cp SARndbox.pipe. The pipe names must match in all steps.

3) Create an alternate color map file. Find “HeightColorMap.cpt” and copy it, in the same folder, to “HeightColorMap-lava.cpt”. The four columns in cpt files are (left to right) elevation, red, green, and blue. Edit “HeightColorMap-lava.cpt” to swap the red and blue values for all elevations below sea level. For example, the first line (“-40.0 0 0 80”) becomes “-40.0 80 0 0”.

4) Test your new color map in a terminal window. Run echo "colorMap HeightColorMap-lava.cpt" > SARndbox.pipe to change to the lava color map. Run echo "colorMap HeightColorMap.cpt" > SARndbox.pipe to change to the default color map.

5) Add echo "colorMap <color map file>" > SARndbox.pipe to the “switch” scripts to match the color map to the texture.

6) Ask questions if you run into problems.