[Bf-committers] BMesh Booleans, ready for testing.

[Campbell Barton]

On Sat, Dec 12, 2015 at 9:22 PM, Mikhail Rachinskiy
<wellmaderice at gmail.com> wrote:
> Hi Campbell,
>
> My primary specialization is jewelry design, that is why I am very depend
> on quality and fast boolean operations, and I am happy to report that your
> implementation of boolean tool is significantly faster than current Carve
> implementation, simple boolean difference operation with two objects both
> 100 000 faces each computes instantly compare to several seconds with
> Carve—this will greatly improve my non destructive modeling workflow.
>
> Of course BMesh implementation does not yet handle custom data (edge
> crease, materials etc.), that might explain fast execution, I hope later
> you will make custom data handling optional specially for those who wants
> fast boolean operation with dense meshes and doesn’t need custom data (like
> me most of the time).

BMesh-Booleans *does* handle custom-data, edge-creases, bevel weights, UV's etc.
One thing that it doesn't do right now is remap materials between the
objects - but thats simple to resolve.

> But I guess it never can be too good, can it? Your boolean implementation
> fails every time with co-linear/co-planar geometry:
> Image: http://i.imgur.com/2ZhD8rz.png
> Blend file:
> https://dl.dropboxusercontent.com/u/29760931/temp/coplanar_bmesh.blend
> I can also provide you with the production scene example if you need it.

Agree this is a big limit, I'll spend some time to check on supporting it,
since it may be the difference between being able to replace Carve or not.

> And this is very serious drawback, since I have these kind of cases quite
> often, Carve implementation handles these with varying degrees of
> success—fine on low poly, fails on hi poly. It would be great if you make
> it work at least with low poly meshes.
> But if your solution to this issue would make booleans slower (as I’m sure
> it will), please make it as an option too, booleans that fast—makes me very
> happy.

Right, if supporting overlaps gives a significant speed hit, it could
be good to make an option since many use cases don't need to support
it.
Though I'd rather not make decisions based on speed yet since this
code hasn't been profiled or optimized.

>
> --
> Regards,
> Mikhail Rachinskiy
> jewelcourses.com
> rachinskiy.com
> _______________________________________________
> Bf-committers mailing list
> Bf-committers at blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers



-- 
- Campbell