Intel® Software Network

HAVOK: .\Rig\hkaPose.cpp(368): [0x5A3281F6] Assert : 0
Invariant failed : both local and model transforms dirty for bone 2

HAVOK: e:\RSYS\Build\code\PcXsPerpetualKeycode\Source\Common/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: .\Rig\hkaPose.cpp(382): [0x5A3281F4] Assert : 0
Invariant failed : m_localInSync is true but some local transforms are dirty

HAVOK: e:\RSYS\Build\code\PcXsPerpetualKeycode\Source\Common/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 :(

(bump)

Any ideas?

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.

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.