Forum Replies Created

Viewing 15 posts - 436 through 450 (of 463 total)
  • Author
    Posts

  • Oliver Kreylos
    Keymaster

    There are two methods to achieve this.

    The simpler method is to start the CalibrateProjector utility as usual, and bind all desired tools manually as usual. Once all tools are bound, open the application’s main menu, and select “Save Input Graph…” from the “Vrui System”->”Devices” sub-menu. Select a file name and location from the file selection menu that pops up (to use the keyboard to type, press “F1” once to enter text mode, and then “F1” again to leave text mode when done) or leave the default name and location, and select “OK.”

    The saved input graph file, which has the same general format as any Vrui configuration file, can be loaded back into an application either manually via the “Load Input Graph…” entry in the same sub-menu, or via the command line:

    $ CalibrateProjector [usual arguments] -loadInputGraph <input graph file name>
    

    This method works for all Vrui applications, including RawKinectViewer, KinectViewer, and SARndbox itself.

    The other method is to directly edit the Vrui.cfg configuration file, or create an application-specific patch configuration file (see the Vrui documentation). Vrui.cfg contains a section called “DefaultTools,” which in turn contains sub-sections for every tool that is to be bound at application start-up. The format for the tool binding sections is as follows:

    section SomeUniqueName
      toolClass CaptureTool
      bindings ((Mouse, 1, 2))
    endsection
    

    This will bind CalibrateProjector’s capture tool to buttons 1 and 2 on the “Mouse” device (which includes keyboard keys and mouse buttons), in that order.

    in reply to: Blue line around running SARNDbox projected image? #100742

    Oliver Kreylos
    Keymaster

    Unfortunately, I don’t know yet how to completely remove the blue border.

    The reason it’s there is either a bug in the Nvidia graphics driver, or an edge case that is triggered by unorthodox texture image handling inside the AR Sandbox software (I have not yet found where the latter would be in the code). The blue rectangle appears only in specific versions of the Nvidia driver; would you please post your exact version number? It is displayed in the “X Server Information” panel in the Nvidia control dialog, nvidia-settings.

    The blue rectangle runs exactly around the sandbox’s water simulation area, as set up during calibration step 5 (measure extents of sand surface). That area coincides with the extents of the 2D texture images containing the water simulation’s state, and are an effect of either a) the graphics driver wrongly accessing edge pixels from that texture image, or b) the sandbox software wrongly relying on unspecified texture edge behavior.

    The blue rectangle can be pushed further outside the box by extending the 3D box corner positions measured in calibration step 5, but pushing the box corners outside the physical limits of the sandbox is not recommended because it might lead to artifacts in the water simulation.

    in reply to: Problem with calibration #100739

    Oliver Kreylos
    Keymaster

    I just checked the sources, and this is a documentation error. I’ll post a top-level addressing the issue.

    in reply to: kinect viewer glitch #100736

    Oliver Kreylos
    Keymaster

    The GL Error problem is most probably due to running in a virtual machine. On those, Linux only gets simulated access to the graphics hardware and has to use software-emulated OpenGL, which doesn’t support all features used by the software, and is very slow.

    The Kinect problem might be due to the virtual machine, too. The picture looks like there are transmission problems on the USB bus into which the Kinect is plugged, and that could be caused by virtual machine emulation, but I’m not sure.

    In general, it’s not good to run the AR Sandbox through a virtual machine. The sandbox requires a high-performance graphics card, and through the virtualization layer, it does not get access to the installed card — it’s the same as not having one.

    in reply to: Problem with calibration #100732

    Oliver Kreylos
    Keymaster

    Before you line up the depth image grid, ensure that the “Average Frames” button in the main menu is selected. That will collect several depth frames, calculate their average, and display it. While the button is selected, the depth image won’t update live any longer. After you placed the grid and collected a tie point, uncheck the “Average Frames” button, move the calibration target, and repeat.

    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.

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