I have a sequence for Kata that I’d like to use both in full-speed and slow motion. With most IPO-based animation this can be done with the Time IPO curve (afaik), but I’m also using the Cloth sim, and Soft-body sim for particle hair, in the sequence. Since these are cache-based animations, the Time IPO would not apply to them, or so I surmise.
Slowing the sequence in the VSE with a Speed Control strip isn’t feasible since it just dupes intermediate frames and ends up looking choppy when slowed as much as I need (~1.64x).
Converting Cloth to shape keys is a route, though labor-intensive, but that can’t be done with the Soft-body sim on the particle hair.
Bottom line – I want to stretch 70 frames to 115 frames in a way that takes into account the already-baked Cloth & Soft-body sims. Any ideas?
Nevermind – I did the Cloth -> shape key conversion, and it turns out that just re-baking the Soft-body hair works OK. It doesn’t exactly match the full-speed motion but it’s not noticeable in the camera angles I’m using, and doesn’t look out-of place despite being “full-speed.”
For soft-body particle hair I think you’d have to slow things down a lot more that I did for it to not look OK even with “slow motion” for the rest of the action. You could probably adjust the Soft-body parameters to compensate a lot as well.
Couldn’t you have changed your fps to say double what it currently is, render the output, then in VSE scale the strip down time-wise to what you wanted?
Changing FPS really wouldn’t change anything, because the determining factor is the number of frames, not the playback speed. Render 100 frames at 30 fps and you get 100 frames that playback in 3.3 second. Render it at 10 FPS and you get 100 frames that playback in 10 seconds. To get 10 sec of playback at 30fps you need 300 frames. Since my playback speed is fixed, I needed a way to render more frames for the same action.
You can alter the recording FPS with a film or video camera to get slomo, but that’s just a means of getting more frames for the same action. But Blender’s FPS (and all other animation apps afaik) is playback only, and the number of frames is set in the animation’s timeline. You can us the Time IPO to stretch/shrink IPO-based animation, but for baked, cache-based motion, you need other means.
First i would try the “speed” soft body parameter.
This is the frame to real time ratio and is adjusted such that
a 1BU = 1m long pendulum has the correct cycle time at 25 fps.
Thanks, that’s good info to know, bjornmose! Unfortunately (as documented early on in this project) my model doesn’t even come close to the proper “sim scale” of 1 BU= 1m, so I have to resort to fakery :D. But it looks good nonetheless.
Forgot … assuming gravity is close to 10 m/(s*s) … T … return time so what ever your world looks like … the basic physics clock ( newton … don’t ask for Einstein please ) is defined by
length ( scale ) and gravity … http://en.wikipedia.org/wiki/Pendulum_%28mathematics%29
Einstein found things are knitted on space time and mass … but I think we can stick with Sir Isaac for sanity
…
Oh, no… no backing out of it… you must post the equations for relativistic renderings!
I kind of see what your getting at with the pendulum equation – is this the basis for the Speed setting?
It would be very useful if such variables as model scale and frame rate could be directly incorporated in the sim parameters to accommodate artist’s choices. Using constants is limiting imo, especially since it hasn’t been well-documented how they are being used (at least not in the past).
Totally agree on that.
Unfortunately the internal blender timing is done in frames. That is the soft body code only ‘sees’ the time elapsing in frames. That is the reason why the speed parameter is needed to re translate to ‘real’ time. ( So yes speed =1 makes a 1 BU pendulum on earth behave realistic at 25 fps)
From pendulum we get approx:
scale * 1BU =1 [m], speed= (scale^1/2)/n ~ 25*n [fps]
Since soft body is in ‘kernel’ module it was a total ‘no go’ to use variables from the ‘animation’ or ‘render’ module directly. Which is a good coding practice to keep the module interfaces clean. Even more since NLA allows to bend and stretch timing to its limits. Bad luck for the soft body module. It is just ‘blind’ for the things happening out there.
OTH good news ‘speed’ animates in 2.5 so even faking relativistic effects is possible.
The correct solution would be to use real time in the entire animation system and evaluate frame timing at bake / render time.
so what ever your world looks like … the basic physics clock ( newton … don’t ask for Einstein please ) is defined by
