For some reason I am having problems subtracting several shapes from another (See attached file).

My steps so far were: boolean / difference
picked center piece, confirm
select all the other shapes surrounding it
click done / right click

Nothing happens still all individual shapes. I even tried to subtract each piece individually, but it
makes no difference. I ran into the same problem before with a similar situation, it finally worked,
but unfortunately I can't remember the steps ... and actually it was the same initial problem. It
just worked all the sudden, don't know why.

Am I doing something wrong - or is it a bug?

Click Centre Part
Boolean (Dif)
Select the 6 pieces
Click done! ??????

Brian
(Follow the instructions as they appear in the very top Right Hand corner of the screen)

Hi Armin, there does seem to be some kind of boolean bug going on there.

One thing you can do when you see a boolean not turning out how you would expect is to select all the pieces involved and run the Construct > Curve > Isect command (note under Curve section and not Boolean) which will do an intersection calculation and create the intersection results as curves. If the generated curves of intersection look weird then that can help to show what is going wrong. In this case there seem to be some improper extra intersection curves being generated which are going to mess things up. (Brian - note that yes the object is cut but the result is not entirely correct, the remnants of the cutting pieces are not being left behind as they should be).

If you open your file in MoI v1, you will actually be able to do the boolean properly over there, so you can do that for the moment to finish the part and then paste it back into v2.

I'll investigate what is going on, to see if I can fix it up to work in v2 again.

I have narrowed it down somewhat already, it appears that this pair of surfaces (the inside plane from your cutting piece and the cylinder is from your main body part) are getting an intersection calculated for some reason on the extension of the plane, when it should not give any intersection there:



So that's a starting point for me to investigate.

- Michael

Hi Michael and Armin,

Scaling the whole thing 10 times seems to fix things.

What does the 'no units system' equate to, if I worked in mm I feel the scale of this object is way too small, but if it was in inches then I guess it would be ok.

Cheers

Hi Danny,

> Scaling the whole thing 10 times seems to fix things.

Hmmm, that is interesting as well. My current guess is that some of my messing with the analytic circle/line intersector in this recent release has hosed something up. I will backtrack and see about that and undo it if that was responsible, because I would expect for this to work, the scale of the object is not actually bad.


> What does the 'no units system' equate to, if I worked in
> mm I feel the scale of this object is way too small, but if it was
> in inches then I guess it would be ok.

The way things work in MoI (and most things), the current unit system does not actually have any effect on the numbers that are stored for x,y,z coordinates. The unit system is just a label that helps to give context to the coordinates, for communication to other people and also for conversion when combining files together.

But say you make a line starting at 0,0,0 and make it 1 unit long in the x axis direction.

The coordinates for that line will be stored as start = 0,0,0 end = 1,0,0 , no matter what unit system is used.

If you use miles, it will be stored as start = 0,0,0, end = 1,0,0

if you use millimeters, it will be stored as start = 0,0,0 end = 1,0,0

If you use "no unit system", it will be stored as start = 0,0,0 end = 1,0,0


The scale of the object being relatively large or small (as far as possibly running into fitting tolerance levels and stuff like that) would have more to do with having large or small numbers like 52512512.23 or 0.00000002412 and not really anything to do with what particular unit system is set.

The main tolerance goal is a distance of 0.001 , just as a direct number and not specifically in one particular unit system (actually I'm trying to shift more towards it being used as a fraction of the object's bounding box size rather than just a fixed distance)

This is kind of the easiest way to have things set up, because when you work with numbers you know that you are just directly dealing with the same numbers that are stored in the database (unless you have purposely asked for conversion of them by typing some different units label with the number for example).

I've seen some things set up where the database is fixed to one specific unit system. The problem with that is if you have your current units set to something else, then when you type in something x = 5,0,0 the number that actually goes into the database has to get scaled to the internal database unit system and the only time the numbers you enter go straight into the database is when you have the UI set to that same unit system...

- Michael

Hi Guys,

Thanks for all your input. I tried it in V1 and that actually worked. So I got a solution.
After I saw the results in V1, I was actually not quite pleased with the results, I mean
the looks. So I changed a few things, like decreasing the bottom radius on the cutting
tool and I also moved the cutting tools further out, for a less deep indentation.

Doing this, I thought I will try this again in V2. And ... I have two different versions.
One worked partially - looks a little bit like Brians version, some faces remained, some
didn't. The second try worked just fine.

Seems it depends on how close you get towards the center - see screenshot. I get the
impression if I get past the highlighted circle it doesn't work, if I stay outside it works?

And btw - Danny the dimensions are based on inches, but like Michael said, this shouldn't
affect the outcome. Maybe ... and I forgot about the restrictions on very small dimensions,
maybe my choice of dimensions caused the problem. If I remember right, I used a fillet
with 0.03125 (1/32) - do we still have the problem with too small dimensions?

Anyway, thanks again for your help ... and see attachments.

Hi armin, thanks for the additional examples.

So it turns out that the problem was not caused by any changes in the most recent v2 beta, the last several v2 betas have the same behavior as well.

I'm going to keep on searching back until I can find where it changed in behavior from v1.


> I used a fillet with 0.03125 (1/32) - do we still have the
> problem with too small dimensions?

I think that should be fine... But if you go much smaller than that you may want to think about having the object scaled up.

However, I have added quite a few things to v2 so that it handles smaller sized things better in many aspects though. Like with fillet for example if you ask for a small fillet radius, the tolerance used in creating the fillet surfaces will be ensured to be some fraction of that radius value so that it basically will adapt to it. But right now not every single function has been audited for that yet.

- Michael

Hi armin, I've been looking extensively into this boolean problem you reported here on this handle model.

I tracked it down to a change about a year ago in MoI v2 where when it loads a 3DM file, it detects whether surfaces in the model are pieces of an exact cylinder, cone, or sphere and if so it creates a special analytic surface class for that surface instead of having it as a regular generic NURBS surface.

The main difference with the analytic surfaces is that surface/surface intersection with them will do some special cases for them to get a more simple and precise intersection result. That's the idea anyway, but there are some bugs in some particular cases of the analytic surface intersections and that's what was causing this boolean failure.

For now I've disabled the analytic intersection for these problem cases so that it will use the general purpose intersector which then lets this boolean work fine.

I've reported these analytic intersection problems to the authors of the geometry library and I'll probably be able to re-enable them in v3 when they get fixed.

But anyway, your handle boolean will work in the next v2 beta, thanks for reporting the bug.

- Michael

Ah....having similar problems here with a boolean failing, but not sure if it's the same. I don't wanna steal your thread, thought it would be good to keep with the subject of boolean problems. I'm trying to cut the gear shape with the box, with no result.

After importing into v1 and trying it, all went well. I just had to then reimport into v2 beta to continue working with it (cause v2 is so saucey good).

Just hope this will be resolved b4 the final V2 is released.

@ Tree
Maybe you must post the 3dm file (zipped)

Hi Tree, could you please post (or mail to me at moi@moi3d.com) the 3DM file with your gear and box in them so I can test it over here?

It sounds like it could be the same problem but I can't be sure without testing it.


If it is a different issue, it would be very helpful to have the model so I could work on fixing it up in v2.

- Michael

Hi Michael,

I mailed you the file. Hope it helps.

Thanks Tree - some initial tests seem to indicate that it is actually a different problem than the one mentioned here, so I'm glad you sent it to me.

I will be digging into it to try and figure out what change in v2 broke this case.

- Michael

Hi Tree, I was able to track down this boolean problem with the gear and the box that you posted previously here.

It behaved differently in v2 versus v1 due to a small change in the surface/surface intersection tolerance. I've got it tuned up for the next v2 release.

Thanks for reporting the problem.

- Michael

Great! Is the surface/surface intersection tolerance something that can be or will be able to be controlled by the user? In the cases where booleans do fail and no result is given or pieces just vanish, would it make sense to give the user control somehow to adjust how it performs the boolean? Sometimes any result would be better than none. Although the opposite can also be said to be true.

Hi Tree,

> Is the surface/surface intersection tolerance something that
> can be or will be able to be controlled by the user?

That's theoretically possible, but it's a rather arcane esoteric value for people to adjust, and it is easy to adjust it improperly if you do not fully understand what it is controlling.

Things tend to behave really strangely if it is too loose, you end up with kind of saggy intersections.


> In the cases where booleans do fail and no result is given or pieces
> just vanish, would it make sense to give the user control somehow
> to adjust how it performs the boolean?

Well, part of the update is that if it failed or if there are naked edges in the result when there were none in the inputs, it will repeat the boolean again with an automatically tightened tolerance. It will go through that cycle a few times.

- Michael

Almost looks like a PBW (Earthsiege / Starsiege) :)

http://www.angelfire.com/sd2/nightcabbage/Stuff/3dsmax/pbw2.jpg