Forum Replies Created

Viewing 15 posts - 436 through 450 (of 453 total)
  • Author
    Posts
  • 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?

    in reply to: Step 5 calibration camera space #100671

    Oliver Kreylos
    Keymaster

    KinectViewer shows a 3D reconstruction of what the Kinect camera sees, which is important to measure the 3D positions of the four box corners. Did the video illustrating that step, http://www.youtube.com/watch?v=RmE6tkXoSJw , help? It shows how to change the viewpoint of the program to move the observed sand surface into the screen plane and take the corner measurements.

    Please note that there’s a mistake in the narration for that video. The corners need to be measured in lower-left, lower-right, upper-left, upper-right order.

    in reply to: Automating drainage key mapping #100670

    Oliver Kreylos
    Keymaster

    Unfortunately, the “mouse click before key press” issue is a known bug in the current release that’s already fixed in the upcoming next version, see elsewhere on this forum.

    in reply to: Water Drain #100668

    Oliver Kreylos
    Keymaster

    My bad; the angle brackets <…> indicate a variable that needs to be replaced with a concrete value. There is another wrinkle that I forgot myself, and that’s that evaporation rate is actually water deposit rate, meaning that it should be negative to remove water.

    Try adding this to the command line:

    -evr -0.25

    and that should do the trick. There needs to be a space between -evr and -0.25.

    in reply to: Water Drain #100660

    Oliver Kreylos
    Keymaster

    The software contains a “water management” tool that can be bound to two keys or buttons. First, to account for a bug in the current software, click the left mouse button within the application window. Then press and hold the key/button you want to use to make it rain, and move the mouse (without clicking any mouse buttons) to select “Manage Water” from the tool selection menu that pops up. Once there, release the key/button you were holding. Afterwards, press and release the key/button you want to use to drain the sandbox.

    After this, press and hold either of these keys/buttons to add/remove water from the sandbox.

    See another post on this forum on how to make this tool binding permanent.

    You can also use a single or a pair of USB buttons that act like keyboard keys to add/remove water.

    Finally, there is a command line option to slowly remove water over time. It is -evr <evaporation rate>, where <evaporation rate> is the rate at which water disappears in cm of depth/s.

    in reply to: Automating drainage key mapping #100657

    Oliver Kreylos
    Keymaster

    There are two ways, and the easier one is probably the following:

    * Start the application, and manually set up your tools as you want, e.g., bind your favorite keys to the water management tool etc.

    * In the application’s main menu (right mouse button), select “Vrui System” -> “Devices” -> “Save Input Graph…” An input graph is the full set of virtual input devices and tool bindings that are currently active in an application.

    * In the file selection box that pops up, either enter a name for your input graph file (press F1 to go to “text entry mode,” enter the filename, then press F1 again to go back to regular mode), or go with the default name. Press OK to confirm.

    * After exiting the application, find the file you just saved. If you didn’t give it a meaningful name from within the application, rename it using the file manager or command line.

    * When starting the application the next time, add -loadInputGraph <input graph file name> to the command line, where <input graph file name> is the name of the file you saved.

    If you use a script or icon to start the application, append the command line arguments in there.

Viewing 15 posts - 436 through 450 (of 453 total)