Fix issue with anisotropic surface reconstruction

[doyubkim]

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.

[Immocat]

The "hole" issue #130 is fixed, but the "band" is still there if using a low-resolution grid(grid-spacing 0.01), which other methods don't have.

But a high-resolution grid could compensate it.

I think the "band" issue is an open question and may be solved by a new method based on the original anisotropic method with some improvements. But for now, at least the severe hole bug is fixed!:smile_cat:

[doyubkim]

@Immocat I have a hypothesis for that particular issue which is the fixed kernel radius multiplier for the sampling. Do you mind attaching the .pos file for that frame?

[Immocat]

@doyubkim frame_000011.pos

[dokipen3d]

@doyubkim So you think that we need to round up the kernel radius to make sure that it cover the far corners of the voxels? ( i hope that makes sense). So that when you interpolate, all 8 points on the grid have had the right data splatted to it. So it the kernel isn't big enough then 3 voxels might get data splatted to it but the others might not get their contribution.

[doyubkim]

@dokipen3d thank you for your insight! I was thinking somewhat opposite. The banding issue mostly happens when the density doesn't fall off smoothly so I thought it could've been caused by the outer extend of the kernel is clamped for some reason. That's still not confirmed, though. The root cause can be something else. Let me take some time and investigate on this.

[dokipen3d]

I've just been chatting with my boss about this and he thought it was something similar. If you have a lot of particles near one grid point and you keep splatting then you are going to get a square wave almost. The next grid wouldn't get much because the kernel falls to zero at that distance. Globally normalizing didn't work for me as areas without many particles get very low densities, even though they might be the areas we are trying to capture (thin areas)!

[dokipen3d]

One of the things I've realized is that I am not using the particle density division in my kernel so that would explain why I'm seeing strange values that aren't normalized. I'll need to recompute the sph densities for my voxel splat stage. I was getting confused with the kernel for the splat as well as the covarient generation.

Should it matter that the spline kernel used in the splat is different from the sph kernel used to create the densities? the paper mentions a bpline but others use variations on cubic and wpoly6 sph ones.

I guess I need to also generate the densities for the voxel splat with the voxel splat radius independent of the SVD stage.

[doyubkim]

@dokipen3d that's really good to know. Yeah, I think concentrated density would make more sense if you think about the orientation of the anisotropic kernel at the slope area. If it was due to any clamping kind of an issue, it would look more like the hole in #130. Thanks for the input!

BTW, I'm taking somewhat different approach for the splatting. Instead of iterating particles and splatting their kernels on to nearby grid points, I iterate grid points and query nearby particles from a kdtree and then compute the weight function.

[dokipen3d]

I am doing a gather operation too. Sorry I was talking in a scatter sense from the perspective of the particle but mine is the same as yours.

I was trying different kernels too and luckily had your book on my desk as I always have to look up that sph kernel!

It wasn't clear to me what this bit means in the paper....

"It is necessary to point out that the equation of W is depending on the SPH simulation, since different SPH schemes can use different W’s for density computation. For our examples, we use the B-cubic spline kernel from Becker and Teschner"

..does that mean that the P spline in the W (eq 7) is the SPH kernel? If its p or wij, then that doesn't correlate with the densities from the SPH kernel right?

[doyubkim]

@dokipen3d my understanding is that the same kernel used for estimating density should be used for Eq (8). For Eq (7), as paper mentions below, it becomes regular SPH kernel if you use identity matrix / h for G which is Eq (5). The choice of P in Eq (5) is up to you I think -- you should be able to use standard SPH kernel.

@Immocat: So coming back to the original topic, the banding problem, I ran numerous tests and so far I think such an aliasing is caused by squashed kernel generating steep kernel fall-off, which is along the line with @dokipen3d mentioned above. To prove it, you can try running iso tropic kernel (with -m sph option) with 2x grid size, but everything else fixed. For instance,

bin/particles2obj -i frame_000011.pos -o iso_002.obj -r 150,100,75 -g 0.02 -k 0.036 -m sph

will give similar aliasing artifacts to the result from

bin/particles2obj -i frame_000011.pos -o aniso_001.obj -r 300,200,150 -g 0.01 -k 0.036 -m anisotropic

Sp yeah, there is a trade-off using anisotropic kernel. I think using adaptive grid (like octree) for the meshing will address the problem, but doesn't seem to be a bug in the code. @Immocat if you agree, I will merge this PR first and revisit the aliasing issue when tackling #131. What do you think?

[dokipen3d]

Thanks for looking into this! One of the things that was brought up in a discussion at work is the fact that when you have an implicit elipse, you can divide by the gradient to normalize the distance values. Can the sph kernels be divided by their gradient to make them squashed kernels but still have consistent falloff? I may be off base but thought I would bring it up.

[Immocat]

@doyubkim Sure. The "banding" is more than a bug.

[doyubkim]

@dokipen3d that's a great idea, but in this case, the resolution of the grid is mainly causing the aliasing. To make the gradient smaller, we can either scale it down or make the support wider. But even with scaling, the low-res grid won't capture the mid points along the kernel slope which will cause the aliasing artifacts. Making support wider will fix the aliasing, but then it will introduce overly smoothed distribution. For smooth and planar surface like @Immocat's example above, the wider kernel will work. But for other cases such as splashes or thin water sheets, it can make things too blobby.

[doyubkim]

Thanks, @Immocat! I opened up #133 to track the banding issue separately.

[doyubkim]

@Immocat @dokipen3d let's use #133 to continue this thread. This has been a really amazing discussion!

[dokipen3d]

Yes it's quite fun trying to figure this out :)