• Next Thread Prev Thread

• Posts   Search Threads

• jbrindle July 10, 2009 10:49 AM PDT    Skeleton Constraints - "Lock Translations" Hi. We are trying to take two skeletons and apply the same animation to both of them. Both skeletons have the same number of bones, in the same order The only difference is that one has translated the bones to a different location. The animation is exported using the original (non-translated) skeleton.  When we apply that to the non-translated skeleton, it looks fine. The animation is then applied to the skeleton with translated bones.  The animation of the root bone seems to pivot around where the non-translated position would be. I think what we need is the "lock translation" constraint.  If I understand it correctly, this should lock the translation of the skeleton, so only rotations are applied to the bones.  Am I correct in this understanding? If so, how do I set that the skeleton should use the bone constraints and export it like that?  When I export the skeleton and use View XML filter, I see that the "lock translation" field is always false. I think I use the enforceSkeletonConstraintsLocalSpace and enforceSkeletonConstraintsModelSpace functions to make Havok use the "lockTranslation" field, but if they are all set to false, that won't have much effect. I am using Havok r 6.00 r1. Any help would be much appreciated.  Thanks in advance! jbrindle July 10, 2009 11:27 AM PDT Rate   #1 Re: Skeleton Constraints - "Lock Translations" I found the hkaSkeletonUtils::lockTranslation function which seems to set the bones to have locked translations. However, when I then call enforceSkeletonConstraintsModelSpace (or local space) I get some asserts: Here is the output window: HAVOK: .RighkaPose.cpp(368): [0x5A3281F6] Assert : 0 Invariant failed : both local and model transforms dirty for bone 2 HAVOK: e:RSYSBuildcodePcXsPerpetualKeycodeSourceCommon/Base/Memory/StackTracer/Impl/hkStackTracerWin32.cxx(91): [0x44B27798] Assert : initsymbols The call stack looks like this: test-d.exe!hkStackTracer::hkStackTracer() + 0x503 bytes test-d.exe!hkDefaultError::showMessage() + 0x7b bytes test-d.exe!hkDefaultError::message() + 0x92 bytes test-d.exe!hkaPose::checkPoseValidity() + 0x1cc bytes test-d.exe!hkaPose::enforceSkeletonConstraintsLocalSpace() + 0x232 bytes I hope that helps. I have a feeling I'm just not calling things in the right order, but I'm not sure what the order should be. I also get this assert: HAVOK: .RighkaPose.cpp(382): [0x5A3281F4] Assert : 0 Invariant failed : m_localInSync is true but some local transforms are dirty HAVOK: e:RSYSBuildcodePcXsPerpetualKeycodeSourceCommon/Base/Memory/StackTracer/Impl/hkStackTracerWin32.cxx(91): [0x44B27798] Assert : initsymbols with call stack: > Elemental-d.exe!hkStackTracer::hkStackTracer() + 0x503 bytes If I don't call hkaSkeletonUtils::lockTranslations,  then I don't get any of these asserts, but the skeleton translations arent locked either :( jbrindle July 14, 2009 7:06 AM PDT Rate   #2 Reply To #1 Re: Skeleton Constraints - "Lock Translations" (bump) Any ideas? havokjasong July 14, 2009 10:14 AM PDT Rate   #3 Reply To #2 Re: Skeleton Constraints - "Lock Translations" Hi jbrindle, Sorry for the late response.  We had a release this past week that kept us all a bit swamped.  I'm going to look into this today, and get back to you a little later. Jason G. Jason Gorski Developer Support Engineer Havok™ 2008 Emmy Award Winner \"Turning Creative Aspirations into Technical Realities™\" www.havok.com havokjasong July 14, 2009 11:39 AM PDT Rate   #4 Reply To #3 Re: Skeleton Constraints - "Lock Translations" Hi jbrindle, It looks like you are attempting what we call "animation retargetting." We are actually rolling out this feature in future versions of Havok (Check out these YouTube videos of it: http://www.youtube.com/results?search_query=animation+retargetting&search_type=&aq=f). You have a pretty simple case, though, which perhaps we can get working for you. First off, you can lock the bones automatically from the Content Tools in the Create Mapping Filter (not sure if this is in the 6.0 content tools). This essentially calls hkaSkeletonUtils::lockTranslations. Note that this method does not lock the root bone from translating. By just calling this function, I would expect your translated skeleton would skill appear at the location of the source skeleton. Is this the case? Let me also say, that bone locking is typically used in terms of enforcing ragdoll/animation skeleton coherance. When you have a ragdoll that is mapped to an extreme animation, or you want to map from a ragdoll back to an animation skeleton, you often want to have locked translations. This prevents the ragdoll/animation skeletons from having bones that get translated in undesireable ways. I have not seen people use it for this purpose. I actually haven't seen people use these methods directly. The assert you are getting deals with the way hkaPose attempts to lazily keep it's representation up-to-date. For performance reasons, it doesn't keep everything up to date until needed. It's complaining, at the end of the enforce call, that there is no valid representation that is up to date. There are lots of hkaPose methods which will set dirty flags on individual bones, or the pose as a whole, for model & local space respectively. Now, I'm not sure why you are hitting this assert. I'd have to know more about the other calls to hkaPose you make prior to the enforce call. Can you give me some more surrounding code? I would suspect what you would want to do is simply: hkaPose pose (animatedSkeleton->getSkeleton()); animatedSkeleton->sampleAndCombineAnimations( pose.accessUnsyncedPoseLocalSpace().begin(), pose.getFloatSlotValues().begin() ); pose.enforceSkeletonConstraintsLocalSpace(); You might try using the hkaSkeletonUtils version of these calls (hkaSkeletonUtils::enforcePose/SkeletonConstraintsLocal/ModelSpace). We use these methods at the end of calls to hkaSkeletonMapper::mapPose() and they won't have the asserts you are hitting. But it might also just mask the problem. So maybe you can post some surrounding code. I'll also try to dig in a little more on this end. Jason G. Jason Gorski Developer Support Engineer Havok™ 2008 Emmy Award Winner \"Turning Creative Aspirations into Technical Realities™\" www.havok.com

• = Best Answer

  Next Thread Prev Thread

Intel Software Network Forums Statistics

17,025 users have contributed to 48,317 threads and 172,754 posts to date.

For more complete information about compiler optimizations, see our Optimization Notice.