Forum Replies Created

Viewing 15 posts - 436 through 450 (of 483 total)
  • Author
    Posts
  • in reply to: Feature wish list #100809

    Oliver Kreylos
    Keymaster

    For new questions, please start a new thread in the main forum.

    in reply to: Feature wish list #100804

    Oliver Kreylos
    Keymaster

    We’re using Kinetic sand in the AR sandboxes at Lawrence Hall of Science and ECHO. I personally don’t like it very much because it requires a bit too much effort to work (you can’t make a riverbed just by swiping your hand, for example), and it doesn’t take projection color very well because Kinetic sand, at least as of now, is naturally brown instead of white. The Kinect can read its surface just fine.

    in reply to: Display updates intermittent #100801

    Oliver Kreylos
    Keymaster

    One thing: what kind of laptops did you try, and how old were they?

    I have a 2008 Macbook Pro, and I have run into a similar issue with Kinect. The moment I stop moving the mouse/trackpad or stop pressing keys, the computer goes into a lower-power state, and in that state it’s not fast enough to keep up with the Kinect’s high data transmission rate. Plugging it into an AC outlet, or turning off power saving in laptop mode, fixes the issue. Have you by any chance tried any of that?

    in reply to: Display updates intermittent #100800

    Oliver Kreylos
    Keymaster

    I’ve heard about that problem a few times now, but I’ve never been able to replicate it, or figure out what could be causing it.

    Does the same happen when you run one of the non-Kinect / Sandbox Vrui applications, such as the ShowEarthModel one that’s part of Vrui’s example programs?

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

    Oliver Kreylos
    Keymaster

    OK, then you had a broken USB host controller. That happens. The Kinect sends a lot of data over USB, and controllers that seem to work fine for keyboards or mice or webcams etc. might buckle under the load.

    in reply to: Problems with KinectViewer (calibration step 5) #100798

    Oliver Kreylos
    Keymaster

    If you remove the intrinsic calibration file, the Kinect package will fall back to a built-in default calibration, which isn’t good, but gets the basics going. That built-in calibration file results in measurements in cm. The file you created by running KinectUtil getCalib results in measurements in mm, therefore all the measured numbers are 10 times larger. This was an oversight in the current Kinect package; I should have added code to make sure that calibration is always in the same units.

    The built-in default intrinsic calibration will be mostly OK for using the sandbox, because the projector calibration step will sort out most discrepancies. But the built-in calibration won’t properly align the depth and color cameras (the latter isn’t used for the sandbox), which is probably what you’re seeing in KinectViewer.

    For simplicity, go with the built-in default calibration right now, because otherwise you’d have to change a few numbers throughout other sandbox configuration files to account for the 10-times size difference.

    Once your sandbox works, you can go back and improve it by doing a full calibration including per-pixel depth correction.

    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.

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