Wednesday, March 16, 2016

A Short Ride

This isn't the section of the video I had in mind, but went with it anyway.


Extras | • Source: Alexis Adams in Body On Body - PornPros

I'm not super happy with it, I gave up trying to work with it. I now remember why I stopped doing high motion video morphs as the connection between Mocha and After Effects is... shoddy. That being said, Mocha isn't made for this stuff anyway, so I can't blame it too much. I wish AE had an Uber Key like Mocha does so I would have to use it. The second scene I want to do is much easier to work with and I might be going at it with a different approach... but that's much later after Jiggle and Grow gets to that point.

Sunday, March 13, 2016

Hooters

There's a lot going on in this one - quite a few small details that when in to make it work out.


This is a combination of the Jiggle and Grow Script and Re:flex instead of the default Reshape Effect. Then it has about 15 adjustment layers to add things before/after/during the growth and bounces. I was pretty happy with the light and shadows.
Enjoy!

Monday, March 7, 2016

Jiggle & Grow Update to 1.4!

Rate is now keyframeable! Yea - that's right, it finally happened! I finally found a way to make it happen.

I realize most people wouldn't be excited about this, even the people who use the script, but I'm super happy about getting this to work!

If you're running the script currently, I'd suggest updating to this one.
If you haven't given it a try and have after effects, this would be the version for you to try!

Why is this such a big deal? Because After Effects doesn't allow you store values from one frame to the next, it also doesn't play nice with recursive functions. This is a problem because of the way sine and cosine work for the bounce part. If you change the rate on frame 10, after effects assumes that current value as what is was the entire time... which leads to very interesting results with the curves running backwards, extra slow suddenly fast, or just stopping. I couldn't think of a way to get around this until now.

Time = Frames * FrameDuration

I don't know what started this, but this little equation lets me control time by knowing the frame and frame rate (duration). The frame rate is set by the user in the composition, but I can control the frames... specifically the frame count. The script adds up the "frames" that have happened and adds weight to them based on the rate at that current frame. It has 2 downsides: It's 8% slower than before and it can only interpret a change of rate as linear changes. Eh, not a bad trade off.