I have been using the BVH-CSG-0.0.11 library in my code.
In this example I am doing something very simple
I am INTERSECTING the pink plate and the green cylinder
IMHO this is hardly a corner case.
The resulting mesh looks good visually
However isWaterTight() fails
Why would this be?
Thanks much
OLDMAN
isWaterTight is not a public or documented function and should not be used - it’s not functional at the moment. Please stick to the API specified in the README.
Since that’s the case, I’m doing something simpler.
I am using simple.js, provided along with the 0.0.11 software distribution, as my example.
I am INTERSECTING a box and a cylinder.
Case 1:
The cylinder is entirely within the box. Thus the intersection = the cylinder.
A wireframe display of the result triangle edges looks good as can be seen from this image
Meaning, they all appear to be 2-connected edges.
I’m computing the volume of the intersection with computeMeshVolume().
My hand calculation says the volume should = PII * (R**2) * H
Which works out to 3.1416 * 0.5 * 0.5 * 1 = 0.785
However, computeMeshVolume() gives me 0.329
Is there a scaling transformation hiding somewhere in the tree?
I have called scene.updateMatrixWorld( true ) before calling this function.
Please explain what I may still be doing wrong.
Case 2:
The cylinder is now approximately halfway through the box. Thus the intersection = half a cylinder.
A wireframe display of the result triangle edges looks a bit suspicious, as can be seen from this image.
Some of the edges appear not to be 2-connected.
I understand that this software can produce non-manifold results in the case of poor precision and corner cases. But I would say this is neither. In fact, it couldn’t be simpler.
Please explain what’s going on here.
Thanks much,
OLDMAN
However, computeMeshVolume() gives me 0.329
I’ve answered this and where the function comes from in your previous thread. It’s possible that answer from the stackoverflow thread is incorrect or has other issues I’m unaware of such that it should be removed. It’s worth looking into but it’s not a high priority at the moment. As I’ve mentioned before you are free to help investigate these problems, as well.
Also please provide example demonstrations of your code with jsfiddle. People should not be expected to recreate your issues in order to help.
Some of the edges appear not to be 2-connected.
There has never been a guarantee or requirement that all edges have a 1-to-1 connected sibling.
Here’s an update from my end.
I am using INTERSECTION within doubly nested loops in my application. The intersector gets called a few/several thousand times in the course of running the application on various datasets. I have my own version of getVolume() and isWaterTight(). Sloppy, inefficient, but hopefully correct code. I’m finding that
my isWaterTight() fails about 50% of the time.
My getVolume() may or may not give the correct answer in a non-water-tight situation. Very hard to programmatically distinguish. My application depends on a correct volume calculation to make certain decisions downstream. Naturally, that code is failing quite often. I have some ideas with other measures of “enclosure” but they are very expensive computationally. Wondering what to do 
And on the point of helping with debugging/finding solutions, I will try. Starting with trying to understand jsFiddle.
Best,
OLDMAN
Clockwise, from opposite you, is counter-clockwise. The word is a borrowed term, not a guarantee. Similarly, watertight depends on the origin(s) as much as vertices. Maybe you have a concavity, stray vertex, or extreme unit? Test an inverted model (not a triangle or plane). Perhaps CSG “water-tight” has a winding-order of construction.
What is your goal? The operation may benefit from chained methods. Close holes, weld vertices, and simplify. This will help monitor performance, similar to raycasting a hitbox. Even volume tests are the result of an approximation.
~Happy laundering! SBF
Not aware that water-tightness is dependent on all those factors. I am simply checking if each triangle edge occurs exactly twice, once in each direction. Of course, after merging “coincident” vertices.
My logic is that if the object is water-tight, I can calculate its volume reliably. If not, all bets are off, The volume calc may or may not be reliable. I rely on the magnitude of the volume to tell me the “extent” to which two parent objects are inter-penetrating. And I use that knowledge to drive some downstream logic in the algorithm.
Those mesh-healing ideas you suggested are notoriously iffy. There are many such software libraries out there, but IMHO, they fail as often as they succeed. Also, realize that the object resulting from the intersection can have very wide variation. Right from just a bunch of triangles in space all the way to a valid solid. The concept of volume doesn’t even apply to the former.
Indeed, lots of laundering :)
OLDMAN
I have my own version of getVolume() and isWaterTight(). Sloppy, inefficient, but hopefully correct code. I’m finding that my isWaterTight() fails about 50% of the time.
I have proofs of concept for determining water-tightness in the project but it requires finding sibling edges for each edge which may be a many-to-many relationship especially after clipping. There are other triangle-clipping approaches that may yield more well-formed edges more frequently but I have not implemented them at the moment.
My getVolume() may or may not give the correct answer in a non-water-tight situation. Very hard to programmatically distinguish. My application depends on a correct volume calculation to make certain decisions downstream. Naturally, that code is failing quite often. I have some ideas with other measures of “enclosure” but they are very expensive computationally. Wondering what to do
Without code or an algorithm it’s impossible to say. Either way - slow or not - I would focus on getting a correct result first and then improving performance later.
you are in my thoughts