Hi,
I think there is a problem with the boolean command.
I don’t need a copy of the original subtracted copy.
In fact, after the boolean command, I have to delete the copied object.
I can’t find an option to avoid this issue.
Rhino 7 didn’t create a copy of the subtracted object with its original state.
1 Like
Did you check the command line option to delete input or not?
2 Likes
Hi,
I don’t want to delete the input (the subtractor). I want both after the boolean command.
I don’t want a copy of the original subtracted object.
In Rhinoceros 7 I get only the subtracted and the subtractor, two objects, not three.
Ok now I see the mean of “delete input”
I thought the input was the “subtractor”
This has changed from V7. In V7 and earlier, there was just DeleteInput=Yes or No. In V8, when you set DeleteInput=Yes, you will see an additional command line option KeepCutters=Yes or No.
-
If you choose DeleteInput=Yes KeepCutters=No, the command behaves like V7 DeleteInput=Yes - only the result of the subtraction remains.
-
If you choose DeleteInput=Yes and KeepCutters=Yes, it behaves like V7 DeleteInput=Yes, the result of the subtraction remains plus the subtractor(s) is/are kept.
The difference is that in V8 if you choose DeleteInput=No, nothing is deleted - you keep both the original base surface(s) and the subtractor(s) - plus you have the results. It’s somewhat confusing now, as all the objects are concurrent and it’s difficult to see if anything was actually done. I suspect this is going to lead to a lot of questioning posts like yours here…
While I do understand the occasional need some people have expressed for this option, I think the lack of clarity that it adds is unfortunate.
hi @gabrielefx , I see what you mean. You can either delete all, or nothing, not the V7 behavior. I’m not sure where this change comes from. I think it makes more sense to have separated delete options for A and B inputs.
It came from one or two user requests in the past… It may also have to do with trying to support History.
https://mcneel.myjetbrains.com/youtrack/issue/RH-70902/BooleanDifference-Added-KeepCuttersYes-No-when-DeleteInputYes
https://mcneel.myjetbrains.com/youtrack/issue/RH-67393/BooleanDifference-Added-History-support-when-DeleteInputNo
thanks Mitch, I can see that this allows history related booleans. I was wrong that the V7 behavior was lost, it’s indeed :
That was exactly what I was thinking, when I first saw it… and was sorely disappointed 
I think the current wording is very confusing for most users, as it uses different nomenclature for the input and the “cutters” (delete vs keep). It’s actually asking the same question but with the sign reversed - should be the same, I think. Maybe DeleteOriginal and DeleteCutter?
-Jakob
here that works, but you will have to keep you input on a separate layer to make it usable I’d say.
While I agree, it’s also a bit difficult to change the wording. If DeleteInput = No, Input means both the base objects and the cutters. Would DeleteInput / DeleteCutters work for you?
Works for me - I think it’s more logical that the command asks to delete on both, rather than delete on on and keep on the other 
-Jakob
RH-74895 BooleanDifference: confusing wording
Ah! I thought I could get history t work with DeleteInput and KeepCutters, so that could have just the resulting geo and the cutter, but now I see that I have to keep all.
It would be neat if it was possible to automatically send the cutters to a designated layer (with all geometry shown as ghosted) and just keep the result and the cutter; not the original. If I need the original, I would just need to move the cutter out of the way (or delete it). Actually moving the cutter out of the way already works and gets you your original object back. Deleting it will leave the last result intact (So if you move the cutter out of the way - to get the original - and then delete if, you are left with original geometry). So basically it’s almost all there - the MO just needs to be fine tuned, I think 
Just my 2 cents
-Jakob
Well, to be honest, the original V7 and earlier wording is confusing - DeleteInput isn’t really what it does, DeleteCutters is actually what it does. So yes, perhaps it does need to be changed, and the “Keep…” prompt is consistent with some other Rhino commands.
So it could be simplified as: KeepBaseObjects=Yes/No and KeepCutters=Yes/No
-
KeepBaseObjects=No KeepCutters=Nowould result in the same asDeleteInput=Yesdoes now in V7 - only the results remain -
KeepBaseObjects=No KeepCutters=Yeswould result in the same asDeleteInput=Nodoes now in V7 - the results remain plus the cutter(s) are kept -
KeepBaseObjects=Yes KeepCutters=Yeswould result in the same asDeleteInput=Nodoes now in V8 - the results remain plus the base object(s) and the cutter(s) are kept
I like that a lot!
And this is the kind of work-flow (overly simplified, but in principle) I would love to see streamlined: Combining gumball, push-pull and subobject selection.
-Jakob
2 Likes
There would still be a fourth permutation of the Yes/No combination. In you’re setup, the fourth one would be:
KeepBaseObjects=Yes KeepCutters=No- The results remain and only the base geometry are kept.
Hi all,
If I understood Thai thread correctly we need to keep both base objects and cutters for Boolean history to work?
If that’s the case, and if history is turned on, I hope the default for both is set to Yes (keep).
Thx,
G
Yes, that’s generally the case with Rhino’s discrete history, the relations are based on the original object id’s and if they are deleted the history is lost. This is already the case for example you chain several transformation operations like Flow, FlowAlongSrf, etc - if you don’t keep all the originals and intermediate results the history is gone. This means that the originals need to hidden or be kept on some off layer if you don’t want to see them all the time.
Hi Mitch, I get that arcane logic and it makes sense, I guess. I always manually keep all my objects pre-Boolean so I can do them again later after a change. This Boolean history does not eliminate that manual management need, it just makes it more complicated, and prone to error.
Yet, I really don’t understand the logic of some of the limitations of Boolean history:
- I can move the cutter and the Boolean updates, good.
- I cannot move the base object, because the Boolean history breaks. Not good
- I cannot change/replace/add more/other cutters. Not good. This is the MOST needed reason to have Boolean history IMO, and it cannot do that.
Edit: my mistake, I can move/edit the base object. I was testing moving the resulting Boolean object.
Still I think Boolean History needs to have the following features to be useful:
- resulting Boolean intersections can be edited with fillet edge and blend edge without breaking history.
- replacing a cutter from current cutter A by a different cutter B. Or by A+B, or any new cutter.
G