1
$\begingroup$

Edits at bottom There is more going on here than meets the eye. I think I have found that there are some bugs in the object solver constraint. It is giving weird behavior in test scenarios. It is not working on bones at all in new files. When applied to an object, it works fine, however baking the keyframes to an F-Curve results in only the first 31 frames being baked. It's all just a little too weird to not be a bug.

A video describing and demonstrating my current problem: https://youtu.be/bzN80ge6_3A

Part of a longer video here: https://youtu.be/gXzgZ0-_Ncs


Ok, so I shot footage of a specially rigged puppet for motion tracking in 60p in hopes that when I use the motion tracking data in a 24p project those subframes would allow for a more fluid look in the motion blur, etc.

Basically, packing those 60 keyframes from one second of tracked footage into 24 frames in 1 second of animation. Hopefully that makes sense.

It would be subtle differences, to be sure, but it seemed like it would be straight forward. Boy was I wrong.

The tracking of the puppet itself worked great! With a little tweaking, our 3d character moves just like the puppet! If we rendered it out at 60p, we'd be golden! Unfortunately, we want 24p instead.

Yes, I could conform my footage from 60p to 24p, or re-shoot all the footage but that would be hours of redoing all of the tracking work we've done on all the clips (yes, we should have done more testing on our method first. It just seemed like it should be so easy to remap the timing of the motion tracking data, how could it not work? LOL.) Of course I've spent hours trying to figure this out, so maybe I should just cut my losses and redo it all in 24p!

So here's what I've tried.

Time Remapping:

Settings: Old:60 New:24

This actually works, except for the baked cloth simulation, which does not respect the time remapping. The cloth reacts as if it were on the original timing of the mesh. It is still correctly simulated, (ie. it's not going bonkers as the arms move through the cloth), it's just baked on the previous timing so that the cloth is running at 40% speed [24/60] and therefore as his arms move, the cloth moves much later.

Keyframes

Ok, I'll just bake these constraints to keyframes and scale them I thought.

This should work, except for one problem. When I hit bake constraint to F-Curve I get this message: Motion Tracking constraint to be converted not found

I don't know if this is a glitch, or something I've done wrong, but I have object motion tracking constraints on the control bones. They follow the movement of the different parts of the tracked puppet. Hands, feet, head, Body etc. This works great as a constraint, albeit it still in 60 frames per sec! I now need to remap their keyframes from the 60/sec to 24/sec by scaling them by 0.4. To do that I have to back them to an F-Curve, and then I run into the above problem.

So, I have issues doing it one way, and I have an issue doing it another. I posted this in its entirety so that someone may have some insight into another solution. If I don't have an answer soon, we'll just redo it in 24p and I'll submit a request to the Blender team to be able to remap the motion capture data to a different frame rate!

Thanks, and happy Blending!

-Matt

EDIT So when trying to recreate the error of tracking a bone to an object solver and then not being able to bake that constraint to an F-Curve, I found that I could not even get the bone to react to the constraint in a simple test set up.

I have a camera solver applied to the camera (a sometimes overlooked prerequisite of an object solver) and when I apply the same object solver as I used on the bone to a cube, it reacts as it should. Very weird indeed.

So maybe I have discovered a weird bug, or an intended regression where object solvers are no longer allowed on bones. I'm really not sure.

This may explain why I get the Motion Tracking constraint to be converted not found error in my original file. However, the constraint works in my old file, and just cannot be converted to keyframes. In my new test, the constraint doesn't even work. Very weird indeed.

$\endgroup$
  • 1
    $\begingroup$ Does the title imply there's been a harsh discordant mixture of sounds of frustration .. lol. $\endgroup$ – batFINGER Jan 3 '18 at 18:02
  • $\begingroup$ That could definitely describe my situation. Lol. $\endgroup$ – Blazer003 Jan 3 '18 at 18:47
  • 1
    $\begingroup$ Just a thought: export softbody in some sort of cache (alembic, etc.) and stick with time remap $\endgroup$ – Serge L Jan 3 '18 at 21:09

Your Answer

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

Browse other questions tagged or ask your own question.