[Steve Bentley]

Cntrl vs cmd: Sure enough, but the alt and option keys can also drive you nuts especially on keyboard models with the damn windows button that shifts the alt key (option on mac) over one. Just plug in a Mac keyboard to the PC and it solves that problem at least.
After years working on Macs, getting used to the pinky thing for cntrl on the PC seemed hard at first but now that I’m used to it and looking back, the cntrl way is the better way – to much finger crossing the Mac way. Its one of the few things that Microsoft got right before Apple did (or should I say before Xerox did)

The mouse moves differently on a PC too. The Mac implementation is elegant with a really good accel/decel. The PC feels a little molasses-like when you first get going on it. You do get used to it but I prefer the Mac for this.

The best part though about moving to PC (apart from building a kick*ss machine for 1/3 the cost of the equiv mac) is that you have a world of graphics cards at your finger tips now. Welcome to the Dark Side. That’s not breathing you hear, its the fan trying to cool 24 cores!

[Steve Bentley]

If its the keyframes you’re working with those are keyed off the object’s anchor point. (not always the same as the path’s first vertex).
You can move the object’s anchor point by using the pan behind tool shown here. Just grab the object’s widget with is and drag away. The object won’t move but the anchor will. Keep in mind if you have already set keyframes this may offset the entire positional animation. You can preserve an already done animation by nesting the animated elements in a null and then offset the null’s anchor point and then animate the null with the other elements inside.
(remember to go back to the pointer tool when you want to move things for real).

[Steve Bentley]

Oh and the custom center of mass only works on rigid bodies too. I made a tear drop out of a cone to have a weeble to test with. Turns out, if you have self collision turned on the tip of the cone splays open as it collides with itself – kind of like that early CG film panspermia, or an Alien egg if you’ve got the friction turned up. So I guess that means cones aren’t really closed. Will have to run a 3D print to see if they are “water tight”.

[Steve Bentley]

I was running in to that too (mass map making a disproportionate jiggle). To add to the complexity I’m firing the object out of an emitter. I had done this with a dummy and got it working perfectly. Of course now that I have my real object the dummy is me (I hate that – test a simplified version to make sure you can say yes to the client and then have the problems start when the actual geometry gets involved). The increased complexity and number of polys seems to be having an effect on the tension within the softbody, so now even firing it out of the emitter with no air resistance imparts a wobble and up-scaling that I didn’t have with my dummy object. (the dummy had less polys). I am animating the damping and the stiffness etc which works in the collisions but the emitter seems to add its own energy that isn’t controlled by the softbody tag on the ejected object.

I think I have it licked though. I’m bringing in rigid body collision objects (invisible) that nudge the object a little to both keep it upright enough and to add a damping at just the right spots. A bit of back seat driving if you will.

The only way I was able to make the compound body work was with rigid bodies. With the softbodies I can get it pretty close but the thin object ends up curling and sliding down the face of the support object after impact, as if its had too much to drink.

Thanks for being a sanity check. Somehow the blood on the brick wall doesn’t seem so bad when there are marks there from others who have tried.

[Steve Bentley]

So Compound Collision works just fine for Rigid bodies – I can’t find no indication in the manual that it won’t work for for Soft Bodies, but try as I might (have tried tag on the parent and have tried tag on a null that is the parent of all nested objects) the objects break apart and go their own separate ways.

[Steve Bentley]

I’ll be the first to say AE isn’t the fastest tool in the shed, but I’ll also be the first to say it’s the most flexible (every new rev of adobe anything gets slower it seems – I’m waiting for a new app from them called “Molasses” – if the machines weren’t keeping up with Moore’s Law we’d be in real trouble. Is that the old code clogging the pipe? Poor memory management? Not utilizing a killer graphics card to the fullest? Not being able to stream line or multithread because the code has to be able to be sooo flexible? Probably all four.

But AE really is a swiss army knife. When you’re working in Fusion or Nuke it’s more of a real time experience (ok its not, but compared to AE either of these handle a few hundred element 6K comp with much more ease than AE. But I always find I end up looking sideways at the AE box, thinking, “You know, I could do that trick natively in AE because that effect is built in”. I don’t know how many times I’ve made an element in AE and then brought it in to Fusion because either Fusion doesn’t have that kind of effect or its just can’t do it or I don’t have to preprocess 20 elements just to get a final element I can use.
Keep in mind too both Nuke and Fusion are more for a production pipeline where separate elements are handed to you, prematted, prepositioned, pretimed, prerendered, preroto’d etc, where as you can just precomp everything in AE to feed your outercomp combining element stack.
To each his own and the right tool for the right job and all that. but it does feel (especially in the speed area) like Adobe got lapped a long way back.
Oh, and again, where’s my built in Paint Adobe?

[Steve Bentley]

Dumb question but is the eyeball on the active camera turned on? and is the time marker within the span of the active camera’s bar within the timeline?

[Steve Bentley]

BMD did give it a shot – by buying Fusion. One might hope however they start developing it too to make it better. They seem to have the chops given their rework of Davinci.

[Steve Bentley]

Hey Mark (and Dave), I suppose there are competitors (Inferno/Flame, Nuke, Fusion, Sabre etc. on the uber pro side, and Piranha, Natron, Shotcut… and is Shake still around?) but I’ve wondered this as well.
But more: Why some of the also-ran’s haven’t “caught”? Especially given that almost every 3D package has built their own compositor as another app to upsell their user base – even Blender! None of the of the ones attached to 3D ecosystems have been broadly accepted or successful. But why? Anybody remember Jaleo? It even had a timeline and didn’t need to render!

I entertained the idea that AE’s and Adobe’s success where other’s may have failed has to do with having an ecosystem that cross-pollinates the work with different apps in different disciplines , abut then remembered that, up until recently, those apps didn’t play well together (and still don’t – I’m looking at you InDesign! And, for the hundredth time – where’s my Photoshop-type paint inside AE? Who makes a compositor without true paint?!!).

Ae is also the only one of the majors to not come out of production (ok, it did a little back in COSA days, but that’s being generous). Sure it benefits from we soldiers in the field but it wasn’t coded in the trenches, perfected and then released. And while we’re on the subject, why has there never been a public version of Sabre? (oh wait, ILM is the only FX house really making money so they don’t have to sell the secret sauce to stay afloat)

I also used to think that everyone of the majors came from and is still being developed by an FX house, except AE, instead being developed purely for capitalism, but then that’s not true anymore either, Discreet products are no longer with their original parents (twice removed now), same goes for Fusion and to some extent Nuke. And we won’t even talk about Shake’s pass through the Apple press until it was a rotting core.

I have to wonder if rendering 2D might be a little harder to code than 3D, at least to get it looking professional on screen and therefore it doesn’t get tackled as a project as much: or brick walls are encounter early in the development. In 3D with its infinite resolution you can always scale up in memory, render, then downsample to get rid of the artifacts and edges. 2D is limited to a degree by the finite resolution of the assets (except vector of course – but even then; try scaling a very small logo from AI in AE – you can’t get very far).

The fact that we don’t see a lot of others may be that the ecosystem around AE is so robust – it ties into 3D apps, has bagillions of plug ins (so many of them native), is frikkin easy to use, hooks into some editors nicely, is relatively cheap compared to others, and is fairly hackable. A prospective coder might look at all that and be daunted by the challenge. Or perhaps the field is actually saturated and we’re just frustrated by Adobe’s SOP. Look at what they did to Live Picture. Perhaps those coders that have attempted a competing product now share a room with Jimmie Hoffa.

[Steve Bentley]

I’ll have to get more in depth a little later today, but just off the top…

When I opened the file the global gravity is actually turned on (edit/project settings/dynamics). Its usually best to just make the value 0 instead of turning off everything with the radio button. This may or may not affect the particles depending on how you are using them. I also noticed that very few of the particles were connected to their gravity nodes and some gravity nodes have no objects in the slot. (this and what follows may be intentional on your part so none of this is criticism). You can leave gravity on, but I just thought with floating being needed its best to kill it and use “local” gravity for each group even it means the gravity is negative for some.

There are some primitives in there. If they are part of a bounce system or dynamics they may not work or not work correctly. You can use primitives for particles in a simulation but I find when it comes to deflectors or bounce objects making them editable geometry is best, plus you can then you can trim down the geometry to only where the particles interact which speeds things up.

You might also find the scale is a little small. When things get too small the math gets less accurate since there are only so many decimals and some of the objects sizes are already in the <1 values so calculating the dynamics get tough.

Its really running slow so i’m going to go through it and see what’s causing all the calculation slow downs (and that’s after i’ve removed the sky rig and a few other things!). You can use a proxy for your colliding objects and particles or you can choose a simple bounding box for collision detection instead of the actual geometry of the particle which makes the math really simple and speeds things up. I also noticed there are connected deflector nodes but no deflector objects in the slot some cases.

In your expresso you can have the PPass node feeding many other nodes; you don’t need one for every attribute. So instead of this:

you can do this:

The lifespan of the upper particles is only 5 frames – is that right? Is this frothing of some sort? If so you can also scale them over time (bubbles usually do that – the pressure drops as they rise through fluid and they get bigger before popping – its the getting bigger that makes them pop)

To speed things up you can turn off the enable button for each expresso in the attributes and just work on one particle set at a time – you can also make those buttons part of the HUD so you can see what’s on and whats not right in the viewport and trigger them from there.

And something not related to the particles: I noticed you are using sketch and toon. The sky rig might be overkill for a shader like S&T. Plus it will increase your render times. If you don’t need lines (the sketch part of S&T), often a cell shader will work just as well and it renders much faster than S&T. To be fair I don’t know what look you’re after but I’m old school: sure GI renders (the sky rig simulates a GI render) are great and a sky rig is quick to set up, but if you can light the scene with a few well placed lights and no GI, you can get it to look almost as good and the render times are fractions of seconds instead of minutes. With so much dynamic interaction going on you might want to speed things up where you can since the collision calculations could be costly time wise.

More in-depth later.