Inactive Leap Motion Controller
- Thread starter Cervator
- Start date
After calibrating the device using a glass plate (my monitor did not even work) the device goes absolutely mad on me. Can not control Terasology in the slightest with it. Even worse than before the actual calibration.
Maybe you have to do a device reset? I recall seeing an reference to that during the SDK upgrade. Alternatively - does it matter if you hook it up to Mac vs Windows? Lighting conditions still an issue? At least we already have a meeting scheduled with Brandon tomorrow, heh.
Before I forget (need to run out for an errand real quick): I suspect some gesture detection sketchiness I noticed last night is due to the frame limitation I introduced at first primarily to learn handling the leap better (by processing input in slow-mo). Not sure if it is a better option to catch all frames anyway (which is a lot and crashed my Java when I tried it using the Listener - but maybe that was just me somehow) or include some sort of intelligent checking of last x frames per game update akin to lag adjustments. If so maybe that would be a nice thing Jitter could do.
I just remember noticing lost gestures a lot when I turned the FPS down a bit for testing. Which makes sense since the built-in gesture detection triggers on specific frames and we don't necessarily listen to all frames.
I'm getting a little worried now myself. Spent a fair amount of time playing with the Leap today, but it has gotten progressively worse. At first I could move it around to find an optimal setup where I could still control the game, even got Fraps + Bandicam working in a way I could record Terasology + Visualizer + hands in RL with my phone, but before I was done practicing the device started losing track of my hands more and more, making it freak out in-game pretty bad to the point where a video would do more harm than good
Too tired to sort it out tonight, near 1.30 am. I ended up getting a second unit due to a shipping quirk and might try setting it up tomorrow to see if the unit matters or if it is entirely software / positioning.
Too tired to sort it out tonight, near 1.30 am. I ended up getting a second unit due to a shipping quirk and might try setting it up tomorrow to see if the unit matters or if it is entirely software / positioning.
As a quick update I recorded a couple batches of three simultaneous views during Leap testing - my hands in motion, Terasology via Fraps, and the Leap Visualizer in another window with Bandicam as each would only record one window.
We'll see what sort of fanciness we can get out of that
When that gets published that completes what I think of as the first round of Leap integration, the goal of which was to get to where we could do a nice "shiny" showcase video, but not necessarily have super nice or well integrated controls. In particular due to some recent tracking issues that's been a tad harder lately, so it'll be good when that gets fixed again.
In the meantime there's some collaboration goodness for Jitter that'll help for round two, but personally I've been neglecting other things like badgering everybody else to see how other areas of the code are improving - so I need to get back to that
We'll see what sort of fanciness we can get out of that
When that gets published that completes what I think of as the first round of Leap integration, the goal of which was to get to where we could do a nice "shiny" showcase video, but not necessarily have super nice or well integrated controls. In particular due to some recent tracking issues that's been a tad harder lately, so it'll be good when that gets fixed again.
In the meantime there's some collaboration goodness for Jitter that'll help for round two, but personally I've been neglecting other things like badgering everybody else to see how other areas of the code are improving - so I need to get back to that
Minor update - SDK 0.7.5 is out and I updated us to that level real quick. It contains some promising tracking stability fixes, using the visualizer for reference it is now possible to find "good spots" where you can hold your hands and tracking is pretty much rock solid. Still, other spots freak out the same way. But before it was pretty much impossible to find anywhere that was fully OK.
Tracking can also be stable much closer to the device again, so I lowered the default height a tad. Can rest my elbows now while working the controls. No more gorilla arms!
Tracking can also be stable much closer to the device again, so I lowered the default height a tad. Can rest my elbows now while working the controls. No more gorilla arms!
Bump - been a little while but I'm trying to quickly prep for the Jitter phase. Updated us to Leap SDK 0.7.6 and the latest code from develop. Grabbed Marcel's code from https://github.com/mrzl/LeapMotionP5 (coordinated with him earlier) and have embedded it into Terasology intending it as a replacement for the hacky LeapSystem
Just a few more tweaks before it'll compile (vector math, eee) then doing a minimal re-implementation to use it instead of LeapSystem. Afterwards can extract the foundation for Jitter proper from that and put some additional design thoughts on GitHub.
Just a few more tweaks before it'll compile (vector math, eee) then doing a minimal re-implementation to use it instead of LeapSystem. Afterwards can extract the foundation for Jitter proper from that and put some additional design thoughts on GitHub.
And right after I updated to 0.7.6 the next release came out
At SDK level 0.7.7 hand tracking seems rock solid now, which was the biggest issue in the past. New utility methods in this release also offers finding the left-most and right-most hand, which might replace us detecting that manually partially or fully. New stuff also includes being able to set the min sensitivity for gestures to trigger (say configuring circle gestures to run at least one whole circle before being sent out)
I got an initial use case for the Jitter lib worked out and I'm fairly happy with it, especially considering how badly I suck at Java
In short Jitter uses an internal Leap listener that runs at the "Leap FPS" somewhere in the 100-120 range. It then (for now) triggers method callbacks for specific gestures to an external JitterListener interface. That's kinda boring but might expand to where it alone provides some utility.
What makes it really interesting (IMHO) is the layer on top of that. I made a BufferedJitterSystem that implements JitterListener, but as the name indicates it buffers the input in local variables. In the meantime our main loop runs at "Game FPS" around 60 and for each iteration goes and fetches what's in the buffer (optionally being picky about characteristics). That way we don't miss anything like the current implementation does (it only retrieves one Leap frame per game frame so it misses around 50%)
It works to where the code on the Terasology side (after the Jitter stuff gets split out into its own jar) is minimal, like so:
That little "2" asks for only CircleGestures that have run the full two circles to be retrieved, anything less mature than that is ignored. After the second circle is completed a valid gesture is retrieved and processed. Now just need to do that for everything ...
Trouble right now is that after working once (or when running in debug) something flips out and causes execution to go funny. An if statement that is clearly false somehow lets execution not only inside but straight into an inner if completely skipping a log statement in between ... might be a debug quirk due to the Leap still being active and having native code fun going on.
Too late tonight to polish, but even though I'm sure there are tons of architectural faux pas in the setup I'm strangely happy with how it is turning out
At SDK level 0.7.7 hand tracking seems rock solid now, which was the biggest issue in the past. New utility methods in this release also offers finding the left-most and right-most hand, which might replace us detecting that manually partially or fully. New stuff also includes being able to set the min sensitivity for gestures to trigger (say configuring circle gestures to run at least one whole circle before being sent out)
I got an initial use case for the Jitter lib worked out and I'm fairly happy with it, especially considering how badly I suck at Java
In short Jitter uses an internal Leap listener that runs at the "Leap FPS" somewhere in the 100-120 range. It then (for now) triggers method callbacks for specific gestures to an external JitterListener interface. That's kinda boring but might expand to where it alone provides some utility.
What makes it really interesting (IMHO) is the layer on top of that. I made a BufferedJitterSystem that implements JitterListener, but as the name indicates it buffers the input in local variables. In the meantime our main loop runs at "Game FPS" around 60 and for each iteration goes and fetches what's in the buffer (optionally being picky about characteristics). That way we don't miss anything like the current implementation does (it only retrieves one Leap frame per game frame so it misses around 50%)
It works to where the code on the Terasology side (after the Jitter stuff gets split out into its own jar) is minimal, like so:
Code:
for (CircleGesture circleGesture : jitterBuffer.nextCircleBatch(2))Trouble right now is that after working once (or when running in debug) something flips out and causes execution to go funny. An if statement that is clearly false somehow lets execution not only inside but straight into an inner if completely skipping a log statement in between ... might be a debug quirk due to the Leap still being active and having native code fun going on.
Too late tonight to polish, but even though I'm sure there are tons of architectural faux pas in the setup I'm strangely happy with how it is turning out
Update: I've pushed the Jitter lib to GitHub and tested its jar file with Terasology, although still with the limited Jitter branch that doesn't have our "full" Leap prototype implementation. The excellent part is that this brings the buffer-based approach within reach and the Leap SDK has matured nicely since the prototype.
No obstacles other than time to implement stand in the way for a nice Leap integration now. Hopefully we'll be able to encourage other contributors to help with the Jitter lib to aid that a bit. I won't be able to move it forward more for a few weeks since I'm going on vacation. Looking forward to messing with it more again after that, although there are higher priority Terasology tasks to follow-up on as well
I'm going to put some stuff in the Jitter issue tracker and see what happens
No obstacles other than time to implement stand in the way for a nice Leap integration now. Hopefully we'll be able to encourage other contributors to help with the Jitter lib to aid that a bit. I won't be able to move it forward more for a few weeks since I'm going on vacation. Looking forward to messing with it more again after that, although there are higher priority Terasology tasks to follow-up on as well
I'm going to put some stuff in the Jitter issue tracker and see what happens