Page 2 of 2

Posted: Fri Sep 10, 2004 3:08 pm
by pildanovak
i've done a simple test, please look at the file and try to do booleans with the two objects. maybe the bools should handle the type of exceptions?

Posted: Sat Sep 11, 2004 7:12 pm
by LozarB
pildanovak wrote:i've done a simple test, please look at the file and try to do booleans with the two objects. maybe the bools should handle the type of exceptions?
Hi, thanks for taking the time to test it! I looked at the blend, object 1 contains polygons that overlap, that means it's very hard for the boolean op to work out what's inside and what's outside the object, this knowledge is the basis of all boolean operations. For better results you might consider taking the union of the 2 overlapping objects in the first blender object and then performing the op with the 2nd object on the result. However, my excuse is a bit mathematical but thats a limitation of "orientable, closed, non-intersecting, manifold surfaces" that are required by this implementation. Blender allows you far more flexibility with objects than those that give decent results from this method.


Posted: Sat Sep 18, 2004 11:38 am
by SpookyElectric
Yeah, in that case, you'd have to separate the meshes and do a union first. Though it's not a case I'd imagine would be encountered much, and so I don't think it makes sense to have special handing for it. For my boolean operation, there are similar requirements of the shapes involved to produce good results. It will only work right when the intersection between the two objects can be defined as a set of closed, non-intersecting loops. Which is guaranteed when your meshes are closed, non-intersecting, etc. Basically any object whose mesh could exist in reality as a solid object with volume. In that example, the intersection is two intersecting circles, and thus will not work right.

For anyone interested in testing my booleans, my python script now (as of today) nolonger needs a specially modified version of blender. The produce a minimal number of edges in the resulting mesh, taking advantage of using quads for filling. Check out the elysiun thread for details.

Posted: Tue Sep 21, 2004 11:50 am
by jm
hey man
this is much more better then old booleans.
I tryied a few meshes and it works for me as I want. :D
without blind-absurd vertex on schape.


Posted: Wed Dec 08, 2004 5:19 pm
by levon
any news on these better booleans? it would be a great thing for these to be in 2.37, if i see electric on irc ill ask him how hes going, and if he is still working on it. great work so far though.

Posted: Thu Dec 16, 2004 7:35 am
by SpookyElectric
They're still work in progress. There were some special cases that caused problems with my first approach. So my python script has been completely rewritten. Latest versions are updated on my thread on Elysiun. Once that's stablized its time to move to the C version. Hopefully that'll be soon. But I thought that in September. Assuming ~2 months till 2.37 I suppose its possible, but I dunno.

Posted: Thu Dec 30, 2004 4:50 pm
by winfried
I tried the debug windows version with the .blend file that I submitted with bug report 1860 (boolean tool crashes blender). If use the unmodified mesh as indicated in the bug report, blender still crashes. If I remove the doubles and subdive the top face of the beveled cube a bit as Ton suggested, blender doesn't crash, but the result is wrong.

ps: The python script of SpookyElectric also can't do the job, but I'll post that on his thread at Elysiun.

Posted: Thu Dec 30, 2004 6:22 pm
by winfried
Update on the previous post: if I recalculate normals outside, remove doubles and subdivide all sides of the beveled cube twice, then union and intersection work ok, but difference still gives a wrong result in my opinion.

Moreover: if the objects do not meet the requirements for the boolean operation, please show an error message instead of crash.

For the rest: very good initiative, I'm looking forward to the final result