Hey Marcus, Snap to Simulation is completely bugged out for me. It doesn’t snap at all, and it says certain bones are skipped because recordTranslation and recordRotation was both disabled. I have checked the markers and that’s not the case.
Both videos show the problem. I think the second video is clearer. You can just watch one of them.
Steps to reproduce this bug:
- Assign markers to some bones
- Disable Record Translation on the bones
- Snap to Simulation
This is the error log.
Python: Traceback (most recent call last):
File "C:\Users\user\AppData\Roaming\Blender Foundation\Blender\4.1\scripts\addons\ragdoll\operators\snap_to_simulation.py", line 43, in execute
commands.snap_to_simulation(solver)
File "C:\Users\user\AppData\Roaming\Blender Foundation\Blender\4.1\scripts\addons\ragdoll\commands.py", line 393, in snap_to_simulation
transfer(dst)
File "C:\Users\user\AppData\Roaming\Blender Foundation\Blender\4.1\scripts\addons\ragdoll\commands.py", line 301, in transfer
handle.matrix_basis = armature.convert_space(
^^^^^^^^^^^^^^^^^^^^^^
AttributeError: 'NoneType' object has no attribute 'convert_space'
Ragdoll: chestUpper skipped because recordTranslation and recordRotation was both disabled.
Ragdoll: chestLower skipped because recordTranslation and recordRotation was both disabled.
Ragdoll: abdomenUpper skipped because recordTranslation and recordRotation was both disabled.
Ragdoll: abdomenLower skipped because recordTranslation and recordRotation was both disabled.
Edit: I discovered turning both “Record Translation” and “Record Rotation” on makes it work again, but that’s not really a solution. Maybe this can provide a hint to where the bug is.
Great report, this is how it’s done! 
Because of the detail and clear demonstration, implementing a fix is quick and easy. Let me know how it goes.
Ragdoll Blender 2024.05.21
Thank you. I’m getting better at explaining a problem :D.
This patch seems to work fine for me. I think you fixed a few more problems too. Wonderful.
1 Like
Wait sorry, I spoke too soon. The patch fixed the bug of it mistakenly skipping recording markers, but Snap to Simulation still applies location and rotation on the original bones even if they are untargeted or retargeted from. And it doesn’t apply location or rotation on the retargeted bone (the pole target) from my testing. I also tried Retargeting with Record Simulation, and sometimes it doesn’t work.
Untargetting bug
Steps to reproduce:
- Assign markers to some bones
- Untarget a marker
- Pose the markers in Live Mode
- Snap to Simulation
- Check if the untargeted bone is moved
Retargetting bug
Steps to reproduce:
- Assign markers to some bones
- Retarget a marker to another bone
- Pose the Markers in Live Mode
- Snap to Simulation
- Check if the retargeted bone is moved
Hm, can you elaborate a bit more on what you expect should happen?
If it doesn’t apply the location and rotation to the untargeted bone, all other bones would also be in the wrong location since they are a child of that one. So in effect, untargeting a parent would effectively untarget all children too. Is that what you are looking for?
I didn’t record the comparisons with Record Simulation in the same setup to keep the video short. I’ll post another video later to show you the comparison, but no, that’s not the intended behaviour. The problem with applying locations/rotations to the untargeted bone is, in some rigs, the FK bones are the deform bones. If the markers, which are first assigned to FK bones before they are untargeted or retargeted to IK bones, apply location/rotation to the untargeted FK bones, it breaks the rig.
Edit: So the intended behaviour is just that locations and rotations do not get applied to untargeted bones, or bones that have been retargeted from.
Ok so, 3 videos in total. I tried to keep them as short as possible. You can just watch the last one because it shows the problem directly. The other 2 videos are just to show the intended behaviour.
Untargeted bone
As you can see, the untargeted bone does not move while its children do. That is my intended behaviour when I use Snap to Simulation. But it actually doesn’t matter if its children move or not. All I need is that the untargeted bone does not move.
Retargeted bone
Same as before, the bone that was retargeted from, i.e. the original bone that the marker was assigned to, does not move. The location and rotation of the marker should also be applied to the retargeted bone with Snap to Simulation, which it doesn’t, as shown in the video two posts before.
Problem in real use case
https://youtu.be/PZHNdOmrtGc
I set up the markers for like you did in the previous tutorial. I first assigned the markers to the FK bones, then untarget the upper arm, and retarget the lower arm to the pole target. Snap to Simulation and the problem appears. The applied location and rotation to the untargeted FK bones messed it up completely.
Thanks, I see what you mean.
This will take longer, and might have to wait till next release cycle. Transferring the simulation from the beginning is fundamentally different from transferring it from a given fixed point in time. When recording, we have the benefit of knowing that on the first frame both rig and simulation line up perfectly. With Snap, we don’t have that and the current implementation works differently to try and make the seem similar.
I’ll keep you updated. Till then, some options:
- Build an armature specifically for Live Mode and transferring of simulation onto, this could then be used to drive your rig
- Record up until the frame you want to transfer to, and delete other keys
- Extract Simulaton with
Attach enabled and manually keyframe the controls at the time you want.
Oh no worries, I’m happy knowing we’ll get better tools later :D. You had me realllllllllly hooked up when you said you were looking to replace the traditional posing workflow completely in the Blender forums. I really want to see how posing or animation will be like in the future.
Right now Live Mode works perfectly fine with just FK bones. I think I’ll probably stick to that.
Yes, and the kicker is that once the Live Mode tools are ready, you won’t need anything but an FK hierarchy for any character.
2 Likes