ship in the ocean

actually it’s 2670 ,my that’s why every text on the screen must be copyable :slight_smile:
anyway, my observations are that the cpu is not the most important one, the ram speed is the main bottleneck, and for some scenes involving huge particle count (about 50M) the most important is…the HDD speed :slight_smile: i’m speaking about the ink in water scene, we observed this effect simulating it on different machines.

Have you done much tests with ram speed and it’s effects? If it’s significant and available in a handy comparison i’d be able to use it to get some new ram for our next phoenix job :slight_smile: already got an SSD in the sim machine.

Ok. good to know. I use ssd for system files, but i will buy one for the sim too if it’s a noticeable difference.

the hdd is important only in cases of simple particles with very big count, if you have foam or splash the calculation time is too big compared to the hdd time.
for fire and smoke sim the ram speed is the most important, if you have significant foam the cpu is most important

Now about the ship in the ocean, My sim is completed. But I can’t render the phoenixFD athmospheric.

I get UNHANDLED EXCEPTION: Updating athmospheric effects

I started back from the original file and loaded my cache and now it renders without crash. I may had changed something playing with the file.

You use strange render settings. Fixed image sampler to 3 and global subdivs to 1?

if you have the cache file that causes the crash, we will appreciate to have it for investigation.
about the render settings - compared to the “usual” render settings used for interiors and other fields, they are really strange. the foam and the smoke are volumetric objects and this kills the rendering, we are trying to minimize the rays count. we use ambient light instead real GI, we use directional light or sun with subdiv=1, and other tricks. if you see similar movies made with houdini or naiad, they always use nuke and compositing. this also helps a lot to reduce the render times, but we do not use it, because it involves 3rd part software. the rendering performance is very important, because it is easily exchangeable to quality. if you reduce the render times twice, you can double the particle count. very low count of viewers can recognize the real GI, especially in outdoor scene, but all the viewers can recognize the bigger particle count.
about the image sampler - when you render particles in bubble or splash mode the fixed image sampler has no alternative. the reason is that the adaptive sampler easily can skip a small bubble and will not trace more rays because it seems that there is nothing in this pixel. this causes blinking in animation. i know in the ship scene we use point mode, it may be rendered with adaptive too, but you have to decrease the default settings, otherwise the foam will produce big count of rays, that actually do not contribute to the quality.

Vlado promised to look deeper into vray-phx relations :slight_smile:

I’m rendering it right now on my render farm with GI and my usual vray settings. I get 13 minutes with my fastest computer to 28 on my slowest. And it really beautiful! I’ll put it on youtube for comparison when my whole animation finished.

And about my crash I discovered it was because I was rendering on a computer on my farm with an older version of phoenix. I installed 2.2.0 rev.24819 everywhere on my farm and no more crash! Sorry about that.

I took the sample scene in the PhoenixFD sample folder, I simulated it and started with my regular render settings in vray to get better AA.I also turned on GI to see how lojng it would be.

It took around 1 minute a frame to simulate on my new dual Xeon E5-2680 v2 with 64 GB of ram.

It took around 13 minutes to render on my faster computer (dual Xeon E5-2680 v2 with 64 GB of ram) the average frame time on render farm was 26 minutes (mostly dual xeon 2.7 GHZ so it took in all 1 hour and 26 minutes on my farm for 940 frames.

The resuklt of the sim is different from the one published by Chaosgroup. It’s because Ii used a different revision. I would have to make my sim box larger cause the foam is getting out on the sides causing straight lines. Also my foam trace is not as long as the chaosgroup result.

Nice one Joce!

But your ship… with those colors, its a moving target :wink:

haha! It’s just the sky’s GI reflecting on the boat!

As everybody I like that scene :slight_smile:

I am working on a scene like that with a ship with similar dimensions currently using nightly 25954 (no Splash-Size in the UI?)

As a sidenote: Basically I don’t like anything but 1 unit = 1 any other unit being cm or m of ft or whatever as we had some troubles with mixing dimensions form different sources and xrefs and animations. So I build the scene from scratch with 1 world-unit = 1cm following the tutorial and using a not so modern ship and slower forward-movement.

How would I approach the scene if the ocean had big waves in it?

Animating the ship should not be the tricky part. Adding displacement after the simulation just in the rendersettings seems too simple as the waves do not splash on the hull and such nice stuff.
As a start the oceantex looks pretty good but how would it be considered in the simulation?

i have seen a technique (never tried it) when a geometry surface is displaced by the displacement texture and the simulation is run with thin layer of water over it. actually the surface may be a source, not sure.
we are considering a tool to make this automatically, because many people need it.
about the splash size - currently the splash size is calculated automatically by the amount of the splash particles corresponding to single water particle (the splash multiplier). this ensures good water-splash transition, but if you are not satisfied, you can change the size in the rendering using the size multiplier of the particle shader. the explicit size was producing too many problems, it was introduced by the assumption that everyone knows what is the real size of the droplets, but in a ship scene like yours the droplets are billions, you cant cover all of them using the real size. so, now the size is relative to the grid resolution, multiplier 5 means the average droplet volume is 1/5 from the grid cell volume.

Sorry for kind of hijacking this thread :wink:

Sounds like some fun R&D is to do :smile: (… I need more time for this project)
Which Conservation- and MaterialTransfer-Method would you recommend as a start? Is FLIP the best choice for all liquids now? Shame on me that I never touched it yet.

Thank you, seems to be useful.

in almost all the cases flip gives better results than the grid solver, except one - the grid is able to settle to a perfectly flat calm surface, flip can’t do this.

because many users are asking for the ship scene reworked for flip core, it’s good to attach it here , you can see the result in this video
ship.zip (994 KB)

Here is our “ship in the ocean”-version (pre-flip):

Worked very well, thank you guys for this nice plugin.

Good stuff! Thanks for sharing!

Will this tool be developed?