Translate Leap Coordinates to use for ThreeJs

[carpetfizz]

Hello,

Is there a way I can translate the Leap Motion coordinates to use with "threeJS"? The Leap Javascript tutorial had the following function for the 2D canvas, but I'm at a loss as to what to do for the z-axis.

 function leapToScene( frame , leapPos ){

var iBox = frame.interactionBox;

var left = iBox.center[0] - iBox.size[0]/2;
var top = iBox.center[1] + iBox.size[1]/2;

var x = leapPos[0] - left;
var y = leapPos[1] - top;

x /= iBox.size[0];
y /= iBox.size[1];

x *= width;
y *= height;

return [ x , -y ];

}

Thanks for any help!

[Joe_Ward]

The Three.js coordinate system is closer to that of the Leap Motion controller than the 2D example you are looking at, so that example might not be the best starting point. In Three.js, the point [0,0,0] is the middle of the world. So, for example, you don't have to shift the axes or invert the y coordinates, you just have to scale the Leap Motion coordinates based on the InteractionBox size and the desired range of coordinates in your Leap.js scene:

function leapToScene( frame , leapPos ){

    var iBox = frame.interactionBox;

    x /= iBox.size[0];
    y /= iBox.size[1];
    z /= iBox.size[2];

    x *= width;
    y *= height;
    z *= depth;

    return [ x , y, z ];
}

[carpetfizz]

Thank you very much, but I had a quick question. What are xyand see z assigned to before they are divided? And for the depth, I'm assuming I can define it as whatever I want?

[Joe_Ward]

Sorry, I left that bit out. x, y, and z are the coordinates from leapPos, so it should be:

x = leapPos[0]/iBox.size[0];
y = leapPos[1]/iBox.size[1];
z = leapPos[2]/iBox.size[2];

The depth is how large your z dimension is, in other words the distance between the closest (positive) z value for the most positive Leap Motion z value and the furthest (negative) z value for the most negative Leap Motion z value.

[carpetfizz]

Thanks much for the help. However, I'm still getting some really high values when I move my hand. I think it's because I'm multiplying it by too much. For width and height, I'm doing the following:

renderer.setSize(window.innerWidth,window.innerHeight);
var width = renderer.domElement.width;
var height = renderer.domElement.height;

[Joe_Ward]

Remember that there are three coordinate systems that you are juggling here.

There is the 2D render viewport that you mentioned where everything in view of the 3D camera is ultimately drawn.

There is the three.js 3D coordinate system. This is the coordinate system defining the positions of any 3D objects, lights, and cameras that you create in the 3D scene. It has its own notion of width, height, and depth (not the same as the render viewport). In fact, the units here are pretty arbitrary. If you put a 1x1x1 cube at the origin, the rendered size depends on the position of the camera. If you put the camera close, the cube will appear large. If you put it far away, then the cube will be small. You can choose any value for the 3D width, height, and depth, but you have to place a camera appropriately to the scene (i.e. is your scene a whole game level, or a single 3D object).

Finally, there is the Leap Motion coordinate system, which reports values in real-world millimeters. You have to transform the values you get from this coordinate system into the interactable area of your 3D scene. This could be the entire scene (e.g. as in the single 3D object case) or it could be a portion of the scene (e.g. the game level case).

tl;dr:
The 2D render size is pretty irrelevant. You have to map the Leap input to the 3D coordinate system used by Leap.js.

[lm_dedelhart]

There is a "normalization" function on the InteractionBox: http://js.leapmotion.com/api_guide#Leap_InteractionBox
that will scale your point data into the 0..1 range. You can use this to get a point into the 0..1 range. You can then scale it by any frame of reference you want.

[Joe_Ward]

I didn't suggest using the normalizePoint() function in this case because it puts the origin at the left, front, lower corner of the box. OpenGL (and Three.js by extension) puts the origin at the middle. So you would still have to translate the coordinates to the proper origin after normalizing.