I have found that if I move the Surface3 for a particle emitter (used in FLIP or PIC) then the particles don't get emitted.

I have tracked this down to the region BoundingBox calculated in VolumeParticleEmitter3::emit(...)

Specifically this code here

BoundingBox3D region = _bounds; if (_implicitSurface->isBounded()) { BoundingBox3D surfaceBBox = _implicitSurface->boundingBox(); region.lowerCorner = max(region.lowerCorner, surfaceBBox.lowerCorner); region.upperCorner = min(region.upperCorner, surfaceBBox.upperCorner); }

Since my moving emitter is an implicit surface created from a Sphere this code runs. It then calculates the lowerCorner of my box to be greater than the upperCorner.

This means that in the forEachPoint method

_pointsGen->forEachPoint(...)

It can't loop over the points in the box because lower.x > upper.x. Which means that this

double boxWidth = boundingBox.width();

Produces a negative number, so no points are emitted.

This revision fixes Issue #130 which was caused by the singular value clamping (taking max instead of absmax). It also includes VSCode setting fix which was outdated.

In the PIC solver, particles act as a fluid. And what is the liquid in the solver LevelSetLiquidSolver3? How can I save fluid data (positions, velocities, forces) in a LevelSet solver? And how can you create a mesh, based on the LevelSet solver?

This revision includes:

• Consistent default parameters for ImplicitTriangleMesh3 between C++ and Python APIs
• Python APIC example fix (margin=0 should not be used). This issue was reported in issue #191

This revision adds/fixes Python API for ImplicitTriangleMesh3 and marchingCubes. It also adds new Python example, apic_example03.py, to demonstrate new/fixed features.

Is it possible to animate during the simulation? For example, enable the oneShot parameter at the emitter, and then after 10 frames turn it off. Or change the position of the collider. Or change the initial velocity at the emitter.

I'll add HPX multiple tasking system such as Intel TBB and OpenMP. HPX is the C++ Standard Library for Parallelism and Concurrency(https://github.com/STEllAR-GROUP/hpx).

Hello, douyubkim. I just discoverd the following problems. It is about the second derivative of poly6 kernel function. In your code:

inline double SphStdKernel3::secondDerivative(double distance) const {
    if (distance * distance >= h2) {
        return 0.0;
    } else {
        double x = distance * distance / h2;
        return 945.0 / (32.0 * kPiD * h5) * (1 - x) * (3 * x - 1);
    }
}

But I calculated it by hands for serveral times and wrote a different version:

inline double SphStdKernel3::secondDerivative(double distance) const {
    if (distance * distance >= h2) {
        return 0.0;
    } else {
        double x = distance * distance / h2;
        return 945.0 / (32.0 * kPiD * h5) * (1 - x) * (5 * x - 1);
    }
}

It's just 3 should be replaced with 5 in that equation. I know it was missing from any test because we just use the second derivative of spiky kernel function instead of poly6 kernel function.

Meanwhile, there is also a small mistake on Page 133 of your book. It's about formula (2.9), the equation of state. I check out the paper (Becker M, Teschner M. Weakly compressible SPH for free surface flows[C]//Proceedings of the 2007 ACM SIGGRAPH/Eurographics symposium on Computer animation. Eurographics Association, 2007: 209-217.) and find that you just put the gamma exponent in the wrong place. The code shown in the book is right.

Thanks.

I have a Visual Studio 2017 Community. In Release mode, the project refuses to compile. Not enough memory. I have 8 GB Windows 7 64 bit.

In Debug mode, the compilation is successful.

Hi, It's me (#109) again :smile_cat: . I find a problem with anisotropic point to implicit3.

What problem:

Here is a screenshot: It seems not correct for a dambreak at frame 0.

How:

I just run a sph dambreak demo similar to sph_sim example 3, and here is the .pos file at frame 0 that I got. frame_000000.pos

And then, I tried to reconstruct the surface using the anisotropic kernel.

./particles2obj -i frame_000000.pos -o frame_000000.obj -r 300,200,150 -g 0.01,0.01,0.01 -k 0.036

(kernal radius:0.036, resolution is 300 200 150, and the gridspacing is 0.01, 0.01, 0.01. sph example 3's domain is 3,2,1.5, so I think it is reasonable)

My goal is to get a surface as tight as possible to render. My sph particle radius is 0.02(and the kernel radius is 1.8 * radius) as default, so I chose 0.036 as reconstruction kernel radius. I'm not sure if it is appropriate. Finally, I get the .obj as the screenshot shows.

My opinion:

I looked into the source code and the original paper

I find that the code is a little bit different from what the paper describes. The main difference is in equation 15. Instead of using the magic number k_s = 1400, the code uses std::pow(relV, 1.0 / 3.0) at line 152 in "anisotropic_points_to_implicit3.cpp"

I do not understand why the code uses "pow 1/3", but I tried to use the magic number 1400 in the same way as the paper, and the problem is gone! Here is the screenshot using k_s = 1400. (Sorry for the light spot in the middle. It is the UI of Blender)

I've not tested the 2D version of the anisotropic kernel, maybe it suffers from the same problem.

That's all I found... I hope I describe the problem clearly. I will maintain the picture and the .pos file till this issue is closed.

The Mitsuba renderings in the examples video and the book look great. Is it possible to add the Mitsuba project files and possibly scripts that were used to create these images? Unfortunately I only see the volume export for smoke simulations in the source code.

Equation 3.18 takes the relative fluid-collider velocity for boundary projection. This does not seem correct. Consider the simple case of of verctical wall (normal_collider=(1,0) uv_collider = (0,1) and uv_liquid_boundary=(0,0). Relative velocity then is uv_rel = (0,-1) and the forumla in the book projects this to the wall which gives boundary_constrained = (0,-1)
This does not seem physically plausible, because the uncontrained velocity was (0,0) and is "suddeny accelerated" to (0,-1). So I think we must take the liquid velocity and replace its boundary-normal component by the boundar-normal-component of the collider. (Using relative velocity is important in other contexts such as friction forces, but should not be taken here IMO)

P.S.: It would be really useful to always give some source from the literature for such kind of formula, as Prof. Bridsen does in his book about fluid simulation development)

Projecting this
The formula in the book would project the relative velocity , i.e. .-1 which

While relative velocity is necessary for drag forces,

According to my understanding, the otherPoint in the function SurfaceToImplicit2::closestNormalLocal is a point described by local coordinates. while the code use _surface->closestNormal(otherPoint), which treats this otherPoint as a point in the world coordinate system, perform a localization and then calculate the normal

Fluid Engine can throw a error that prevent me from a successful build on my environment (MacOS big sur, clang 11, cmake 3.19.6)

adding this line in the root CMakeLists.txt may help! (I put this line under the cmake_minimum_required(...) line)

cmake_policy(SET CMP0025 NEW)

a subtle fix advice, best regards!

When I work MinGW build on 32-bit system, I saw that some unit tests are fail. We need to fix related code.

[----------] Global test environment tear-down
[==========] 793 tests from 166 test suites ran. (3277 ms total)
[  PASSED  ] 781 tests.
[  FAILED  ] 12 tests, listed below:
[  FAILED  ] VolumeParticleEmitter2.Emit
[  FAILED  ] Vector.BasicGetters
[  FAILED  ] TriangleMesh3.ClosestIntersection
[  FAILED  ] Timer.Basics
[  FAILED  ] SurfaceToImplicit3.ClosestIntersection
[  FAILED  ] SurfaceToImplicit2.ClosestIntersection
[  FAILED  ] SurfaceSet3.ClosestIntersection
[  FAILED  ] SurfaceSet2.ClosestIntersection
[  FAILED  ] MathUtils.MonotonicCatmullRom
[  FAILED  ] ImplicitSurfaceSet3.ClosestIntersection
[  FAILED  ] ImplicitSurfaceSet2.ClosestIntersection
[  FAILED  ] Pcg.Solve

I am running a fluidics simulation in a robotics platform and I am currently pausing the simulation every few steps to mesh the fluid particles. Is there a way I could use the xyz to obj capabilities of fluid engine dev so I will not have to run the partciles2obj examples each timestep?

Currently, I use system to run the examples from the terminal. Can I do it without this extra I/O? It would be amazing if there was a way.