Conserning The Motion Of Bones With Dynamic Constraints

[markw]

Sorry all but its me again with more questions.

The model I'm working with at the moment has a few short chains of bones in the hair and breasts with Dynamic Constraints to give it some "free" secondary motion as she moves.

This motion is determined by A:M based on how fast the model moves in real time.

Faster, more motion, slower less. Just like in the real world.

To capture this motion for NetRender to use, a scene needs to have the Dynamics baked first.

However when baking, A:M plays through the scene, making keyframes for the Dynamics as it goes, much slower than in realtime.

And it is at this slower speed that A:M now calculates the amount of motion on any bones with a Dynamic Constraint, resulting in rather minimal and stiff looking motions after baking when played back at the correct speed.

 

Any tips for avoiding this slowdown or workarounds?

Should it be reported?

[robcat2075]

This is something that has bothered me, but I've never gotten around to investigating it.

 

Logically, an unbaked dynamic constraint sent to render (not Netrender) should look no different than a baked one sent to render (not Netrender) since both start from Frame 0 and work their way through the animation with the same imaginary 1/24th second units of time.

 

That's the way i see it. What do other people think?

[John Bigboote]

I had noticed that in the past, in fact we had several discussions here on the forum about it. It was quite frustrating because you either had to set your DC looser or go back later and dink with the generated keyframes to try to get the full action back into them. What version are you using, I ask because this may be an issue that is addressed in V17- seems I am not having trouble with this issue anymore...

[Gerry]

I had a problem with this a couple years ago, where dynamic constraints that looked fine in a one-pass test render all "flattened out" in a multi-pass render. As someone told me at the time, before you do a final (multi-pass) render, delete all the dynamic constraints and check "simulate spring systems", or something like that. It has something to to with the multiple passes equalizing the dynamics until they're barely there at all.

 

Is this relevant to the type of renders you're talking about here? (N.B.: I've never baked anything, so I'm unfamiliar with its effects)

[NancyGormezano]

This motion is determined by A:M based on how fast the model moves in real time.

Faster, more motion, slower less. Just like in the real world.

To capture this motion for NetRender to use, a scene needs to have the Dynamics baked first.

However when baking, A:M plays through the scene, making keyframes for the Dynamics as it goes, much slower than in realtime.

And it is at this slower speed that A:M now calculates the amount of motion on any bones with a Dynamic Constraint, resulting in rather minimal and stiff looking motions after baking when played back at the correct speed.

 

Any tips for avoiding this slowdown or workarounds?

 

I think what you may be experiencing/describing is that the dynamics look, playback differently in REAL-TIME, and scrubbing compared to the rendered version? Yes there is a difference. (ver16b 32 bit PC)

 

However, I do not believe there is a difference in RENDERED imagery, whether the dynamics have been baked or not. The computation looks the same to me. It also doesn't seem to matter (in this small test) whether it is multipass ON or multipass off

 

Your best bet is to bake your dynamics and then check the interactions, appearance of your animation in real time with the baked dynamics. Make your tweaks according to that. Then go to render.

Comp_1bakenobake4exsh264loop.mov

[robcat2075]

My test is similar to Nancy's but has a very slightly different result.

 

I don't think there really is "real time" to the computer. It does the simulation calculations to get the object from the last frame to the current one, throws a picture up on the display and then waits until it has to do that again.

 

To test that out I captured a real-time display one-frame at a time and compiled the captured frames back into a 24fps movie (middle view). It wouldn't matter if I waited 10 minutes between each capture or did them 1/24th second apart, the motion of the chain woudl be the same.

 

 

PendulumComparisonH.mov

 

The result looks so similar to the realtime playback on my screen (which i can't capture at 24fps) that I'll say they are identical.

 

It also looks identical to the animation sent, unbaked, to the renderer (top view)

 

The "baked" version (bottom view) is also similar but show some slight differences, particularly in the behavior of the top bone in the chain. I can't think of a good reason for them not to be identical, however.

 

It's possible that if you had a one-bone dynamic constraint you might be getting a very different appearance between unbaked and baked.

 

This test uses just the default settings that happen when you create a dynamic constraint.

 

I believe "simulate Spring Systems" is left over from the old cloth scheme and isn't relevant to dynamic bones. It's greyed out on my screen.

[John Bigboote]

Interesting test, Rob... lottsa work! What version was this done with?

[robcat2075]

Interesting test, Rob... lottsa work! What version was this done with?

v17 beta 4

[Elm]

....

Logically, an unbaked dynamic constraint sent to render (not Netrender) should look no different than a baked one sent to render (not Netrender) since both start from Frame 0 and work their way through the animation with the same imaginary 1/24th second units of time.

 

That's the way i see it. What do other people think?

 

 

Anyway, if you're planning on using multiple passes for later compositing (whether with or without using netrender), you really should bake all dynamics before rendering. That's because - even if you render locally on one machine - the dynamics might be simulated with slight differences. Thus the resulting passes won't fit with each other.

 

i think Nancy's approach is the right one. Just check the dynamics after baking and eventually alter your settings.

 

Greetz,

Elm.

[Fuchur]

This motion is determined by A:M based on how fast the model moves in real time.

Faster, more motion, slower less. Just like in the real world.

To capture this motion for NetRender to use, a scene needs to have the Dynamics baked first.

However when baking, A:M plays through the scene, making keyframes for the Dynamics as it goes, much slower than in realtime.

And it is at this slower speed that A:M now calculates the amount of motion on any bones with a Dynamic Constraint, resulting in rather minimal and stiff looking motions after baking when played back at the correct speed.

 

Any tips for avoiding this slowdown or workarounds?

 

I think what you may be experiencing/describing is that the dynamics look, playback differently in REAL-TIME, and scrubbing compared to the rendered version? Yes there is a difference. (ver16b 32 bit PC)

 

However, I do not believe there is a difference in RENDERED imagery, whether the dynamics have been baked or not. The computation looks the same to me. It also doesn't seem to matter (in this small test) whether it is multipass ON or multipass off

 

Your best bet is to bake your dynamics and then check the interactions, appearance of your animation in real time with the baked dynamics. Make your tweaks according to that. Then go to render.

 

One of the biggest problems with OpenCL is, that different implementations result in different results. (only slightly, but for a rendering-application a difference of 0,0001 makes a huge difference, especially if this result is used to calculated further on. CPUs are not the same neighter, so baking is a better idea... what you do afterwards with the channels / keys is then your decission...

 

See you

*Fuchur*

[John Bigboote]

All interesting, but I still think the problem has been worked on since V15 when it was much more noticeable. You would set your DC, watch it play(not scrubbing) and like what you see, render it and it was like the DC was never even applied.

[robcat2075]

All interesting, but I still think the problem has been worked on since V15 when it was much more noticeable. You would set your DC, watch it play(not scrubbing) and like what you see, render it and it was like the DC was never even applied.

 

Yes, I remember there used to be a substantial difference.

 

markw, what version are you using?

[markw]

All interesting, but I still think the problem has been worked on since V15 when it was much more noticeable. You would set your DC, watch it play(not scrubbing) and like what you see, render it and it was like the DC was never even applied.

 

Yes, I remember there used to be a substantial difference.

 

markw, what version are you using?

I set the Dynamic Constraints and started this animation in 16b but all the Dynamics baking has been done in the 17beta's.

 

I want to try and replicate your test there Robert at some point, maybe in a more complex set of motions as I still think I'm seeing something different.

It seems to me that A:M is doing more than as you say Robert "… does the simulation calculations to get the object from the last frame to the current one, throws a picture up on the display and then waits until it has to do that again." and that it is somehow applying the rate at which the next frame has to be shown to the degree of motion applied to the bones.

And because it bakes at a slower speed than normal play, a lesser degree of motion is what is captured.

 

Another possibility, which has just occurred to me writing here and possibly more likely?, is that when working in the Chor maybe the Dynamic Constraints that we think are at work in fact are not! Or at least not fully in that the % values are not being applied.

But it is only when we go to bake that the various settings we made for the constraints when rigging are actually getting applied. Thus giving the illusion that its the baking that's wrong in making things appear too slow and stiff.

 

When time permits me I think this will need some more looking at.

The motion we see in the Chor should be the same as we see when baked and finally rendered otherwise we are left with trying to second guess when animating what the software is going to do to all our hard work later.

 

This is definitely one of those times that I wish we were all in the same room with our computers and could actually see whats happening on each others screens!

 

As to my current animation, are you all saying that I should go to each of the Dynamics keyframes and reposition the bones by hand? Thats a lot of keyframes!

As that's going to be a long job even on this short animation I think first I might try Johns idea of dropping the stiffness etc... of the Dynamics settings and see what that renders like (Humm... this might actually tie in with my earlier idea above).

[Gerry]

How do you bake the dynamics? And as I understand it, once baked you can't unbake, right? So the idea is to save a baked version of the chor for testing, etc.?

[robcat2075]

How do you bake the dynamics?

 

in the Chor>Bake Dynamic Systems

 

And as I understand it, once baked you can't unbake, right?

 

in the Chor>Remove Dynamic Simulation Data

 

 

 

So the idea is to save a baked version of the chor for testing, etc.?

 

You may be thinking of cloth. Cloth (not a Dynamic bone system) has no explicit un-simulating option, but in actual practice a new simulation will overwrite the old one.

[robcat2075]

I want to try and replicate your test there Robert at some point, maybe in a more complex set of motions as I still think I'm seeing something different.

It seems to me that A:M is doing more than as you say Robert "… does the simulation calculations to get the object from the last frame to the current one, throws a picture up on the display and then waits until it has to do that again." and that it is somehow applying the rate at which the next frame has to be shown to the degree of motion applied to the bones.

 

A:M uses formulas to calculate how much farther to move a bone from the last frame to the current one and in what direction. The "time" element of that calculation is not dependent at all on our real-world human time that passes while the calculations are being done. The computer plugs in a number that represents the passage of 1/24th of a second and the formula (which also considers numbers for things like previous direction and speed) returns values that tell where to place the bone for the new frame.

 

It matters not how long the calculations actually take the computer to do. A very slow computer processing the formula should come up with the same answer as a very fast computer processing the formula.

 

If there is a difference between realtime simulation result and the simulation that results from Baking, then the formula is somehow being applied in not exactly the same way.

 

It's possible that my simple test with default settings does not catch what is happening for you. If you could create an example case that shows your differing result that would be very useful.

 

For reference here's my test PRJ.

 

DynamicBakingTest.prj

[NancyGormezano]

I'm seeing something different.

It seems to me that A:M is doing more than as you say Robert "… does the simulation calculations to get the object from the last frame to the current one, throws a picture up on the display and then waits until it has to do that again." and that it is somehow applying the rate at which the next frame has to be shown to the degree of motion applied to the bones.

And because it bakes at a slower speed than normal play, a lesser degree of motion is what is captured.

 

There are 3 different ways to view your animation: real-time, scrubbing, rendered

 

When I say playback in real-time, I mean that you are playing your animation in A:M, and not looking at a rendered QT mov or avi. A:M's "real-time" playback is an approximation - that is the playback is NOT happening at exactly real-time For exact real-time each frame would be displayed for exactly 1/24 sec (if 24fps), only if your computer was fast enough, or not too fast. To approximate real-time, we usually check the setting Tools/Options/ Global/skip frames if behind. This will give you the best approximation to what the rendered timing will sorta look like. However it will NOT be the same as the rendered. If you want to see what it sorta will like (but not exactly) then you should bake first and then play it back in real-time, to get an idea of how the dynamic system is responding.

 

For the 2nd case: If 1) you are scrubbing thru the timeline, AND 2) you have NOT baked your dynamic systems then you will definitely see different results depending on how fast or slow you are scrubbing. See for yourself. Try scrubbing back and forth with your mouse very slowly thru a range of frames, and then very rapidly through the same range - and yes you will get widely different dynamic motion (if unbaked).

 

The motion we see in the Chor should be the same as we see when baked and finally rendered otherwise we are left with trying to second guess when animating what the software is going to do to all our hard work later.

 

Yes the dynamic motion of a chain of bones should be the same, after baking. The timing however will look different, if played from a QTmov, avi, or in A:M real-time.

 

As to my current animation, are you all saying that I should go to each of the Dynamics keyframes and reposition the bones by hand? Thats a lot of keyframes!

 

No. no. no. What I meant was after baking, you will want to check for stiffness (too loose? too stiff?) as well as penetrations of the dynamic system geometry into other geometry elements in your scene - if there are any, you will probably want to adjust other elements (other bones, camera angle, stiffness, other dynamic properties) based on the baked dynamic motion IE Change your settings, Move things out of the way, hide from view. Unbake, rebake test again, repeat ad nauseum.

 

I usually have a control bone parent (in my example called big bone) that is a parent to the chain of the dynamic bones, in which I use to TWEAK the motion of any penetration of the dynamic chain (after baking). So if after baking I like the motion, but some geometry has penetrated, I can use the control bone to rotate or translate slightly the chain's motion for a couple of frames, and then move it back again when all's clear. That is what I meant by tweaking.

 

Do not try to tweak the dynamic chain results (in my case bone1, bone2, end). Screwy things will happen. The dynamic results are offsets. I believe it use to be one could tweak those results, but somewhere along the versions those channels became inaccessible. I believe they use to be the actual real translate and rotate channels and not offsets at one time.

[robcat2075]

Mark, if you can show us the case that comes out very differently that will speed things up enormously.

 

Without a misbehaving PRJ in captivity it's hard to study the problem.

[markw]

Mark, if you can show us the case that comes out very differently that will speed things up enormously.

 

Without a misbehaving PRJ in captivity it's hard to study the problem.

Well thats interesting Robert.

I just tried your baking test and A:M runs through it, baking as it goes, at more or less the same speed as just hitting the play button.

And you would have to be super picky after baking to try and find a fault.

In my Rear Window chore when you bake, it runs through it baking at maybe half speed at best, possibly less. This could be because there's more information going on for A:M process? And there's a noticeable difference between pre and post baked DC's.

This is why I want to try and make a more complex version of your test with lots of other things for A:M to keep track of as it runs through the chore baking.

 

And yes, normally putting together an example .prj for others to try out is the first step with these things. Sadly I don't have one just yet.

Its a question of available time for me at the moment to experiment with this. I still have much else to do on my bit for the Community Project and at the moment thats the only project I have using DC's that I could post as an example. But I would rather not make that readily available for general downloading on the forum just yet.

[markw]

And to Nancy,

"No, No, No…"

Thanks for the clarification Nancy. That was a disaster narrowly avoided there!

 

"For the 2nd case: If 1) you are scrubbing thru the timeline, AND 2) you have NOT baked your dynamic systems then you will definitely see different results depending on how fast or slow you are scrubbing. See for yourself. Try scrubbing back and forth with your mouse very slowly thru a range of frames, and then very rapidly through the same range - and yes you will get widely different dynamic motion (if unbaked)."

Yes, this is definitely what I see too.

 

"…repeat ad nauseum."

Aptly put, I'm about to embark on that now.

I like your idea of a master bone for each chain too.

 

As I said in reply to Robert I'm afraid the only project I have at the moment that I could post for what I think is happening for dissection by more learned minds on the forum is my bit for the community project so it may be a little while before I can see if its replicable in another project. But I will be coming back to this to prod and poke it some more.

[robcat2075]

In my Rear Window chore when you bake, it runs through it baking at maybe half speed at best, possibly less. This could be because there's more information going on for A:M process?

 

Definitely

 

 

 

And yes, normally putting together an example .prj for others to try out is the first step with these things. Sadly I don't have one just yet.

 

Dont' despair. We'll be here for a while.

[mouseman]

For the 2nd case: If 1) you are scrubbing thru the timeline, AND 2) you have NOT baked your dynamic systems then you will definitely see different results depending on how fast or slow you are scrubbing. See for yourself. Try scrubbing back and forth with your mouse very slowly thru a range of frames, and then very rapidly through the same range - and yes you will get widely different dynamic motion (if unbaked).

 

My guess here is that A:M is using: [clock-time of rendering of the current frame] - [clock-time of rendering of the previous frame] for the time difference when scrubbing, instead of [animation time of the current frame] - [animation time of the previous frame] (e.g. 36:00 - 35:23, or 1/24th of a second). The problem is very noticeable when using the vehicle rig that mtpeak posted a while back.

[John Bigboote]

After baking my V17beta5 choreography with multiple dynamic constraints and getting results that were rather UN-dynamic- I came up with a work-a-round that seemed to work pretty well. (Forgive me if this is discussed above.)

 

Change your main project FPS to something really low, like 5-7 FPS(frames per second, it is at the very-very top of the Project Workspace) THEN- run your 'Bake Dynamic Sytems' feature... THEN- change your FPS back to whatever it was. The GOOD thing is that you get a nice, baked dynamic action... the BAD is that you don't get a keyframe on every frame. Works though!

[markw]

That's an interesting idea there John!

I'm about to have another go at this Dynamics thing soon, so that's a timely suggestion, thanks