Forum Replies Created

Viewing 15 posts - 481 through 495 (of 522 total)
  • Author
    Posts
  • in reply to: Problems with KinectViewer (calibration step 5) #100793
    Oliver Kreylos
    Keymaster

    Most probably a scale issue. If you retrieved calibration data from your Kinect via “KinectUtil getCalib <index>”, you might receive distances in mm instead of cm.

    After starting KinectViewer, zoom out by rolling the mouse wheel up a few times. The 3D image should come into view shortly, and then start from there.

    in reply to: Using SARndbox with libfreenect or Iannix #100786
    Oliver Kreylos
    Keymaster

    To process an incoming depth image within the rawDepthFrameDispatcher method, or any method called by it, you access the frame contents via the getBuffer method:

    const RawDepth* depthImage=static_cast<const RawDepth*>(frameBuffer.getBuffer());

    RawDepth is a typedef for unsigned short, i.e., each pixel in the depth image is a 16-bit unsigned integer. You can get the size of the depth image from the frame buffer’s getSize() method, but for Kinect v1 the size is always 640×480.

    The contents of the depth image are raw pattern displacement values, meaning they are not metric distances. The conversion formula from displacement values d to metric z values is slightly different for each Kinect camera; figuring out the parameters is part of intrinsic calibration. The precise formula to get z from d is:

    float z = A / (B - float(d))

    where A and B are intrinsic calibration parameters. Approximate values for A and B are 34000 and 1090, respectively, which will yield z values in centimeters.

    There is also pretty significant non-linear distortion in the depth image, due to lens imperfections in both the IR pattern projector and the IR camera. My Kinect software uses per-pixel depth correction formulas to account for those; they are applied to the raw displacement values before conversion to metric distances. See the FrameFilter class’ filterThreadMethod method to see how they are applied.

    in reply to: BENQ MH630 #100783
    Oliver Kreylos
    Keymaster

    There is a newer graphics card generation, a GeForce GTX 970 instead of the GTX 770 that used to be on the recommended hardware list. We have not tested the 970 yet, but based on its specifications it should be slightly faster than the 770. As it is not much more expensive, it is probably a good deal. We don’t see any reasons why the 970 should cause problems for an AR Sandbox.

    The Intel Core i7 is still the recommended CPU, although a Core i5 should work fine as well. A mid-range i7 (or i5) at a reasonable cost will be ideal; it is not necessary to buy an “extreme edition” CPU or the like.

    in reply to: libusb library troubles in MACOS 10.10 #100781
    Oliver Kreylos
    Keymaster

    warning: zero size arrays are an extension [-Wzero-length-array]
    and
    warning: commas at the end of enumerator lists are a C++11 extension [-Wc++11-extensions]

    I have not tried building the Vrui / AR Sandbox software stack on Mac OS 10.10. But so far, every new version of Mac OS has broken a few things here and there. These warnings are OK to be ignored, but I will look into the source code to get rid of them. Would you please post the complete output from the compiler for the source file where these warnings occur, including line numbers? Without that, I will have a hard time tracking them down.

    LIBUSB1_BASEDIR = …

    In cases like this, where you know exactly where a certain library is installed, you can set up the package file entry like this:

    LIBUSB1_BASEDIR = /usr/local
    LIBUSB1_DEPENDS =
    LIBUSB1_INCLUDE = -I/usr/local/include
    LIBUSB1_LIBDIR  = -L/usr/local/lib
    LIBUSB1_LIBS    = -lusb-1.0
    

    (Ensure that /usr/local/lib indeed contains the libusb-1.0.dylib library file.)

    After this change, Vrui’s makefile should auto-detect the presence of bus topology calls. If it doesn’t, you can explicitly enable that feature via line 82 in the makefile:

    
    # Presense of libusb_get_parent in libusb.h:
    # LIBUSB1_HAS_TOPOLOGY_CALLS 0
    

    Uncomment the second line and set the value to 1.

    This should hopefully work.

    in reply to: Hide mouse while running SARndbox? #100779
    Oliver Kreylos
    Keymaster

    The more elegant approach is to place a file defining an invisible cursor into Vrui’s share/Textures directory (which already contains Cursor.Xcur), and create a patch configuration file as above with the following contents:

    section Vrui
      section Desktop
        glyphCursorFileName <Vrui texture dir>/EmptyCursor.Xcur
        glyphCursorNominalSize 8
        
        section MouseAdapter
          fakeMouseCursor true
        endsection
      endsection
    endsection
    

    where <Vrui texture dir> needs to be replaced with the full path to the directory where EmptyCursor.Xcur was placed.

    in reply to: Hide mouse while running SARndbox? #100778
    Oliver Kreylos
    Keymaster

    It’s somewhat hackish, but the easiest way to hide the mouse cursor is to press “Q” once SARndbox is running. This will set Vrui into first-person navigation mode (like a first-person game, with WASD to move and mouse to look around), which will hide the mouse cursor as a side effect.

    FPS mode by default shows a heads-up display that might get overlaid onto the terrain. If that’s the case, disable the FPS mode HUD by creating a new Vrui.cfg file in the same directory from which SARndbox is run, with the following contents:

    section Vrui
      section Desktop
        section Tools
          section DefaultTools
            section FPSNavTool
              drawHud false
            endsection
          endsection
        endsection
      endsection
    endsection
    
    in reply to: Blue line around running SARNDbox projected image? #100774
    Oliver Kreylos
    Keymaster

    Awesome sleuthing! I can confirm that this works for me.

    This pointed me towards where the actual problem in the code is; I am using GL_CLAMP as clamping mode for the water level texture, which is appropriate during the water simulation itself because the sampling mode is GL_NEAREST, but when I use the water level texture to colorize the sand surface, I temporarily switch its sampling mode to GL_LINEAR, and GL_CLAMP will then access parts of border texels, which are blue.

    However, when I change the clamping mode for rendering to GL_CLAMP_TO_EDGE in the code (that’s what disabling “Conformant texture clamping” does according to Nvidia docs), it doesn’t work at all — it gets even worse. So there is still something wrong somewhere in the driver, or disabling conformant clamping doesn’t quite do what Nvidia claims.

    But for now, disabling “conformant texture clamping” is a valid workaround. I’ll add it to the common issues.

    in reply to: OS/Hardware Success/Failure Stories? #100771
    Oliver Kreylos
    Keymaster

    In addition RawKinectViewer and KinectViewer freeze while any key is held down so it makes calibration a beast.

    Can you describe that problem in more detail? I don’t think I’ve heard of this one before.

    in reply to: OS/Hardware Success/Failure Stories? #100770
    Oliver Kreylos
    Keymaster

    Our own sandbox is running Nvidia driver version 343.36 on a GeForce GTX 680, and we have the blue rectangle problem.

    in reply to: Blue line around running SARNDbox projected image? #100769
    Oliver Kreylos
    Keymaster

    If you want to try different Nvidia driver versions, it’s easier to use the binary blobs directly from Nvidia’s site instead of the distribution-supplied drivers, but to be honest it’s quite the pain in the buns.

    I don’t currently have a driver version that’s known to work. When we built our initial prototype in 2012, it worked flawlessly, and when we rolled out the sandbox for open-house day in 2013, we were able to roll back to a then-recent driver version that worked, but currently, due to a newly-installed OS, we have the blue rectangle in our sandbox as well. It’s very close to the physical edges, so it’s not too annoying, but it’s there.

    in reply to: BENQ MH630 #100765
    Oliver Kreylos
    Keymaster

    The Kinect camera has a 4×3 aspect ratio, meaning that the sandbox itself should ideally also have a 4×3 aspect ratio, or there will be parts of it that won’t be scanned, and that would be confusing/irritating.

    This projector has a 16:9 aspect ratio, meaning that it would have to over-project the area scanned by the Kinect. This is not necessarily a problem, but it will take some extra software setup to ensure that the overprojected parts are black, to be close to invisible, instead of some random color. When overprojecting to the full size of the scanned sandbox area, the remaining resolution of the projector would be 1440×1080, which is somewhat higher than the 620’s 1024×768. But the sandbox’s effective resolution is limited by the Kinect camera’s 640×480, so the benefit would be marginal.

    The bigger issue is throw distance. The 620’s throw ratio matches that of the Kinect camera, meaning it can be mounted at the same height as the Kinect. This projector needs to be mounted significantly higher to achieve the same projection size, which makes the overall sandbox design more complex (probably needs a mirror), and could potentially lead to problems when the Kinect itself ends up in the projector’s light path and casts a shadow onto the sand surface.

    Based on the projector specs and the throw distance calculator at Projector Central, the minimal throw distance to create a 30″ tall image is 61″.

    Here is an existing AR Sandbox installation with a long-throw projector and a mirror: British Geological Survey

    in reply to: Using SARndbox with libfreenect or Iannix #100750
    Oliver Kreylos
    Keymaster

    That would require code modification. The main SARndbox application receives depth image data in a central callback, from where it is dispatched to any clients who need depth data for processing. It would be straightforward to add another client that converts the raw depth data into whatever format necessary to control external applications, and then stream it out through OSC or a custom protocol.

    The relevant callback is called rawDepthFrameDispatcher, and found in Sandbox.cpp.

    in reply to: Blue line around running SARNDbox projected image? #100749
    Oliver Kreylos
    Keymaster

    The last four lines are the corner points in 3D. It looks like your fourth corner point is off (52 instead of 62 in x, 39 instead of 44 in y), which would pull in the entire box, so you might want to re-measure that.

    You can manually push out the box by adding/subtracting from the x,y positions. For example:

    (-65.6, -49.7, -147.3)
    (64.0, -47.4, -148.9)
    (-63.1, 45.6, -154.4)
    (53.3, 40.4, -155.3)
    

    will push your box outward by 1cm in each direction.

    in reply to: Blue line around running SARNDbox projected image? #100745
    Oliver Kreylos
    Keymaster

    Thanks. This is no guarantee of success, but you could try installing a newer Nvidia driver. I’m on Fedora 20, and the stock Nvidia driver for that distro is at version 331.104. (The graphics card on this laptop is a GeForce 8600M GT.) I can’t test right now whether this driver version works or not. The stock version on Fedora 21 is 343.36 right now.

    Let’s collect version numbers of Nvidia drivers that don’t exhibit the problem.

    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.

Viewing 15 posts - 481 through 495 (of 522 total)