Fast collision

[chrisadamsonmcri]

In the first surface that is created, the “cerebrum” surfaces, if you have fast collision OFF it prevents the surface from having the high curvature it needs to penetrate into deep sulci. In addition, there are some cases where shocks form in the surface (a shock is where you have a V shape in a surface and the faces at the V apex cross over) and you get this spike that stays outside the brain because the collision detection prevents the vertices at the shock moving. When fast collision is turned ON for the cerebrum surface it doesn’t have this issue and it penetrates correctly.

For the “white” and “pial” surfaces you do need to have the fast collision OFF to prevent those errors you are having. There do seem to still be shocks forming for the “pial” surfaces which is why you get these “pointy” regions of pial surface at the fundi of sulci sometimes. I might need to alter the parameters to make the outward movement of the pial surface change so these shocks don’t form. It is possible that you are getting better results with fast collision off because it has fewer restrictions on curvature and overlapping faces. But the problem is that it causes some crashes due to said overlapping faces.

Any ideas for changing the parameters to prevent shocks?

[schuhschuh]

Yes, this is indeed a problem that occurs when the collision test is too sensitive / conservative.
The option --fast-collision-test relates to the case of non-adjacent faces, and enforces a certain minimum distance. When on, the distance is calculated between the (barycentric) centers of the triangles, otherwise it computes the "actual" minimum distance between the two triangles.

One way to avoid faces to get to a stage that they are this close is the use of the repulsion force, which is a weak constraint on minimum distance between faces (rather than a hard constraint). Also, the repulsion force considers a different "distance" than the collision test, and hence may not prevent the collision condition.

Secondly, if I remember correctly, I used this "Gaussian curvature force" to counter these "pointy" regions from occurring in the dHCP data. However, I think the structural dHCP pipeline uses the following settings instead, i.e., no Gaussian curvature based smoothing term:

gauss_curvature = 0
min-width = .1
fast-collision-test = False

The difficulty in case of the pial surface expansion is that in order to preserve one-to-one correspondences, you want to have iterative surface remeshing disabled. But this means that the remeshing cannot help to smooth out regions that are contracted, such as the fundi of sulci. What may help (besides increasing smoothness terms and reducing the iterative step size) is to remesh the white/cGM surface mesh sufficiently (at least in regions expected to contract) before deforming it? [The SurfaceRemeshing filter has some option for adaptive remeshing, based on a min/max edge length specified as scalar data array at each vertex.]