isn’t that a flat surface you are using in the video? Anyway, I don’t know if they worked on it and I haven’t tried any build since a long time, but as I was saying I learned that this kind of behaviour is a know problem with FLIP simulations.
Actual Linux build:
– PACKAGE-INFORMATION –
Branch: fluid-mantaflow
Revision: dd075f2
Submodules: locale d3349b4 addons 142ef5b addons_contrib 15b25a4 tools 8ebcf63
OS: GNU/Linux, Architecture: x86_64, GLIBC: 2.19
Builddate: Do 12. Jul 12:13:43 UTC 2018
Filesize: 110589956 byte
Sha256sum: c6cf5b62ad0b2ba90b4656b4eb121175f711e33c5eb615017bee2d6890f403ae
URL: https://www.jensverwiebe.de/Blender/blender_fluid-mantaflow_linux64_latest.tar.xz
CHANGES SINCE 1be28f9:
-added guiding object velocity factor (UI option)
-improvements to keyframe parameters
-more sanity checks for fluid guiding
-fluid guiding overhaul
-Merge branch ‘master’ into fluid-mantaflow
…
Cheers … Jens
2 Likes
By flat I mean no angle, also, I think that if the domain is not square, the voxel gets distorted, I might try something similar but with a cube domain!
ah I see what you mean. Yes with a flat surface the problem would disappear. This kind of issue appears exactly in this kind of simulations, like the beach wave one. It really makes a huge difference unfortunately
I tested fluid guiding with liquids and it worked.
Mesh as a guide only works for simulation domain as liquid.
Liquid domain as a guide only works for simulation domain as liquid.
Smoke domain as a guide never works.
That’s because the simulation is voxel based, also, as I said, I think that if the domain is not a cube, it affects the simulation, I would need to test this, but I believe that if the domain is not a cube, it distort the simulation!
I think once you apply the scale it’s not necessary to have a perfect cube… I haven’t noticed any distortion in my tests…
Since last commit, everything works for fluid guiding simulation.
I succeeded to create smoke simulation guided by a liquid domain…
Or liquid simulation guided by a smoke domain.
But there is an issue that prevents to make serious work with fluid guiding.
Flow objects are taken into account by both types of simulation no matter what is their type.
So, to avoid to have a liquid simulation taking Smoke emitter as a Liquid emitter, I had to delete smoke emitter modifier. Simply, disabling smoke modifier is not working. Putting it into another layer, neither.
In theory, I could create one simulation in one .blend file, import it into another one and use it as guide for final simulation.
But it means that if result of final simulation is not satisfying ; to modify some aspect of guide (not taken into account by 3 available settings), I have to re-open original .blend file of guide.
The difficulty to affine your work by going back and forth, when you are testing general flow of simulation is annoying.
It is great to be able to animate weight, size and factor. But if you need to modify flow direction at a moment, boundary of guide because it should be better with or without a wall, add a collision object ; it is really frustrating to work without visual feedback of previous iteration in another file. Just because a bug where a gas simulation is changing liquid into smoke and liquid simulation is changing smoke into liquid.
3 Likes
Fresh Win64 build:
3 Likes
I’ve been using mantaflow builds for a while, I think it’s really great, but somehow I’m not been able to get a good result when using an animated moving collision object, with other builds the liquid reacted weirdly when colliding, with the latest build the liquid starts to disappear like it does with an outflow, does anyone knows what I’m doing wrong?
I couldn’t load a video because I’m a new user but here’s the link, fluid domain resolution 100 samples:
https://www.dropbox.com/s/ibzg3hl8bvjftl7/0001-0100.mkv?dl=0
Besides, does anyone knows how to give the flow an initial axis velocity like in elbeem? It’s one feature I used for making water fountains for example.
Thanks happy mantaflowing!
The idea behind speed of mantaflow is to use a narrow band of fluid particles.
So, instead of having particles in whole volume corresponding of the fluid, there is a narrow band at its surface.
Collision should create waves and drops.
Particles used to define surface will migrate to create these waves and drops.
If band is too thin or resolution or particles number are too low, holes will be created in surface previously defined and particles will no more be interpreted as top surface of a big volume of fluids but just as drops.
It is why you should check your simulation by looking at FLIP particles before meshing the result.
If particles are too distant, you have to change settings of domain.
If band was lost, volume will be lost.
thanks zeauro for your explanation, I did what you said increasing number to 5, width to 10, even minimum 18 and maximum 32, doubling resolution 200 but volume is still lost. Just with low resolutions it tends to not disappear. Could real world size be affecting this?
Yes. I forgot that aspect. At a small domain a big volume can correspond to a droplet.
Really, you should enable Show FLIP option in domain properties to debug.
You can try to disable adaptive stepping and decrease CFL value to increase number of substeps per frame and avoid to skip them.
But there is still a probability that you have encountered a bug.
I got show FLIP enable all the time, It just with the mesh it’s difficult to see it in the video.
I will try then changing real world size and disabling adaptive stepping with a decreased CFL,
thanks again!
nop, try both CLF 0.1 and 1 with real world size 10 and 100, but it loses almost 2/3 of liquid anyway. It’s a better result than the previous ones but still not what I think is expected to happen =(
Ok I think I got this working… this trick is to add the emitters to groups (smoke & fluid) then assign each to their respective domains under ‘fluid groups’… (Fluid guiding)
Oh, you are right. I forgot fluid groups.
It’s very temperamental at the moment… and can corrupt your file when baking the second simulation…
I already mentioned the same problem a while ago, even increasing the resolution.
I think they’re going to implement some kind of AA to try to solve the problem.
I always find it confusing about good configuration of Fluid Cache (in Linux). I think that for “Data File Format” I can make it work with “OpenVDB”.
If I start a simulation from a new file and add a new “Liquid” domain, in Cache the default path has the following format: “/tmp/blender_pMZ5jg/cache_fluid”, and this generally works. In this way, one folder is created in “/tmp/blender_pMZ5jg/cache_fluid” containing “data” and “mesh” folders. A folder is also created in the path where .blend file is located, with the same name as the .blend file containing “bphys” files.
But sometimes when I am modifying an old file, for example in a mesh where I had configured as Domain, if I eliminate Fluid Mantaflow from that mesh and I add Fluid Mantaflow again and configure it as Domain, then the created cache path is “//cache_fluid” sometimes. In this last path format the simulation never works.
Regarding last changes made by Sebastian in recent days, apparently Force Field (at least Wind), it does not seem to be working.