<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=us-ascii">
<TITLE>Message</TITLE>
<META name=GENERATOR content="MSHTML 8.00.6001.18812"></HEAD>
<BODY bgColor=#ffffff text=#000000>
<DIV><SPAN class=015030310-26092009><FONT color=#0000ff size=2 face=Arial>Hi
Florian,</FONT></SPAN></DIV>
<DIV><SPAN class=015030310-26092009><FONT color=#0000ff size=2
face=Arial></FONT></SPAN> </DIV>
<DIV><SPAN class=015030310-26092009><FONT color=#0000ff size=2 face=Arial>Thanks
for this review. I'm surprised by the comment on one core being completely busy
during animation playback/record. I had exactly opposite experience when testing
complex armature: with old solver: 100% busy, with itasc: 8%
busy.</FONT></SPAN></DIV>
<DIV><SPAN class=015030310-26092009><FONT color=#0000ff size=2
face=Arial></FONT></SPAN> </DIV>
<DIV><SPAN class=015030310-26092009><FONT color=#0000ff size=2 face=Arial>I can
answer your question about pose flipping when you change a target in 3D view:
any modification of an object position causes the dependency chain to
be 'flushed'. This means that the armature, which depends on the
target, will receive a 'cache flush' request and the entire history of the
solver is cleared. As a result, the solver doesn't have a past position anymore
to compute the current pose, and starts from the rest pose, causing possible
flip. Once you replay the animation in full, the cache will rebuild
automatically and you get the correct dynamic
again. </FONT></SPAN></DIV>
<DIV><SPAN class=015030310-26092009><FONT color=#0000ff size=2
face=Arial></FONT></SPAN> </DIV>
<DIV><SPAN class=015030310-26092009><FONT color=#0000ff size=2 face=Arial>I
didn't find a simple solution to this problem yet. One possibility is to
use the current pose instead of the rest pose as the start point in case
past history is missing in the cache, but that would create a dependency on
future when playing an animation in loop. Another possibility is to rebuild
the cache in full each time the cache is flushed, but that's not viable
performance-wise. A third possibility is to use the pose from Fcurves as a start
point instead of the rest pose. These Fcurves would be automatically updated
(inserting key frame for all bones) when modifying targets. </FONT></SPAN><SPAN
class=015030310-26092009><FONT color=#0000ff size=2 face=Arial>This is probably
the best option but requires actions on Fcurves that I'm not familiar
with. </FONT></SPAN></DIV>
<DIV><SPAN class=015030310-26092009><FONT color=#0000ff size=2
face=Arial></FONT></SPAN> </DIV>
<DIV><SPAN class=015030310-26092009><FONT color=#0000ff size=2 face=Arial>I'll
do some experiment as soon as possible. For the time being, you need to play the
animation each time you change something on the armature.</FONT></SPAN></DIV>
<DIV><SPAN class=015030310-26092009><FONT color=#0000ff size=2
face=Arial></FONT></SPAN> </DIV>
<DIV><SPAN class=015030310-26092009><FONT color=#0000ff size=2
face=Arial>/benoit</FONT> </SPAN></DIV>
<DIV><SPAN class=015030310-26092009> </SPAN></DIV>
<BLOCKQUOTE
style="BORDER-LEFT: #0000ff 2px solid; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; MARGIN-RIGHT: 0px">
<DIV></DIV>
<DIV dir=ltr lang=en-us class=OutlookMessageHeader align=left><FONT size=2
face=Tahoma>-----Original Message-----<BR><B>From:</B>
robotics-bounces@blender.org [mailto:robotics-bounces@blender.org] <B>On
Behalf Of </B>Florian Lier<BR><B>Sent:</B> samedi 26 septembre 2009
10:42<BR><B>To:</B> Blender and Robotics<BR><B>Subject:</B> [Robotics] Itasc
branch review<BR><BR></FONT></DIV><FONT size=-1><FONT
face="Helvetica, Arial, sans-serif">Hey all,<BR><BR>finally I found some time
to compile and test the itasc branch.<BR><BR>- Some notes - <BR><BR>Test
system:<BR><BR>Ubuntu 9.04 32 Bit<BR>Intel QuadCore 3,2 Ghz<BR>4 GB
Ram<BR>NVIDIA 8800 GTX 512 MB with NVIDIA prop. driver<BR><BR> ":("<BR>1)
With Compiz/3D effects enabled the game engine seems to run pretty
unstable<BR>2) Compiz also seems to mess up the menues like "Armature" "Bone"
or "Contraints" Menue (screenshot: <A class=moz-txt-link-abbreviated
href="http://www.icram.de/itasc_scale.png">www.icram.de/itasc_scale.png</A>)<BR>3)
When recording an animation and replaying it one core is completly busy
(100%)<BR><BR><BR>":)"<BR>1) The menu-settings for the IK are pretty nice and
clearly arranged<BR>2) The solver works very well and seems to be
smarter/smoother than the "normal" solver<BR>3) The scons installer works
flawlessly<BR><BR><BR>That's the my first impression on the current itasc
branch. I compiled it myselft - I didn't<BR>use the binaries provided by
benoit.<BR><BR>Here's a small video showing the demo: <A
class=moz-txt-link-freetext
href="http://vimeo.com/6761002">http://vimeo.com/6761002</A><BR><BR><BR>A
general question: When moving the IK chain controlled by an EMPTY (target) in
3D View <BR>the solver sometimes "jumps" from pose A to pose B. During
replaying and animation the solver<BR>doesn't jump that much - so why is that?
<BR><BR>Cheers, Florian<BR><BR>P.S. @itasc guys: Pretty nice valueable work by
all means!<BR></BLOCKQUOTE></FONT></FONT></BODY></HTML>