In today’s developer meeting, Kyle mentioned that it would be great for the Boolean commands in Rhino to provide graphical feedback about why the operation failed.
One idea is to run the intersect command, see if the result is open, and show the user where to look to close up the input geometry.
@theoutside, @BrianJ, @chuck, @GregArden and others were interested in this conversation.
Greg suggested that we also need some example models that fail in these ways so that we can test the code.
I just shared a Google doc with all of you. Kyle and I will be making support cases for this. After we are done it might be good to think about adding a link in the command line when a Boolean fails.
I have several open YT items regarding Booleans (#BrianJames #BooleanUnion #BooleanDifference #Open #Submitted) but will add more during the making of this doc. If we make certain cases obsolete through a fix we can remove the tips from the doc.
Can you please post the link to the GoogleDoc in this thread? Thanks.
What is the difference between:
A) Failure due to incomplete intersection
B) Failure due to open objects
Is (A) a computational failure while (B) is a problem with the way the model was created?
B) If one object is open but the other is closed you can create a srf where you don’t want… so something happens but it really isn’t expected so I call it a failure. I’ll add an example tomorrow and make sure it’s filed.
Yeah, this has been a difficult-to-teach part of Boolean operations forever. It was one of the first things I tried to write up when I started working here 19 years ago.
As I’m sure you are aware, Boolean operations with open surfaces are perfectly valid. The rules are the same as for closed objects, but require you to understand which direction is “out” for the surfaces involved.
When only two objects are involved, we could let the user cycle through all four options to see which one they wanted to get. The possible permutations are:
A intersect B
-A intersect B
A intersect -B
-A intersect -B
where -A is A with it’s normals flipped.
Here’s an animated GIF that says it more clearly:
But once there are multiple open objects involved, the permutations for helping the user can quickly get out of hand… maybe that’s not a problem though, since cycling through the options may be faster for the user than finding and fixing the problem to get what they want.
Yes… that’s it and good idea about cycling through the possible results. My thought in listing it was just to have a help blurb on the page explaining normals as pertaining to Booleans with open objects.
Yeah, I appreciate the desire to document it. I hope you’ll do a better job writing it in a way that is succinct enough yet understandable. I found that the blurb I wrote was pretty lengthy.
I’ve just committed code to v6 that keeps track of two sets of points found during a failed boolean operation. The first, NakedEdgePoints, is the set of points where an intersection curve ended at a naked edge. These points show where a model needs to be closed off in order for the boolean to succeed. The second, BadIntersectionPoints. is the set of points at ends of intersection curves that don’t connect to anything at all. These are usually due to a failure of the intersection code.
BooleanUnion now puts dots with “N” at the locations from the first set, and “I” from the second. I did not do anything with BooleanIntersection or BooleanDifference since I know this implementation will not last long. My hope is that @mikko will take a look and polish up the interfaces. http://mcneel.myjetbrains.com/youtrack/issue/RH-27520
I guess one UI possibility would be a ShowEdges style modeless dialog that would highlight the problem areas without adding objects to the doc. I think it might be good to also highlight the problem edges if the boolean code knows which ones are causing trouble.
I made a new McNeelPrivate topic to continue this discussion of the implementation of my new code.
If you want a conversation to be private, you can also change the category at any time - this will move it to the more private area. Also, I don’t think discussing implementation in public is inherently bad.
No, it’s not inherently bad, but I don’t think it is useful in any way. I don’t want to change the entire topic to McNeel Private, just this part.
Concerning http://mcneel.myjetbrains.com/youtrack/issue/RH-25372, where the customer calls a boolean on open objects and does not understand that normal directions are important, I don’t think it makes sense to provide a preview except in the case of 2 objects, but then Boolean2Objects already does that. If two objects were chosen and one is open, maybe we should go into that command automatically. With more than 2, maybe we could just pop up a message saying something like, "Some inputs are not closed. If the result is not what you expected, see (link to help, explaining normal directions and booleans).
I think calling Boolean2Objects automatically is a good idea, although it may interfere with scripts users may be using that rely on commands ending reliably the same way. At least we could make the verbal feedback in boolean commands suggest using Boolean2Objects if the results don’t look expected and there are 2 inputs and at least one of them is open.
I’d like to hear feedback on the naked and bad intersection indicators. Do they help, and do they work as expected, or does the feedback system need to be different somehow? I’ve been thinking about making it an analysis mode a la ShowEdges, but the more I think about it the less suitable it feels.
So far, I’ve noticed that the reports of naked edges are not always at naked edges. I’ll have to dig deeper to figure out a better way to classify the errors in these cases.
Yeah, I saw that too, although the model was so bad I wasn’t sure what to expect. I tried to get the “bad” label to show, and deliberately made a partially inside out object by revolving a figure eight. Attached is a reconstruction of the model. You get naked labels is 2 different places depending on where you pick:bu_nakeds.3dm (30.1 KB)
Now you should only get “Naked” on naked edges. Also, recently I started tossing out intersection curves that ended in the middle of both surfaces since they could not possibly lead to a successful boolean. The ends of these were not showing up ion the feedback. Now I keep track of the ends and the do show up. Also, those curves show up again with the intersection command. Keep in mind, the feedback is only hooked up for BooleanUnion at this point. Once it is determined to be worthwhile, it will be added to the other boolean commands.