[sldev] Body motion and facial expression tracking, Microsoft did it
Jan Ciger
jan.ciger at gmail.com
Sun Jun 7 06:07:09 PDT 2009
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi Dahlia,
Dahlia Trimble wrote:
> Impressive video.. I liked the part where he grabs the beer.
Thanks. Or rather that should go to my ex-colleague Tolga who has done
the automatic grasping for his PhD.
> Most of my experience with IK animation is using tools such as 3DS Max
> and blender. I have done a small bit of procedural animation in SL, here
> are a few examples:
>
> http://www.youtube.com/watch?v=VqdeEIa_Ehs
>
> http://vimeo.com/946012
>
> all calculations are done in real time in both of those videos. And yes,
> those are simulated joints ;)
Nice, that is a cute hack. Didn't see this done before. I guess the sim
owners are going to hate you for the load these scripts have to produce :-p
Re Max/Blender - that is a different issue, and apples to oranges
comparison. There you get realtime IK but with only one end-effector
moving at a time (e.g. hand), and it is heavily constrained, typically
in 2D plane aligned with your camera view where you are dragging it. You
do not have that luxury when animating something like that beer grasping
(the solver needs to work in all 3 dimensions at the same time).
Also, you have other issues adding complexity - e.g. maintaining balance
of the character. If you are reaching for something far away, you will
stretch out your leg to keep your center of mass above your other leg -
otherwise you would fall over. The IK in the beer video can actually do
that (look at the other IK videos at the website - it is the same IK
solver), but I have never seen something even close to that in Max or Maya.
This is also why the simplistic approach with "only modifying existing
animation and locking/weighting down joints" as Argent described
wouldn't work - if you lock down the feet ("I am only reaching for
things!"), you either wouldn't be able to find the solution (with the
VRlab's solver and the balance constraint on) or it would look
completely wrong once the object is out of arm's range and you need to
bend over to get it.
> There is a crude form of synchronization of animations in SL now, it's
> usually used in "couple animating poseballs". It assumes that animation
> sequences have been cached by both viewers and the animations will both
> start within a close tolerance. There is no start time designated in the
> signal, the viewers respond when the start message is received so any
> delays will reduce the quality of the synchronization.
Well, that is not really any synchronization. I am speaking about
frame-by-frame sync, or at least synchronizing every few frames with
interpolation between. The poseball animations will drift apart after a
few seconds, no matter what you are doing.
Regards,
Jan
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mandriva - http://enigmail.mozdev.org
iD8DBQFKK7t6n11XseNj94gRArXyAJ4/oEhlBjCE3BXeCyWNTOPYafmSsgCfQ2Fh
c/vnrhwgtZq6IJ4/6DL29c8=
=ceeb
-----END PGP SIGNATURE-----
More information about the SLDev
mailing list