How to display numbers with the contours?

[liudr]

I am sure this is an easy question, like a runtime option. I would like to display numbers with the contours, such as 0,1,2, etc. for their respective heights in meters. How do I do it? Thanks.

[Oliver Kreylos]

That’s an easy question, but a very hard feature. The current software doesn’t support it, due to the way the contour lines are implicitly generated during rendering.

[liudr]

Hey Oliver,

Thanks for getting back to me with a clear answer. Are the contour lines created by SARndbox? I’m reading your code. It’s hard since I don’t know how your other code (kinect and VRui) works. From reading your code, I realized that dynamically changing the location of the height=0 plane is also going to be very difficult. The base height extracted from BoxLayout.txt is used a lots of function calls or instantiations. The program doesn’t have a main() so I suppose main() is inside VRui and compiled with SARndbox code. I was going to have two push buttons adjust the height of zero height since sometimes you have too much or too little sand. I think it’s going to be quite hard.

John

[Oliver Kreylos]

Contour lines are generated by the surface rendering fragment shader. The exact code is in Shaders/SurfaceAddContourLines.fs. Basically, the shader detects whether a given screen pixel is intersected by at least one contour line, and if so, colors that pixel black. That’s why the contour lines can’t easily be labeled.

The base plane equation is stored in two classes, for different purposes. The DepthImageRenderer class contains the base plane equation used to generate contour lines and a bathymetry DEM for water simulation, and the ElevationColorMap class contains the base plane equation used to color-map the surface. Normally those two are the same, but they don’t need to be.

There is already a function to change the color mapping base plane dynamically. It’s exposed at the SARndbox’s pipe command interface. If you create a named pipe and attach to it with ./bin/SARndbox ... -cp <pipe name>, and then write the following to the pipe while the sandbox is running:

echo "heightMapPlane <normal x> <normal y> <normal z> <offset>"

(concrete example: echo "heightMapPlane 0.0 0.0 1.0 -95.0" to put the base plane flat at 95cm below the camera)

it will immediately change the elevation color mapping. If you want to change the contour line base elevation at the same time, call depthImageRenderer->setBasePlane() with the same plane equation from the same location in the code (inside Sandbox::frame).

In short, insert

/* Override the elevation base plane in the depth image renderer: */
depthImageRenderer->setBasePlane(heightMapPlane);

before line 1152 in Sandbox.cpp.

[liudr]

Oliver,

I really appreciate your help. Your reply got me started. I got the named pipe working after some reading on what a named pipe is. It got me what I wanted but is not easy to integrate into GUI buttons. I wanted to have this feature included in the GUI. It took me a day to peel off the layers of code and finally zeroed in the code that updates the values from the named pipe, find a way to make changes to the height using buttons without running into problems of a struct that was defined internally in sandbox. Now my system will raise and lower the color mapping at the press of 5 and 6. Water simulation seems unaffected by the change of color. That’s what I wanted. You may have too much sand for oceans or too little for all the green land. You just have to adjust color mapping with a knob instead of adding/removing sand or changing a value in a file and rerun the simulation. Pushing buttons beats interacting with Linux for teaching/outreach. I’ll now make the electronics to simulate 5 and 6 using a knob up and down.

John

[liudr]

So I worked on the electronics and now I have a knob to adjust the color map. Here are a few photos of the electronics and same sand but different color maps.

[liudr]

Video:

https://youtu.be/-qsQ5rXE8WI

[Oliver Kreylos]

I’m glad you got it to work, but the idea with the named pipe is that you can create external scripts using bash or Python or whatever, which write commands to the pipe when a button is pressed or some other interaction takes place.

[liudr]

Thanks for the direction. I’m sure there’s more than one solution to this problem. I’m more concerned with how to keep a Python script in focus to receive button pushes and still utilize the water tools (sandbox needs to stay in focus). Maybe there needs to be a push to add more features to the named pipe command parser to have two way communication so the sender may know the current status or sandbox needs more methods to deal with requests such as global water, increment or decrement base plane, etc. Then maybe I should connect my box to the script via serial port and just send serialized command to the script that will send it on to sandbox’s named pipe or maybe even weld the serial port to the named pipe to rid the need of a script. There must be a Linux way to “weld” the pipe to the serial port. Maybe some udev rules that fixes serial port name binding so it wouldn’t change between reboots and other devices being inserted in USB. I’ll have to learn that somehow. Anyway, I started with the simple idea that my box should seamlessly add on to an existing sandbox since it emulates button pushes. Now the source code has to change so there is no simple way to add to an existing sandbox without some “professional” help to the operator of the box 🙂

I’m thinking about simple wrapper functions to get global water or base plane features so they can be called either by named pipe parser or Vrui tool callback.

[Oliver Kreylos]

There is a “ScriptExecutor” tool class in Vrui that can execute a script. You bind it to a button/key like any other tool, and when that button/key is pressed, the script is run. That’s how I set up our AR Sandbox to switch between water and lava: I made two scripts that modify the water fragment shader and use the AR Sandbox’s control pipe to change the viscosity of the fluid, and use two ScriptExecutor tools, bound to two USB buttons, to call those scripts from inside the SARndbox application.

[MaxD]

Hi liudr,
I’m intrigued by your solution to dinamically change water level, can you give me HW & SW details to replicate it in my school?

Thanks!

[liudr]

Thanks Oliver. I’ll give that a try. Is there anywhere to find out about the syntax of the key binding .cfg file? I tried a couple dozen times to successfully bind all keys. Your example on another post only binds two keys to global water tools.
If I do run scripts this way, how will the script know what the current elevation is? I thought that only functions within sandobx.cpp can access the configuration struct.

[liudr]

MaxD,

The two most recent posts on my blog have a lot of details including the Arduino code.

https://liudr.wordpress.com/

I don’t know how much you know about hardware and software. I had to change a number of source files and recompile to add the elevation change feature. You’ll have to replicate that, which is doable if you have some basics of linux. You will get the features and can bind to keyboard keys. The construction of the control box needs skills in building electrical circuits such as soldering wires, hooking up components to arduino, and programming an arduino. I might be able to make some kits or complete boxes but I don’t know if there’s enough interest.

[Author]

Posts