I tried googleing it but did not find the name.
I have a cascade of boolean result issues and would like to run that by the developer.
Anyone knows who maintains develops the BMesh now?
Indeed bmesh solver has some issues.
It was Campbell that developed the new boolean algorithm, but his departure from daily work (I say daily because he’s still coding the occasional patch) means that there is currently no active development in the area of modeling (so the chances of bugs quickly getting fixed would’ve likely gone down).
On the second post which just appeared, there are currently some known limitations of the Bmesh boolean and the devs. are aware of it, but it’s unknown when they will be resolved or whether there is a desire to do so.
I’m sure it has, but what you’re trying to do doesn’t really makes sense from a “theoretical” standpoint. Your plane has no volume, so the “correct” solution for difference would be your original input mesh (i.e. the cube). Defining this operation to mean anything else may make sense from a usability standpoint, but you can’t expect all solvers to agree on something here.
Please take a few seconds before starting a new thread to consider whether a problem you are observing is actually newsworthy and belongs in the ‘Latest News’ forum. Thread moved.
Ops sorry I realized that afterwards that I posted this in the work forum.
It makes a lot of sense.
Volumes you can trim and split
Surfaces you can trim and split
Pretty old concept!
Ah thats too bad because this means that at least when dealing with surfaces (not volumes) the BMesh modifier is currently so buggy that it is tricky to use.
The speed of BMesh vs Carve is fricken fantastic! It crunches through dense mesh like nothing.
Hi.
No matter who is the developer. If you think a feature is operating in a wrong way, then this should be reported.
I think it would be best to start here by posing the issues one at a time to see if it’s something we’re doing wrong or it is a problem in the code.
Neither of these operations exist in this context. You have boolean difference, union and intersection on volumes. How would you define the volume of a planar surface? How an implementation handles such degenerate cases is basically “undefined behavior”. As I said, from a usability standpoint it makes sense to do something “useful” here, but not every implementation will agree on one behavior.
I would use the face normal. As if it was a portion of a huge volume of which we only know that small flat surface with its normal pointing up and the other side being inside the volume.
Edit: After some experiment, a plane does in fact cut a cube in bmesh boolean if the angle and size are right.
yeah that’s also possible.
bmeah sometimes can work with surfaces fine and then it fails.
beerbaron you view would be correct if the commands would only work with solids but bmeah works also with non planar open surfaces
for both target and tool body.
Fair enough, now you need to put a special case into the algorithm that detects whether it is a planar surface and then treats it that way. The point isn’t that this is not possible, but that this is a heuristic that isn’t defined in the original context. It’s unlikely that two different implementations will agree on something here.
Your idea of “it works” and “it fails” seems to be “it does what I wanted” and “it doesn’t do what I wanted”, respectively. In reality, what you get is rather how the algorithm happens to behave when it encounters invalid input data. The two algorithms are clearly different.
If the algorithm detected (and rejected) invalid input beforehand, you wouldn’t be posting this thread, but then it would also be slower. Instead, you are basically getting undefined behavior.
Do we really need to argue about this and loose ourself in semantics?
Volume or not it really should not matter, no matter if NURBS or Polygon.
The reason why I posted this thread is also that with Solids BMESH can create fantastic artifacts.
A quick link to the manual shows you that they also state it works with both:
https://www.blender.org/manual/modeling/modifiers/generate/booleans.html?highlight=boolean
Anyway Beer the point of me posting this was to get in touch with who made this or who maintained
it to see what the current intention ONLY is, what are unsupported options, and what are unexpected
results.
Lets be civil and focus on that.
This is not a semantic dispute (i.e. arguing over the meaning of words). You simply refuse the semantics.
Volume or not it really should not matter, no matter if NURBS or Polygon.
It absolutely matters, that’s my whole point. You refuse to understand the problem. The program offers you boolean operations on volumes. It doesn’t offer you trim or split, or whatever you would like it to do, even though these are useful operations.
You are most likely running into problems that aren’t bugs, but are rather the result of your wrong expectations.
A quick link to the manual shows you that they also state it works with both:
https://www.blender.org/manual/modeling/modifiers/generate/booleans.html?highlight=boolean
It works on open or closed volumes, not surfaces! Now, what’s the volume of an open polygonal boundary representation? There are different possible answers to this, but the hole needs to be closed somehow, otherwise the actual volume is undefined.
Either way, this likely refers to the Carve backend.
I quite well understand the problem - you on the other side seem not to understand the point of this thread at all.
BTW
A surface is nothing else than an open volume.
Otherwise I would have stated planar surface.
But a plane…
If the plane is considered an open volume, for which of the sides that volume is?. There should be a convention to take there, and apparently Carve considers the existence of Volume in the opposite direction to where normals pointing in the plane. I really do not quite understand what conventions are taking BMesh in such cases.
Regarding open volumes, in the following example you move the open volume up along Z. BMesh acts as Carve only as far as the volume ends.
By the way, I have the feeling that Union and Intersection in BMesh works in a more accurate way (mathematically) than Carve.
The question is how does BMESH and CARVE calculate surface intersections.
That is the important part.
If you deal with planar surfaces or open boundaries is afterwards a secondary questions
mainly answered by the first one already.
Carve is pretty much able to calculate a trim (boolean difference) with a solid or a planar surface.
Bmesh can do even the same. But with BMESH the geometric structure (density) of what is being cut is a deciding factor.
However and that is my main point of this thread also with volumes Bmesh has a significant bugs here and there.
It is also extremely picky when edges (target and tool body) overlap. This is specifically an issue when using symmetrical
meshes for the target and tool.
Here is a screen shot showing that the Fail boolean only works when the input geometry is extra subdivided
If not subdivided the volume has to be a solid being fully closed.
In addition to get a difference the boolean has to be set to intersect.
Making it a solid then you can use the difference command.
However this behavior does not apply to the other open surfaces
and they cut correctly.
After reading the code, if I understand it correclty, BMesh loops through generated islands, gets the first face, calculates a point on it and then casts a ray with (1.0, 0.0, 0.0) direction, and if it intersects, a hit is generated and the island removed.
This might explain why at certain positions a planar surface works cutting the corner of a cube but fails later when the surface cuts a bigger chunk of the cube
and why adding more geometry to the cube will help the boolean command.
Besides the bugs - issues I am madly impressed about the speed VS Carve