You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
By default, ad hoc meshing uses a cubeSize of [128, 128, 128] (when specified in mag 1). For mag 64, this corresponds to a cubeSize of [2, 2, 2] and with a padding then [3, 3, 3]. However, this seems to produce incorrect meshes for some reason.
As a workaround, one can run window.__marchingCubeSizeInMag1 = [4096, 4096, 4096] in the current tab. The default cube size doesn't seem well chosen for these coarse mags. Therefore, I think, we should adapt the front-end to send different cube sizes to the back-end.
However, I'm not 100% sure why small cube sizes don't work at all. Is it problematic if a bucket contains only one segment and then no mesh is returned for that bucket or something like that?
The text was updated successfully, but these errors were encountered:
By default, ad hoc meshing uses a
cubeSize
of[128, 128, 128]
(when specified in mag 1). For mag 64, this corresponds to acubeSize
of[2, 2, 2]
and with a padding then[3, 3, 3]
. However, this seems to produce incorrect meshes for some reason.As a workaround, one can run
window.__marchingCubeSizeInMag1 = [4096, 4096, 4096]
in the current tab. The default cube size doesn't seem well chosen for these coarse mags. Therefore, I think, we should adapt the front-end to send different cube sizes to the back-end.However, I'm not 100% sure why small cube sizes don't work at all. Is it problematic if a bucket contains only one segment and then no mesh is returned for that bucket or something like that?
The text was updated successfully, but these errors were encountered: