First off, I realise this is not the optimal workflow, but I’m kind of backed into a corner right now, so here’s my question…
I have multiple long sequences, sometimes over a minute long, with Motion Capture Characters all implemented into a pipeline to Unreal Engine. I am tasked with Simulating all the dangly Jangly bits such as cloth and necklaces in which I’m using Ragdoll. Problem is, during Layout, an artist has been snapping characters to new locations between shots, therefore Ragdoll Markers go completely bonkers after these teleportations.
Is there an elegant way to handle these types of oversights? Perhaps ‘resetting’ ragdoll on certain frames? Or Freezing the current state of a simulation over a couple of frames, then unfreezing?
I’ve tried keying all to Kinematic, but Ragdoll seems to remember the sudden change of position even after a few frames… Is it really going to be a case of simulating each ‘part’ individually between pops?
Thanks in advance
Setting an entire character to Kinematic and then back to Dynamic should do the trick. Is it possible that it only had 1 frame of Kinematic to work with? Try 2 or more frames.
The velocity of the Markers on the frame where it becomes Dynamic again is based on the difference between 2 frames. So if it starts at X=0 and then to X=100 once it goes from Kinematic to Dynamic on the next frame, the velocity will be 100 units per frame.
Hey Marcus! Thanks for the reply and information.
I don’t think the Kinematic vs Dynamic switch is going to work due to the sudden stops and snaps back to the original control positions essentially re-setting the Sim. I need it to freeze in it’s current state for 1 frame and then continue where it left off. I think I am going to have to simulate per ‘part’ and bake several times over the sequence duration…
There is 1 thing that might be worth considering though… When baking a simulation to a layer, that layer is by default set to Override. This means Previous bakes are essentially hidden whilst the new bakes are active. My solution for this is to Key the Layer weights on and off for when I want each bake to be visible. I can then merge all the bake layers when I am finished.
What might be nice is if there was an option to bake a simulation to an ‘Additive’ layer, rather than Override by default.
Anyway, thanks again for the advice. Really appreciate the speedy responses
Alternatively, if there was a way to ignore velocity for 1 frame, that would be infinitely easier?
Resetting the sim and ignoring velocity for a frame is what animating Kinematic → Dynamic should already be doing. I might be misunderstanding your scenario, would it be possible to post an example video? Of either what you have right now, or of a simplified version that can be shared online in public.
I think you are right Aiden, pausing simulation for a frame is different than re-setting the simulation.
If you reset the simulation all the danglies will start with zero velocity and take time to settle and move naturally - always a problem with dynamic sim that you need pre frames often times. Your example of a continuous move with a teleport in the middle, would be much easier to simulate before the teleport was added.
I can’t see a neat way to achieve what you want - your solution of simulating parts and baking it is probably simplest. You could write a script to add (or remove) X frames - Maya isn’t the fastest at dealing with multiple characters and long animations though, so it would be a bit clunky.
Let’s get some pictures in here so we can ensure we are referring to the same thing.
In the above video, the character is “teleported” twice, each time causing a big ripple throughout the character.
By animating the behaviour of every Marker during the time of teleporting from Dynamic to Kinematic, like I’m doing in the below on the group, we can “reset” or otherwise cancel out any velocities introduced at that time.
Here’s a scene you can inspect.
teleport.zip (117.8 KB)
Is this what you mean?
Hey guys! Thanks for the advice. I am intending on responding properly as soon as I can. Just very busy at the moment wrangling ragdolls!
Sorry for the silence. I’ll update soon.
Okay. Here’s a simplified demo of what I’m experiencing.
The issue with ‘B’ (switching to Kinematic for 1 frame) is that the markers all reset to their original positions and have to fall to rest again.
What I’m doing in ‘C’ is baking the first and second parts of the timeline separately then switching between bake results on playback. This produces a natural result, but is unweildy for the amount of simulating I need to do.
To clarify, I’m happy with the results of ‘C’, but if there was a more elegant way of doing this, I would be extremely interested to hear it.
Thanks for your patience!
Thank you, now I see the issue. This was an interesting challenge! I can see 3 potential solutions.
- Bake one range at a time
- Software solution
Since I didn’t have the scene, let me start by showing the problem reproduced.
Here, I have explicitly made the initial position of the skirt fan out, to highlight that it desperately needs a few frames to come to rest and that simply transitioning to “Animated” isn’t enough.
Let’s start at (1).
1. One Range At A Time
If the character starts at 0 and is offset at frame 77, we’ll bake until 76 such that we can maintain the pose of the skirt as we transition from “Dynamic” to “Kinematic” (called “Simulated” and “Animated” since version 2023.04.01).
This solves the issue of having to come to rest as much, but still kills any velocity from the previous pose.
This would be the cleanest and most scalable solution I think, and the one I would probably attempt if I understand your circumstances correctly.
In this case, the offset is removed. The simulation is performed. And then the offset is returned. See that
counterOffset animation layer?
With no offset, the simulation would run under pristine conditions, and with the offset on a layer we can toggle it off once simulation has been recorded.
3. Software Solution
Now, the nerd in me can also think of many ways of solving this in software. As a feature. It would be trivial to add a “Freeze Velocity” attribute that when turned On would simply ignore changes to velocity to the previous frame. But as a developer who is also mindful of maintaining the software for a long time, there is also such a thing as “feature creep” which is written on the tombstones of many software projects. It means too many features got added to tackle things too small and isolated. And I cannot see any other use for such a feature than this particular case.
Perhaps this case is common enough to warrant such a feature? Perhaps this is more common in games development? If so, do let me know. Then it is no longer feature creep, but a valid feature that should exist to solve a common issue.
Wow, an amazing response! Thank you so much for taking this seriously even though it’s a niche issue brought on by a less than perfect pipeline.
Your solution 2 to counter offset is interesting and would achieve the most accurate results, but unfortunately I think it would in the end take longer to manage than Option 1.
I am very aware of feature creep and I appreciate the concern of adding small tools for rare issues. I’ve come across this issue a couple of times in Game Dev, especially for Cutscenes, but I’m in no position to say if the feature would be ‘valid’. However if you do decide to implement this, I’ll be first on the list try it out.
Again, huge thanks for the guidance and understanding. And thanks for the great software!
Thinking about this, I’m reminded of at least one more usecase that I myself encountered in production a few years back. I had a character flying about a room, think Dr. Strange in the spirit realm, and my mission was to simulate his tunic and skirt. I didn’t care about momentum from the flying around, it wasn’t realistic anyway and would have thrown the simulation off. Instead, all I wanted was gravity and contact with the character. So, with nCloth, I parented the solver to the character such that - from nCloth’s perspective - the character was standing still.
I may implement this, it’s been on my list since early on but I hadn’t found a usecase for this with Ragdoll. I’ll move it a bit higher on the list. @_ed it sounds like you have encountered something like this as well, could you tell us more about it?
sorry for the slow reply -
It is, unfortunately, very common in games to teleport characters. Honestly sit down and play any game and you will see characters initialising on screen, hair and skirts either starting in the bind pose (often posed straight and away from the body to allow easier rigging and skinning) and then falling into place, or even worse inheriting the forces from wherever they are teleported from and then going crazy for a few frames until they settle down.
This is most often seen at the start of a level, or just after a cutscene. Or during cutscenes where on a camera cut a character may be moved quite a long way from where they were in the previous shot. These small teleports happen more or less all the time. And they get baked into the data. Quite often even if something was captured/animated in one continuous shot by the time it gets back to simulation it will have been edited in multiple places. Technically this is a pipeline problem as the edits could be non-linear (thus preserving the original data) but often it just doesn’t happen with this degree of sophistication and what you see is what you get.
- One Range At a Time - yes this works. It’s annoying though as it means if you want to re-simulate something you have to pretty much start again.
Also (and maybe this is just an option I’m missing) when I record it makes an override layer which if I then record again removes all animation from the previous override layer. I was struggling to find a neat way to just record as I go?
- counter offset
Certainly would work. Obviously adding time and effort and also wouldn’t work if on a cut a significant non linear time was added. i.e. my dancer is spinning, but I go back in time on a cut, to show the spin from a new angle.
- software solution
leave this one to you.
- Add frames
very similar to counter offset. But instead of fixing the animation to remove the pop just add frames so the simulation can cope with the movement. Adds the overhead of having to add these frames (and remove them on export), but at least it is simple and flexible.
I am struggling to find neat solutions. The option to pause simulation and then pick it up again while preserving momentum (but ignoring anything that happened in the pause) would help fix some issues (but not all).
It would be nice if Maya had a bit more in the way of a non linear timeline. i.e. between frame 30 and 31 (where my character teleports) I just add 30 frames (and maybe one breakdown key frame) and everything simulates nicely (but I only export frame 30 and 31 - not the 30 frames I just created). This would also be kind of handy for looping animations (like a walk cycle). I have no idea if non-linear time is a possible feature within ragdoll?
Thanks @_ed, this helps me understand the issue better, and I’ve also had time to think about this since our last conversation. I now see how it isn’t possible with Ragdoll at this time and how it is a more general issue to simulations.
I do have one idea, which if successful should solve this without the need for extra frames and without any artefacts altogether. I’ll give this a try within the next few days, since I’m curious about it myself.
To dive a little deeper, what I’ve got in mind is to provide an animatable toggle to freeze the velocity of the rigid bodies. When toggled, whatever velocity an object has would be captured and persisted until the toggle is disabled. This should allow things like cloth to retain their velocity while they move about, even teleport. They would appear frozen/static during that time, only following their top-most kinematic parent like the root/hip. This would only work for hierarchies and where some parent-level object was kinematic and can actually still move.
To be continued.
As you say - this is a general issue to simulations. No easy fixes I think.
Thanks for looking into possible solutions, velocity freeze sounds workable…