doyubkim / fluid-engine-dev

Fluid simulation engine for computer graphics applications
https://fluidenginedevelopment.org/
MIT License
1.9k stars 266 forks source link

Error generating mesh #289

Open PavelBlend opened 4 years ago

PavelBlend commented 4 years ago

It seems to me that the polygon mesh generator does not work correctly at some points. The mesh is not Manifold. 01 test_apic_method.zip

doyubkim commented 4 years ago

Looks like a marching cube problem for sure. Let me take a look.

utilForever commented 4 years ago

I'll check this issue. Thanks. :)

PavelBlend commented 3 years ago

I tested the simulator again and noticed one thing: These invalid triangles are only created on the walls of the domain. I started to study the code in the file src\jet\marching_cubes.cpp to get a rough idea of the cause of the error. I saw that the mesh generator uses different algorithms for creating triangles for the walls of the domain and for the triangles within the domain. The error occurs in blocks of code that have comments: Construct boundaries parallel to x-y plane Construct boundaries parallel to y-z plane Construct boundaries parallel to x-z plane https://github.com/doyubkim/fluid-engine-dev/blob/45b4bdbdb4c6d8c0beebc682180469198203b0ef/src/jet/marching_cubes.cpp#L395 I hope this information will help you understand the cause of the error.

doyubkim commented 2 years ago

Thanks @PavelBlend ! So I guess what’s happening here is that boundary mesher is adding more triangles and the topology of it does not agree with the surface mesher. Maybe it’s direction-dependent; one side of the domain works fine but the opposite side might show this problem. @utilForever: one way to fix this is to make a simple repro case with two volumes close together and see how the lookup table is being referred for the particular case.

PavelBlend commented 2 years ago

@doyubkim I created a small example:

from pyjet import *
import numpy as np

ANIM_NUM_FRAMES = 360
ANIM_FPS = 60
Logging.mute()
# Create APIC solver
resX = 50
solver = ApicSolver3(resolution=(resX, resX, resX), domainSizeX=1.0)
solver.useCompressedLinearSystem = True
# Setup emitter
sphere = Sphere3(center=(0.5, 0.5, 0.5), radius=0.15)
emitter = VolumeParticleEmitter3(implicitSurface=sphere, spacing=1.0 / (2 * resX), isOneShot=True)
solver.particleEmitter = emitter
# Convert to surface
grid_size = 1.0 / resX
grid = VertexCenteredScalarGrid3((resX, resX, resX), (grid_size, grid_size, grid_size))
# Make first frame
frame = Frame(0, 1.0 / ANIM_FPS)
for i in range(ANIM_NUM_FRAMES):
    print('Frame {:d}'.format(i))
    solver.update(frame)
    pos = np.array(solver.particleSystemData.positions, copy=False)
    converter = SphPointsToImplicit3(1.5 * grid_size, 0.5)
    converter.convert(pos.tolist(), grid)
    surface_mesh = marchingCubes(
        grid,
        (grid_size, grid_size, grid_size),
        (0, 0, 0),
        0.0,
        DIRECTION_ALL,
        DIRECTION_NONE
    )
    surface_mesh.writeObj('frame_{:06d}.obj'.format(i))
    frame.advance()

at frame 48 I get this mesh: 011111

Here is the obj file: frame_000048.zip

I think this is due to the fact that two drops are in the same voxel: 01000

The mesh generator builds a polygon between the drops.

utilForever commented 2 years ago

@PavelBlend Thanks!

doyubkim commented 2 years ago

Yup, I think this is definitely a marching square issue where its lookup table is not consistent with the marching cube.