[Steve Bentley]

So it sounds like the environment (the room) doesn’t change and your camera doesn’t move. So you are right: why render the room over and over again if the only thing that changes is the robot.

Light the robot as you wish and render all his frames with just him with an alpha channel and the room turned off.

Then apply a shadowcatcher material (R19 and above) to the floor object and render all the frames of your floor, the robot with no materials on him, only the lights that cast shadows and a compositing tag on the robot with “seen by camera: set to off. The robot will not show in the render but his shadow will (as an alpha), and only the shadow. So you don’t need materials on the room objects and you only need to have the objects that will receive shadows visible.

Then render just the room in full color but just one frame.

Composite the robot, the shadow and the room together in a compositing program, extending the one room frame to cover the entire length of the robot’s animation

[Steve Bentley]

You could also animate empty polys and use the trace feature to link the space between them.

[Steve Bentley]

“Randerizing” – my new favorite compositing-related word!

[Steve Bentley]

If you are using the new AE2018 15.03 or higher you have run into the “no longer supported codec” problem. Apple has stopped development of quicktime and there are a bunch of other codecs that will not be compatible with higher color space formats and bit depths, so Adobe in their infinite wisdom has, without warning, not allowed us to work with that kind of footage any more. To be fair, its a pill we are all going to have to swallow sooner or later, but to do this without warning or without some kind of transcode option is just silly.

You can uninstall and got back to AE2018 15.01 which has all the features of 2018 (plus a few bugs) but does allow the older formats.

[Steve Bentley]

The values of the keyframes are the original footage frames. So if you put a keyframe at frame 50 of the time line but make the keyframe’s value 100, you will have sped up the footage by a factor of 2.
Keep in mind though that the Time Remapping feature, while handy doesn’t “invent” the missing frames, it simply grabs the closest whole frame to the one the keyframes are asking for. Take the example above, instead of 100 use 105. So now on timeline frame 50 you will see the original frame 105, so far so good. But go back one frame in the time line. What frame should be there? – technically it should be frame 102.9. Well there is no 102.9. So AE will display frame 103. If you keep going back one frame at a time by the time you get to timeline frame 45, you will end up seeing source frame 94 twice. This can have a choppy effect that doesn’t look like slow motion, or in this case smooth sped up motion.
Precomposing your source footage that has been shot at a much higher frame rate than is needed can help. Then use time remapping on the precomp, but in the outer comp. Because there are more frames to choose from per second in the precomp than the frame that is needed, the time remap will have a better chance of plucking out the frame it needs if the frame rate on the source footage is very high.
But if you want a true slow-mo or smooth speed-up, you must use the built in time warp effect or a third party time warper like Twixter. These will render a new frame based on the pixels of the frames either side and “invent” frames that were never shot, but correctly position objects where they would have been if shot at that frame rate. Its never perfect (especially with objects suddenly appearing from out of frame) but its surprisingly good and again better and better if the source is shot at a higher frame rate than you need (even if you are going to speed up the clip in the end – the more frames these warpers have to work with the more data they have to make the missing frames.

[Steve Bentley]

First the caveat. I’m using the standalone RF (with some custom stuff) so my suggestions or naming conventions might not translate to the plug in.
Processing the simulation can take a long time as each particle has to figure out where it is based on what all the other particles and forces are doing to it AND figure out how it connects (literally) to all the particles around it and which ones those are and which ones it wants to make geometry with. Its a huge amount of processing and on meshes like we generate can take days to work out.
Once the mesh is figured out ,its just geometry rendering after that.

I’m wondering if you couldn’t play with a much lower concentration of particles to get the process working (whats going to react correctly with dynamics and the fluid friction settings etc) and then and only then increase the number of particles emitted to get your final look.

And with that in mind, I wondered about two meshes. One that is made from a lower number of emitted particles that will sim quickly and will be of a lower poly count as a mesh, and then use that mesh for the dynamics interactions.
Then process another mesh, made from a goodly amount of particles that will make it look like liquid and not lumpy porridge. Use this mesh purely for the render. Don’t plug this one into the dynamics engine. They won’t be identical but might be close enough for the illusion.

I’m not sure if it helps but there is also a script here: https://helloluxx.com/product/impact-deformer-for-cinema-4d/
Its not part of RF but it might create some interactions you can use to help the effect.

One the problems with all fluid simulations is that (for some reason) the particles have too much energy. So when you pour them in a glass for instance, they will shoot up the far wall and exit the glass. Real life doesn’t work that way unless you are pouring from 3 feet away. So you have to ride the friction levels or put attractor/damper fields in the simulation to suck the energy out of the moving particles at just the right time. It can also take a long time for them to settle (in fact they rarely do) so you have to ride the “death” settings to get them to stop. Usually we’ll subsitute in another wave based solid model just as the particles are settling so you don’t get jittery particles jumping or leaking out of your glass.

As for the program crashing, its possible the particles are making a mesh that is not well formed. When we bring a mesh in from RF often it has to be optimized because there are points that never fully realize into “blobs”. There are always many more particles emmited than resulting blobs – you need a cluster of particles to make a blob, a single particle will rarely show up as a droplet. (depending on settings). And as particles part, that droplet can be torn apart, sometimes with geometry inside out or not closed or with vertexes in exactly the same spot. When you run the dynamics engine in C4d it may encounter reversed faces or even unclosed polys in the mesh and that may result in divide by zero errors. By simplifying the RF mesh that is used in the dynamics tests, that may reduce the number of bad polys encountered as it interacts with the earrings.
It might also be that the earrings are not well formed. Run an optimize on the points and faces of those as well just in case and check that all the normals are facing the right way and that they have no holes. Or use a stand in for the earrings (again a simpler model) in the dynamics processing. Nothing says that the actual objects that create the pretty renders have to be the objects that crash into each other; those just become trigger objects.

[Steve Bentley]

Because of how the volumetric tracer works, and based on the look you are going for, you might be better with smaller thinner cloud groups and then creep each group along individually, overlapping them for the look.
The Cloud Generator is just a preset for Thinking particles and PyroCluster, but it has been optimized for making static bunches of cloud clusters. I’m not sure if we have it here but I’ll take a look and see what kind ways you can get under the hood. There should be an Expresso tag on a null in your object manager that you can open up and see whats going on.
And on that note I just realized, because its preset you could just post the project and I could see whats happening. Once the script is in the project its already run and everything is in place so I could work with it.

[Steve Bentley]

Its the sims that kill us. We’ve tried splitting them up on the farm but we get differing results between “identical” machines. About 4 or 5 years ago RF finally got multi threaded so that was a godsend but now of course we’re taking advantage with stupid amounts of droplets , but at least we can now read by the light of each machine’s 24 cores glowing white hot.
I wish Nvidia would start building computers instead of just video cards. If I could push the sims into a video card they would scream! I never thought we could get to a point where the render would be the quickest part.

[Steve Bentley]

There are a few ways to get there.

You can use the delay effector and/or the shader effector with a noise set to world space so that as the particles pass through darker areas of the (invisible) 3D noise they slow. Make sure to set the fall off correctly so it encompasses the area you want to be affected.
You can also change the particles emission and individual travel speed either with the velocity settings in TP or with “gravity” wells here and there (attractors with very low values – not enough to truly attract them but enough to make the particles think twice before continuing on).
You could also change the particle size so that it shows and then doesn’t show as much when in a cluster of other particles doing the same thing (voxels build up as they group together)
I think you could also do a combo of both. Use a global noise piped into expresso to set traveling speeds of the particles with the get position and set position nodes.
Don’t forget you can have multiple emmitters all doing something slightly different and each in a different particle group and then have all the particle groups fed into Mograph to have them show up.

One issue with all this might be the cloud formation. As the voxels get farther apart they tend not to group and show up. And you might get some popping in your cloud puffs as they build up, or worse intersect in a way they weren’t intersecting on the previous frame. There could also be depth issues – as a voxel passes through or behind another, it will often pop as its depth is reordered by the render engine.

I think you can get there with TP but FYI this sort of particle control is easier with X Particles.

[Steve Bentley]

Sure, that’s the inertia of the objects overshooting their landing position and then snapping back. In essence, it’s a bounce and a classic technique of animation to give shapes weight.

You can hand animate that, or use an expression to handle it ,or if you’re working in mograph there is an effector setting that will automate it. I’m not in front of C4D right now but will check on where that hides in Mograph later.