Forum Replies Created

Viewing 15 posts - 451 through 465 (of 473 total)
  • Author
    Posts
  • in reply to: Running with Windows #100731

    Oliver Kreylos
    Keymaster

    I haven’t tried building under cygwin in a very long time, and last time it didn’t work.

    One issue with running under Windows, either via cygwin (if it works) or in a virtual machine, is that the sandbox application won’t get access to the graphics hardware — it can only run in emulated mode.

    This means the performance of the sandbox, especially the water simulation, will be very poor. The ideal installation is with a dedicated Linux PC, or a Linux installation run natively via dual-boot.

    in reply to: Full Screen #100730

    Oliver Kreylos
    Keymaster

    Please check the topic “Full Screen Mode.”

    in reply to: Water Drain #100723

    Oliver Kreylos
    Keymaster

    There are many brands/makes of USB buttons, but they vary widely in their capabilities, and it’s usually not specified what exactly they do. That’s dangerous.

    In our AR Sandbox, we use a two-button switch, Delcom 706502-F, where the red button drains and the blue button deposits water.

    Delcom also has one-button switches, such as this one, but they are rather pricey. On the upside, they are robust and known to work.

    Delcom’s switches are programmable via a Windows-based utility available from their web site. They can be programmed as mouse buttons, keyboard keys, or joystick buttons. The ideal configuration for the AR Sandbox is one or two joystick buttons. Most cheap USB buttons only emulate keyboard keys, and usually in a dumb way that makes them unusable for the AR Sandbox.

    To use a USB switch that’s configured as joystick button(s), one has to create a patch configuration file that makes it available as an additional input device, and then bind a water management tool to the new device’s button(s) using Vrui’s standard tool binding interface. Alternatively, one can bind a water management tool automatically via the same patch configuration file. Here’s the file I use to bind our two-button box to the add water / remove water functions:

    section Vrui
      section Desktop
        inputDeviceAdapterNames (MouseAdapter, HIDAdapter)
    
        section HIDAdapter
          inputDeviceAdapterType HID
          inputDeviceNames (ButtonBox)
          
          section ButtonBox
            name ButtonBox
            deviceVendorProductId 0fc5:b080
          endsection
        endsection
        
        section Tools
          section DefaultTools
            section WaterTool
              toolClass GlobalWaterTool
              bindings ((ButtonBox, Button167, Button166))
            endsection
          endsection
        endsection
      endsection
    endsection
    

    The deviceVendorProductId setting would need to be adapted to the actual switch’s ID, and the actual button names (Button166 and Button167 in our case) might have to be changed.

    The name of this patch configuration file, say SandboxButtons.cfg, is then added to SARndbox’s command line as such:

    $ SARndbox [usual options] -mergeConfig SandboxButtons.cfg
    
    in reply to: Hardware requirements #100721

    Oliver Kreylos
    Keymaster

    The computing hardware requirements are not strict, per se. The AR Sandbox software runs fine on my vintage 2008 Macbook Pro (Intel Core 2 Duo 2.2GHz, 2GB RAM, Nvidia GeForce 8600M) as long as there is little or no water (or water simulation is disabled entirely).

    The problem is that the water simulation will run slow on low-end systems like that, which leads to noticeable and annoying choppyness when the water is agitated and moves quickly, even if only in some small areas. We found that GTX 770-level hardware is able to handle almost any circumstance without noticeable slow-downs.

    The AR Sandbox is GPU-limited, meaning that the choice of main CPU is secondary. A lower-clock rate Core i7, or an i5, should cause no problems at all.

    The water simulation method I implemented is conservative, meaning that it maintains physical accuracy at the expense of run-time. To be honest, that’s not an ideal choice for an application that requires interactive response and where accuracy is secondary to irrelevant, but that’s the way it is. An always-robust non-accurate simulation method like smooth particle hydrodynamics would be more appropriate, but that wouldn’t be usable for my other applications.

    in reply to: Water to Lava #100720

    Oliver Kreylos
    Keymaster

    The water effect is achieved by a GLSL fragment shader, whose source code is in SurfaceAddWaterColor.fs in the SARndbox package’s shader directory, share/SARndbox-<version>/Shaders.

    To switch the water to appear as lava (this only affects appearance, not behavior), change the following lines in the source file:

    Uncomment line 170:

    float colorW=max(turb(vec3(fragCoord*0.05,waterAnimationTime*0.25)),0.0); // Turbulence noise
    

    Comment out line 177:

    // float colorW=pow(dot(wn,normalize(vec3(0.075,0.075,1.0))),100.0)*1.0-0.0;
    

    Comment/uncomment lines 179 and 180:

    // vec4 waterColor=vec4(colorW,colorW,1.0,1.0); // Water
    vec4 waterColor=vec4(1.0-colorW,1.0-colorW*2.0,0.0,1.0); // Lava
    

    Then save the source file. If the AR Sandbox is already running, the change will take effect immediately; otherwise, it will take effect when the SARndbox executable is started the next time.

    To go back to water-colored water, reverse the steps above.

    Another option is to create two copies of the shader file, say SurfaceAddWaterColor-Water.fs and SurfaceAddWaterColor-Lava.fs, make the above changes in the second file, and then use a script on an icon or hotkey to copy either file onto the one that’s used by the Sandbox, such as

    $ cp SurfaceAddWaterColor-Lava.fs SurfaceAddWaterColor.fs
    

    to set “lava mode,” and

    $ cp SurfaceAddWaterColor-Water.fs SurfaceAddWaterColor.fs
    

    to set “water mode.”

    in reply to: Split Screen #100716

    Oliver Kreylos
    Keymaster

    That’s a neat idea.

    There is also a software way to achieve the same effect. It takes some configuration, but is more flexible, and will work better with the upcoming SARndbox 2.0 software.

    Plug the secondary display into the same graphics card as the main display. The graphics driver should recognize it as a second monitor, and the Nvidia control panel (nvidia-settings from a terminal, or somewhere in the start menu) will show the two displays as two partial screens positioned next to each other. Ensure that both screens are set to the native resolution of their respective displays (1024×768 for the projector, probably 1920×1080 for the secondary), and jot down the absolute pixel positions of both screens.

    In a typical default setup, the main screen would start at (0, 0) with a size of (1024, 768), and the secondary would start at (1024, 0) with a size of (1920, 1080).

    Then create a new configuration file DualScreen.cfg in the Vrui package’s configuration directory (~/Vrui-3.1/etc by default) and put in the following:

    section Vrui
      section Desktop
        windowNames (MainWindow, SecondaryWindow)
    
        section MainWindow
          windowPos (0, 0), (1024, 768)
          decorate false
          windowType Mono
          screenName Screen
          viewerName Viewer
        endsection
    
        section SecondaryWindow
          windowPos (1024, 0), (1920, 1080)
          decorate false
          windowType Mono
          screenName Screen
          viewerName Viewer
        endsection
      endsection
    endsection
    

    Afterwards, add another command line argument to the SARndbox executable:

    $ SARndbox <other options> -mergeConfig DualScreen.cfg
    

    And the same image will show on both displays, at their native resolutions. If either of the two windows does not entirely cover its respective display, i.e., if menu bars etc. still show, add a line “windowFullscreen true” to the respective configuration file section.

    If the two displays have different aspect ratios, e.g., main projector 4:3 and secondary display 16:9, then the topography will appear stretched on the secondary display. To fix this, adjust the size and position of the secondary window. For example, to create a 4:3 window on a 1920×1080 display using the same screen layout as above, use

    windowPos (1264, 0), (1440, 1080)
    

    In the upcoming SARndbox 2.0, the two displays will be able to use individual display settings. This means the topography can be shown in calibrated mode on the main display, and in regular 3D viewing mode on the secondary.

    in reply to: step5 Problem with calibration #100715

    Oliver Kreylos
    Keymaster

    Could you please post the instructions for the calibration step at which you’re stuck here? I’m not sure what you’re referring to.

    in reply to: Problem with "5. Build the Augmented Reality Sandbox" #100714

    Oliver Kreylos
    Keymaster

    makefile:59: /home/ggmedl/Vrui-3.1/share/make/Configuration.Kinect: No such file or directory
    makefile:60: /home/ggmedl/Vrui-3.1/share/make/Packages.Kinect: No such file or directory

    These two messages indicate that the Kinect package was not installed properly. After successfully running “make” in the Kinect package’s directory, you also need to run “make install.” This will copy the two indicated files into Vrui’s installation directory, and also copy all the other required files, such as FrameBuffer.h.

    After running “make install” on the Kinect package, try running “make” on the SARndbox package again.

    in reply to: Sandbox Size #100698

    Oliver Kreylos
    Keymaster

    Due to the Kinect’s fixed field-of-view, it has to be mounted at approximately the same height above the intended sand surface as the sandbox’s width. To wit: sandbox 1mx0.75m => Kinect (and projector) height 1m; sandbox 2mx1.5m => Kinect height 2m.

    The main issue is that the Kinect’s depth resolution, i.e., the sandbox’s elevation resolution, is inversely proportional to distance squared. From 2m away, the Kinect won’t be able to resolve height differences smaller than around 1cm.

    in reply to: caught exceptions with RawKinectViewer and SARndbox #100696

    Oliver Kreylos
    Keymaster

    That’s unfortunate. While it’s true that all versions of the original Kinect (-for-Xbox 1414 and 1473 and -for-Windows 1517) are not 100% reliable, we’re typically only seeing issues very rarely. I haven’t noticed Kinect-for-Windows devices being less reliable than -for-Xbox ones in general.

    When issues do occur (such as error messages, or the depth map being completely flat or non-existent), it’s usually sufficient to restart the application that was using or trying to use the Kinect. If that doesn’t help, KinectUtil reset all typically does the trick.

    If you’re seeing problems that often, there might be a problem with your specific Kinect device, or with the USB port into which it’s plugged, or your entire USB subsystem. If your Kinect is currently plugged into a USB 3 port, try using a USB 2 port. While our software fully supports Kinect over USB 3, USB 3 support in the Linux kernel is still a bit lacking, and Ubuntu 14.04 uses a somewhat older kernel.

    If you’re already on USB 2, try a different plug, ideally on a different bus (front-facing and back-facing ports on a typical tower PC are usually on different buses). If all that doesn’t help, try the Kinect software on a different PC if you have one, and if that helps but you want to keep using the one you currently use, try to find a cheap USB 2 or USB 3 PCI expansion card ($5-$20) and put that into the PC and the Kinect into it.

    in reply to: build issues #100695

    Oliver Kreylos
    Keymaster

    For simplicity reasons, Vrui and its add-on packages and applications (Kinect, SARndbox, …) are set up to install in the installing user’s home directory. For experimentation, I recommend not changing anything in the build system and just running make, make install on Vrui and Kinect, in that order, and make on SARndbox. That creates a working system with the CalibrateProjector and SARndbox executables in ./bin in the directory from which make was run.

    Depending on how the sandbox computer is set up, it might not be necessary to ever do a system-wide installation, but if desired, the easiest way is to pass installation paths directly to make, as in:

    Vrui:

    $ make INSTALLDIR=/usr/local
    $ make INSTALLDIR=/usr/local install

    Kinect:

    $ make VRUI_MAKEDIR=/usr/local/share/Vrui-3.1/make
    $ make VRUI_MAKEDIR=/usr/local/share/Vrui-3.1/make install

    SARndbox:

    $ make VRUI_MAKEDIR=/usr/local/share/Vrui-3.1/make INSTALLDIR=/usr/local
    $ make VRUI_MAKEDIR=/usr/local/share/Vrui-3.1/make INSTALLDIR=/usr/local install

    This procedure doesn’t modify any files, so it could be put into a script.

    in reply to: libusbx and USB nodes #100692

    Oliver Kreylos
    Keymaster

    The udev rule file distributed with the Kinect-2.8 package only has rules for the original Kinect-for-Xbox (model number 1414). I added detailed instructions for newer Kinects to the Kinect download page.

    in reply to: libusbx and USB nodes #100682

    Oliver Kreylos
    Keymaster

    The device manager rule file that’s installed by make installudevrule is only applied when new USB devices are plugged into the system, or the system is rebooted. Meaning, it will not affect the USB device nodes of a Kinect that’s already plugged in.

    There are three alternative methods to activate the rules:

    1. Unplug the Kinect from its USB port, wait five seconds, and plug it back in.

    2. Restart the device manager by running the following two commands from a terminal:

    $ sudo udevadm control --reload
    $ sudo udevadm trigger --action=change
    

    3. Reboot the computer.

    in reply to: Compatibility with Kinect for Windows v2? #100678

    Oliver Kreylos
    Keymaster

    The current AR Sandbox software only works with the first-generation Kinect, either Kinect-for-Xbox 360 or Kinect-for-Windows. I’m still working on a low-level driver for the Kinect-for-Xbox One and Kinect-for-Windows v2.

    You should still be able to pick up Kinect-for-Xbox 360 in the gaming aisle at electronics stores, for around $100.

    in reply to: Sandbox design #100673

    Oliver Kreylos
    Keymaster

    The ECHO AR Sandbox, and its identical twins at Lake Tahoe and Lawrence Hall of Science, were designed by the San Francisco Exploratorium workshops. We paid for the design, so the drawings should be available. Please contact the person in charge at the Exploratorium, Allyson Feeney, via globalstudios@exploratorium.edu .

    The ECHO et al. sandboxes are in portrait orientation, in the sense that the back cabinet is along one of the short box edges. Due to the projector being natively landscape, this leads to a less stable setup where the projector is dangling from the top hood. I recommend a design where the projector is directly attached to the cabinet, running up from the center of one of the long edges.

    Since you’re in Berlin, have you checked out the AR Sandbox at the GameScienceCenter?

Viewing 15 posts - 451 through 465 (of 473 total)