Popping and errors when recording

Hallie · 23 February 2024 19:17

Hello!

We’ve been having some weird recording results and errors when recording. The preview markers look great before recording, but once the simulation is recorded onto the controls, there’s a lot of flipping occurring, and translations that I wouldn’t expect.

We’re working with a challenging springy, accordion-like rope, so the setup is a bit special; I’ve got a video showing the setup but I’ll also describe it here. The rig itself is a spline with a ton of joints and a few controls. I assigned a marker to each joint using ‘Assign’ rather than ‘Assign and Connect’, so the joints wouldn’t be parented together. This way, I could set all their overlap values to 10, and the markers could overlap without colliding when the rig squashes or stretches. I’m keeping the markers pinned close to their joints via Pin constraints, which are all hooked up to multiply-divide nodes so the animator can dial them stiffer with the Pin Value attribute on the ragdoll control hovering above the arm. All the joints are untargeted except for the few joints that correspond to a rig control; those are retargeted to the rig controls. In hindsight I see that the untargeted markers aren’t necessary, but I don’t think that’s what would be causing the recording issues (please correct me if I’m wrong!). All of the ragdoll elements are outside of the rig hierarchy (solver, groups, and pins) in case that was causing any problems. The first and last markers are set to ‘Animated’ to keep the ends of the rope stable.

Video with the rig setup:

With this setup, when previewing, the markers stay very close to the original keys, just adding that extra jiggly spice. But when we go to record, the markers have major flipping and strange translations on them, causing all sorts of popping and undesirable shapes. You can see these in the next video. I’ve tried recording only in translation, recording without the euler filter setting, and on an override layer instead of an additive layer. We’ve also tried it on two versions of ragdoll: I’m on 11.20.2023, my coworkers on 2.10.2024 with the same results. I thought maybe it was due to the markers and controls they were retargeted to having different orients, but when I adjusted those markers, I got the same result.

Video of the popping recording:

Another thing to note is: whenever I record, my recording ends at 95% with a warning. The rSolverLayer still records, but in another forum topic I saw that it was at 95% was when the euler filter gets applied, so that may be a lead?

Any help on this would be amazing; we’re really excited about the marker preview results, and want to get it on our rigs!

marcus · 24 February 2024 10:34

Hey @Hallie, thanks for the detailed description of your issue, this helps narrow down things by a lot.

The error in the Script Editor seems like an issue with our code, I’ll patch that up on Monday. It won’t affect the recorded result, and would simply leave it as “Override” which is the default.

For the popping, the first step in debugging this would be to try Ragdoll → Utilities → Extract Simulation. This will record the simulation onto a new set of Maya joints you can use to compare with. These should match the simulation, and is a good first step to see where the problem lies.

From there, try the option inside of the Extract Simulation option UI to “Attach”. This will perform the next step in the recording process, of constraining your controls onto those extracted joints. I expect this is where you will start to see your popping problems. And it’s here you can have look at any of your popping controls to see what the constraint for that control is doing.

Hallie · 24 February 2024 16:26

Thanks for looking into that error Marcus!!

I tried debugging via Extract Simulation, and here are my results:

Without attaching the controls, the new sim joints stay very close to the original joints, the way I would expect them to. There’s a few joints that fly away a little bit, but I would expect that using pin constraints. They may be colliding with the geo at the end of the rope, which isn’t part of the overlap group. I’m not seeing any popping from the joints, either.
When I do attach the controls, the new sim joints are suddenly way off the mark in terms of what we were seeing before. Curiously, the controls don’t seem to be flipping or popping, but they’re still not where I would expect them to be. I noted that there’s quite a large offset on the orient constraints under the controls; not sure if that’s normal or not, so wanted to note it.

To me, this looks like there’s doubling influence; the controls aren’t directly constrained to each other, but if you move one, the others follow it with a falloff. I’m wondering if that’s causing the difference in positions? What do you think?

The Extract Simulation tool is great for debugging, thanks for showing me that!!

marcus · 25 February 2024 09:55

Hmmmm, it’s suspicious that each extracted joint is unparented. They should form a hierarchy. Are these markers not connected? Are they not soft via Translate Motion: Soft?

If you:

Make a joint hierarchy of e.g. 4 joints
Assign and Connect
Extract Simulation

The resulting extracted simulation should be an identical 4-joint hierarchy. But in your case, they are not, but do have the length of one which makes it appear as though they form a hierarchy in the viewport.

Could be a clue, any thoughts?

Hallie · 26 February 2024 02:13

Hey Marcus!

You’re correct, my markers aren’t parented/connected to eachother. I set them up using ‘Assign’ rather than ‘Assign and Connect’ and never parented them, because I wanted to set their overlap group to 10; due to the squashing and stretching of the rig, I needed the markers to be able to overlap. I found that if they were directly parented to eachother, changing the overlap group number never allowed them to overlap, nor did turning off self collisions. The markers all have their translation motions set to ‘locked’, rotate stiffness ‘0’, and are kept pinned to the animation with pin constraints.
To make sure everything’s working fine, I extracted the simulation of four parented joints like you suggested and the new sim joints did generate parented in a hierarchy.

Do you think it’s because they’re unparented, that they flip and pop? Is there a way to get parented joints to overlap?

marcus · 26 February 2024 09:46

It’s quite likely this is the problem yes. Ragdoll needs to figure out the final local translation/rotation for each control and when they are all in worldspace there are situations where it struggles. There’s a built-in mode to do this internally, to cope with closed loops, and it has similar artefacts.

I would:

Parent them in the order the are parented in Maya
Give them all a common group
Disable self-collision

No self collision is identical to giving them all the same overlap group, which it’s doing internally. So that should also work, anything else is a bug and bugs are not allowed in Ragdoll. If you can provide some step-by-step to reproduce that issue, I would love to squash it.

Here’s what you should expect from translate motion, without self collision.

marcus · 27 February 2024 10:42

Just in case it wasn’t obvious, it might not be, you can Reparent your Markers without redoing any assigning.

Select child
Shift + select parent
Ragdoll → Edit → Reparent

You can also manually (via e.g. Python or Node Editor) connect a marker to the parentMarker attribute which does the same. That way, you won’t have to redo that rig, which looks like it could take a while.

Hallie · 27 February 2024 15:00

Sorry for the late reply!

Re-parenting the markers together did the trick! It also helped when I switched to making the markers from the controls, rather than from the joints and retargeting them onto the controls. I’m no longer seeing any popping!

I didn’t realize that I needed to set the translate motion to ‘soft’ to get overlap on parented markers. It’s working perfectly.

Thank you so much for your help, and showing me those great debugging tools!

marcus · 27 February 2024 15:12

Woho! Great news.

Yes, per default no translation is permitted between Markers, the “Soft” option permits it and takes into account the Translate Stiffness and Translate Damping attributes to control how much.