0
\$\begingroup\$

I have this partially working already, but my implementation doesn't animate very well (lots of jitter, some random movements) and I thought that you guys in Game Development might be able to point me in the right direction.

  1. I have a "Listener" application that listens to updates from the Kinect, finds the object in the frame, and sends an update of that objects location. (I just care about x/y in my case, not the z axis)
  2. In a separate "Projector" program I listen for that update, and update the actual position of the object in my model.
  3. In the "Projector" program there is also a rendering thread, triggered once per screen update, that attempts to move the projected object smoothly along the path of the real object using that model. (trying to project the image on top of the real object)

The problem I need to solve is: How do I track the object's real location with my projected object in a way that animates smoothly?

The kinect updates the location at 30 FPS, the render cycle happens at 60 FPS (on a ui thread), but I'm trying to project on top of my object as best I can while keeping the rendered image moving smoothly. (right now it tracks with the object but jitters quite a lot) I came across http://gafferongames.com/game-physics/integration-basics/ on the RK4 algorthim, which is probably more complex than I need but I wasn't able to implement it correctly for my case. (likely because I don't fully understand it)

\$\endgroup\$
  • \$\begingroup\$ This is a very broad question. I would be surprised if you got that far without knowing the word "interpolation", but I've been surprised before! \$\endgroup\$ – Alec Teal Sep 26 '15 at 19:05
  • \$\begingroup\$ Euler, Verlet, and RK4, I've googled it enough to come across these terms, but actually implementing them in a scenario like my own is much harder. (I can get a sample to work, but I don't completely understand the math involved so have been unable to modify them to fit my needs) \$\endgroup\$ – millejos Sep 26 '15 at 19:09
0
\$\begingroup\$

I wanted to post what I have so far in case anyone else comes across this question, apparently: It is very important that all calculations are based on the same time step! In my case I have two separate threads:

  1. Process data from the kinect
  2. Render stuff on the screen

I did not have these two separate threads synchronized very well, which turned out to be a lot of the reason for my jitter. I fixed this by creating a central timer, picking an arbitrary heartbeat (33 milliseconds), and calculating everything based on where it fell in relation to that slice of time. For example if I got a Kinect message at 40 milliseconds, I'd back-calculate the location to where it would have been at the 33 millisecond mark, 7 milliseconds ago. In my render cycle I then calculate how long it's been since the last heartbeat to determine current render location.

And no, I haven't figured out the best way to project kinect movement into the future, I'm just using the previous [velocity] x [time] right now, sorry. I may look into how you calculate the overall trend in velocity to get a more accurate prediction.

\$\endgroup\$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.