RealFlow: Mesh/Fluid wont create Initial state. Crown Daemon not rendering on impact

[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.

[Jim Scott]

[Steve Bentley] “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.”

Hey, thanks for reminding me…

Something which I tend to forget about is that the Realflow C4D plugin has an option in its solver settings to “Use GPU,” though the manual does come with this caveat: “RealFlow’s Dyverso solver is highly optimized for CPU multi-core and many-core processors. Some GPUs, on the other hand, do not have enough computational power to outperform a 8 or 12 core processor – which is common hardware today. For this reason a GPU-based simulation can be slower than a pure CPU-based simulation.”

One of these days I’ll try to remember to run a test to see if my GPU (GTX 980 Ti) gives any improvement. Apparently only the fluid solver is GPU-accelerated (and not fluid – object collisions) so I’ll try to find a project where I can see a difference with and without using the GPU.

By the way, Steve, if you’re able and willing to divulge it, what’s the name of your company? I’d love to watch for your work just so I can say, “I know that guy.” 😉

[Kale Collins]

Hey all~ I appreciate the feedback so much. It’s been a great help. When both of you noted the “bugginess” in RF-it was good to know I wasn’t the only one.. also you all should know I am working with the most recent crack I discovered of the RF plug-in. (So that may contribute to the the lagginess.. and I have wondered if the legit one would make an evident difference.)

I did follow the steps you tested Jim, and for the most part my computer seemed to bare with me//Also I”m working on a 2010 Macbook pro, however updated it is still very very laggy. So I was intrigued to hear that you also said the simulation was slow- had no idea polygyons could play a role in that, does it really make a big difference?
Changed the res to .1 a suggested, in order to play the sim realistically and that worked well- still laggy though for my laptop.
Then created the initial state at around 45 frames
cached simulation (takes at least an hour) and then cache mesh (about an hour). — I wonder if this timing is because of the amount of polygons/ I hadn’t shrunk the cube/container yet- partially because when I try to change the size of the cube the mesh still stays the same… maybe I should cache the mesh to see if the container will shrink, the timing just takes forever.
That would also make sense because when I render the animation my water fluid within the container is not settled yet.
And Also that the crown is not in tact…..maybe another glitch of me needing to recreate it.
As I am typing this it seems to be making more sense of what I need to do.
Thanks so much!

~{^-^}~

[Kale Collins]

Update: my file crashed, not surprisingly. Luckily I had many saved incrementals however I do notice that whenever my file crashes, the affiliated, or previous incrementals are slightly corrupted. And now unable to perform certain tasks- as simple as creating an initial state. Also the color vividly is more glitchy.
What systems are the best for working with these simulations?

~{^-^}~

[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.

[Jim Scott]

Kale,

Once you have cached the simulation and mesh, if “Use Cache” is enabled any changes you make (fluid resolution, cube/container sizes, crown, etc.) will have no effect because the program is using the cached simulation and meshes for playback and not looking at those changes. You will need to disable “Use Cache,” make your changes, and recache everything.

To clarify the necessary steps: To speed up the initial experimentation stages, use a low fluid resolution and disable the mesh so only the fluid simulation is running and all you see is particles. This includes setting up an initial state. When you’re happy with the simulation disable “Use Initial State,” increase the fluid resolution to your desired setting, and then play the simulation again to the point where the fluid has settled and create a new initial state. Since the particle interactions will depend on the fluid resolution, more particles will result in more interactions and it will probably take longer to settle down. Run the simulation again (still no mesh) and check that you’re still happy with the crown. Once you’re happy with the whole fluid simulation, enable the mesh (with your desired settings) and cache everything. Theoretically this last step is not necessary as the rendering process should run through all the math before rendering each frame, but I’ve found that sometimes when I skip the caching it screws up the rendering. To be safe, cache everything and then render. The rendering will be faster because all of the caching is already done.

When playing around with your original project I found that I had to delete the whole RF Scene and recreate it in order to get the project to work. Either something gets lost in the upload, or chalk it up to a bug, but when I just ran it from its original state there were no particles being created.

Lastly, don’t forget to use Realflow’s “Help” button at the bottom of their settings in order to get to the online manual.

Good luck.