Issue:
Shelling a Boolean Union inward doesn't create the result I expect. It adds a wall or a gap between the bodies.
Applies to:
- Shell
- Implicit modeling
Cause:
A wall or a gap can appear between the two implicit bodies due to the fields of the bodies. When the two shapes are Boolean Unioned together, it adds their fields together. Therefore, when the Implicit Bodies are shelled inward, it follows the contour of the field, creating either a wall or a gap depending on the fields of the original bodies.
If we use the Shell block on this Boolean Union of two boxes, the result lines up with the shape of the contours, depending on what Direction we choose Outward, Inward, and Center. Therefore, if we shell it inward, it adds a wall between the two objects.
Solution:
To shell inward without a wall or a gap, you need to make sure the boolean union objects are overlapping slightly, then you convert the Boolean Union into a mesh and then back into an implicit. When you do this, it won't have a wall or gap between the two shapes because it won't recognize the individual fields of the shapes from before they were unioned together.
If you want to learn more about implicit vs boundary representations, check out this blog.
Comments
This solution makes no sense. It's not a "solution" it's a hack for incorrect behavior. This is a bug that you all should fix! In order to make ntopology more efficient, you're clearly not recomputing the field of the boolean'd object, but just assuming each section is correct and valid. But you should be, there's no reason not to, and if you recompute the field, then you will find that it is incorrect. I understand the efficiency argument here, but at the least there should be an option for users to treat them as a a combined object (slow, accurate) or separate objects (fast, inaccurate, but the inaccuracy may not matter in many cases). There aren't enough tools when doing 2D-->3D part conversions to work around this bug elegantly, and meshing-->unmeshing is WAYYYYYYY slower than anything else, and introduces discretization errors!!!!!
Incidentally, I understand that a big issue is that the full computation is slow. One workaround on the dev side could be to render the approximate union to the screen, but to output the correct SDF when exporting to file. It is likely the same algorithm with the same approximate complexity when outputting to file in either case.
Please sign in to leave a comment.