Page MenuHome

Bisect Modifier
Needs ReviewPublic

Authored by Krantz Geoffroy (kgeogeo) on Jan 7 2014, 12:02 AM.



It made the bisect operation as modifier.

Diff Detail

Event Timeline

Krantz Geoffroy (kgeogeo) updated this revision to Unknown Object (????).Jan 7 2014, 12:47 AM

rebase the file with git

Some comments on UI code.


I'd prefer one condition only. (md.bisect_object == False)


I would place the "bisect_object" higher in the panel, as the other values above depend on this.
General UI flow is: important ones on top, less important/depending ones beneath.

You can put bisect object and threshold in 1 row even, with corresponding labels above the 2 properties for clarity.

Krantz Geoffroy (kgeogeo) updated this revision to Unknown Object (????).Jan 9 2014, 12:27 AM

I've update the patch to add the possibility to use group of object.
So we can make multiple cut with only one modifier.
It work like it is but there is a BIG hack.
To make it work I have to convert derived mesh to bmesh at start of the loop and bmesh to derived mesh at end.
And this every time it looped.
else when I don't do I've a really wrong result with destroyed mesh.
must be a way to avoid this conversion every time but I can't figure out, I don't understand all with BMO_xxx.
Even you will never accept this patch, I would be really grateful to have help to understand what is the failure,
it's always great to learn anyway.

ps: I will make the clean up after, first I want to make it work good.

Addwed some quick remarks. Still thinking if a bmesh operator is a good idea, if more operations are to be done this way. Of course for optimal results the algorithm should work on derivedmesh data directly to avoid the conversion step.


No need to duplicate condition here, just store in a variable


Those should be unneeded if conversion is done in the loop, just set tmp to dm. Did this fail as well?


Indeed I think this should not be needed every time. I will try the patch tomorrow myself, no time now.


This is odd, there should be no need to convert: dm -> bmesh -> cddm


Using BMesh operators from modifiers incurs a fair bit of overhead, its good to get something up and running quickly - But I'd rather use BMesh functions directly (without BMO_ functions). its not so much extra effort.

I've a lot of question but I will ask later, make a list of question to understand flag, hflag ??
I there any doc for that?
Thanks for the first review.


yep it fail when I don't use tmp


yep I know, I've expected that it work directly but maybe I missed something.


I hope you find the time to try. Thanks


do you mean to use "bmo_bisect_plane_exec" directly?
not use BMO_op_initf, BMO_op_exec, BMO_op_finish?
Not sure to understand what you mean.

Krantz Geoffroy (kgeogeo) updated this revision to Unknown Object (????).Jan 16 2014, 12:02 AM

I've change a lot of thing according to what Campbell suggest (I think).
So to use directly BM function I need to create bmesh_triangle_fill file.
only move the executive code to appropriate file and convert it tto use only BM_XXX.
It work like this but I can't figure out the beauty and dissolve function for now.
I'm stuck with the bmesh flag thing I think, not sure what need to be or is flagged.
Anyway, am I working in the good direction??
Any tips with the flag or something to read to understand that better??
What does "face_attribute_fill" function exactly, is it important??

Some more question.
What is the difference with BMO_XXX and BM_XXX for eg BMO_ITER and BM_ITER.
When and why use one or another.




hard to figure out what to do here?


I've try to convert the code to dissolve edges but it delete to much edge and have problem with iter, maybe it kiil edges that is used in the loop.
Any tip to convert that.


Is it really important?
What does it exactly do?

This is work in progress, not really ready for review (patch contains quite a few questioins).

Ill reply to some but prefer patches be closer to completion before submission.

It may end up being easier for me just to write a bisect modifier from scratch then review the patch.


I wouldn't attempt to do use_beauty or use_dissolve here.


This should be submitted as a separate patch.


Its important, it fills in loop data from adjacent existing faces.

Campbell Barton (campbellbarton) requested changes to this revision.Jan 21 2014, 9:53 AM

Hi KGeoGeo,
Your modifier is really useful.
A bug : Having 2 planes in a group with opposed normals to get a kind of "sandwich cut" work well with 2 bisect modifiers but doesn't with a group containing the exact same planes.
Having the possibility to assign a material to the filled area would be nice too.
Merci beaucoup :)

Hello. I've been working a lot on modifiers lately, and particularly on non bmesh modifiers. kgeogeo, if you don't plan on finishing the bisect modifier in the short term, I could try to complete it, particularly in adapting to not using BMesh. Indeed, as I've measured with performance tests on the array modifier, BMesh modifiers are incredibly slow, and it's quite feasible to do the same work on derived mesh.

That would be really nice to have it work for 2.71. I don't know what happened to Kgeogeo. Last time he had health problems. I really hope he's now better, but even if it's the case, it may be better for him to concentrate on recovering. Campbell already suggested to do it and had no answer many weeks ago now. I can't imagine he would be sad to see you contribute and help him get his work done as he can't.

it is not health problem but it take a lot of time to solve.
Anyway thanks for the support.

So I don't see any objection to use or not what I've already done.
I feel there's a lot of people waiting for this modifier but I can't say when I will do an update and if I will do it acceptable to trunk.
So I would be really happy if you do that.
Good luck and I look behind your shoulder to see the great work you will do.


I worked on a non-bmesh version of the bisect modifier. At the moment, I have it working correctly in most cases, but have not coded the "fill" feature, that builds a face where the plane has cut the mesh.

Cutting the mesh, and the polys, is not so difficult in most cases. But it gets tricky when an ngon face crosses the bisect plane several times (which can happen if it is non convex), or when an ngon face in not in a plane.

And similarly, making up the fill face is easy in most cases, but tough when you cut a hollow object, for example cutting a taurus in half horizontally: it is easy to identify the outer and inner circles, but difficult to make the smaller circle cut out of the larger circle, and divide the region in between so as to have convex polygons... Any help on this would be welcome.

Then I came to realize that the bisect operation is very similar to an intersect boolean operation with the second object being a huge cube representing half the universe. And the new boolean modifier with carve works pretty well, and solves some of the difficult problems I have. Actually, making a bisect modifier that would call the same functions as the boolean modifier is maybe not a good idea: users can just chose the boolean modifier themselves... which would burry the whole idea of a bisect modifier.

@Patrice Bertrand (PatB) The reason why everybody wants a Bisect modifier is because boolean is pretty unpredictable and slow. Use a subdivided Susan with the Patch from KGeogeo and compare to the "infinite cube" solution with boolean. Best is if you animate your cube to cut the Susan, you will see all the glitches, flickering and bugs of the boolean (make Susan big enough to see the polygons)
WIth the patch from KGeogeo, I could cut a landscape with 3Dtown and trees at about 2M polys in realtime (moving the plane updated really fast) all that on a 150€ I5 3450 and without any bug in the resulting mesh.

Any news on this?
It would be really handy for some Mograph work....
The Boolean modifier is not so powerful as this modifier...
As bliblubli stated, the most cases the boolean modifer fails but the Bisect modifier not!

This revision now requires review to proceed.Jul 20 2020, 1:17 PM