I think that what is shown as “Intersect” isn’t exactly that. I don’t think that is recreatable with airtight meshes, but even it was, it feels more like join still. With intersect I excepted that in your video we would get the cylinder: that parts of the cube outside of the circle would disappear. That is what intersect is, and I would love it if that was possible, and behaved like that by default. Currect intersect can be recreated by join easily. But it would be impossible to detect when user wants to intersect probably, so it should be manually chosen I believe.
I would love the ability to limit cut to current island only. Sometimes islands are close to each other, and if I want to cut through one I have to be very careful with gizmo not to touch the other one. It would be nice if I could have freedom to drag however much and then in redo panel choose “Self Island Only”. But I don’t consider it pressing issue, can be something added in the future.
I like working with tool rather than shortcut, and tool has one gizmo, that is aligned to normals. But, when you press XYZ in modal you can cycle through Global orientation, Normal orientation, and Freeform (no orientation lock). I would love that if this was exposed in tool settings, just like it is for regular extrude tool, so I can choose which gizmo I want before modal, Normal or XYZ (bonus points if “Freeform” is added to that for both tools).
I found that it’s best to do entire extrusion in one go. For example if I want to cut through mesh to create a hole, if I select face and drag through its ok, but if I first drag to center, and then to other side, in center it leaves edge ring which I have to dissolve manually. Would it be possible to have “Dissolve Orthogonal Edges” option in redo panel like regular Extrude has?
As far as the bugs go, one I can consistently reproduce this one for those particular faces on Suzanne. But generally, when faces aren’t perfectly aligned it seems to get normals wrong quite often, resulting to things like that. Sometimes undo and redoing it fixes it (not in this case) which makes me think if the problem is in Float solver, and maybe exposing solver as tool property would make sense?
@ThinkingPolygons, @Wevon_AAS: The general rule is: coplanar faces are removed. So the behavior shown in the images is expected. I can add an option to not remove coplanar faces, but most of the time that is what is desired.
On the video: I still think that what is shown as “Intersect” is still “intersect” because the cylinder shown is not closed, so there is no “inside” or “outside” for the parts generated in the cube.
Certainly the cylinder outside the cube could be removed in that case, but it is good to remember that not all geometry is a manifold, so in many other cases there would also be no parts of the cylinder “outside” or “inside”.
If the cylinder were closed, the union would happen and the internal parts would be removed.
Note: there is also an operator called “Intersect(Boolean)” that does exactly what is shown in the video.
On Islands: It might be useful in some cases, but I also think it could limit cases where the user creates a separate geometry just to drill a hole in another island. And the user can simply hide the islands they don’t want to be affected. if that is most desirable, I can add an “Affect only islands with selected geometry” option to the Redo Panel.
Good point, I hadn’t noticed that since I hardly ever use the gizmos. Will be implementing.
I was able to replicate the problem described with Suzanne, I will investigate.
The issue doesn’t seem to be that the original coplanar faces are removed, but that their area is not included in the newly created face, leaving a blank space
That summarizes the expected result nicely. Removing the existing coplaner face (or, what will be) is fine, but the geometry being dragged over it should keep its own face.
I do understand the coding challenge of “but what about when…” , though.
I don’t think this will ever work. There needs to be some advanced heuristic that fuses this geometry to produce user-expected result. There can’t be some option user has to manually wrangle on/off based on different types of corner cases just to get expected result.
The case posted by @ThinkingPolygons produces clearly wrong result, but if there’s a manuall toggle to produce coplanar faces, then if the resulting mesh ends up with coplanar faces, it will be equally as wrong result.
The UI will get more complex, the UX will get worse, and in return, user will have a choice between wrong and wrong result. We already have one nonfunctional destructive boolean tool. Let’s not make another one.
Also, it should work like regular extrude tool. There needs to be consistency. It should not wait for click drag, at least not by default.
Are we going to give up on a tool because of a case that no machine can predict in 100% of cases?
The code could make the choice based on the normals of the two overlapping faces, but that would also not solve all the cases the user expects.
Removing or keeping coplanar faces can then be a user choice.
No, you would not add this to UI. I mean your gif pretty much shows exactly my point. In the case you showcased, the checkbox clearly toggles between right and wrong result. Not between two alternative results with viable use cases.
No machine can predict 100% of the cases, but at the same time, there are examples (which we can’t post here) of similar tool in other mainstream 3D packages that just work, without excuses.
In this case, whether to dissolve or not could be defined by whether the extrusion direction was along positive or negative normal vector. But that still won’t fix the problem that mesh with coplanar faces is invalid. It simply produces a buggy result, a buggy mesh, which user then has to manually fix, defeating the point of using this tool in the first place.
And as I said above, no one wants to keep checking some UI elements based on which situation they used the tool in just to get acceptable result.
Normally, one might lean towards that feeling. But in this situation, no. I believe most would agree that the current Extrude Manifold tool is so below expectations that - well, for myself - i simply never use it. It fails for me in the most common cases I’ve tried, where i was thinking “Really, it can’t even handle THIS?”
After 10 mins with Extrude Boolean - every random thing I was throwing at it (in the way i actually approach modeling), worked. I can easily think of edge cases that it might not - the example above with the 2 columns and coplaner illustrate it well enough. But, I can easily produce what I’d want in that example by bridging those 2 faces.
So this tool probably won’t solve every case, but it will certainly solve a ton of cases that right now are just a hassle. So TLDR: I’d prefer to have this new tool, than remain without it. And if it can improve at some future point to work out more paradoxes - great.
Whatever the option, no invalid meshes are generated. (It may still generate overlapping faces in the case of open mesh intersections, but this is another different situation, and the faces are not duplicates).
Direction is not always clear, for example when extruding a plane.
And comparing normals helps some cases but does not solve others.
Whatever other solutions exist, there are certainly problems somewhere else. A customizable option avoids this.
calm down mate. this tool is already very useful as it is right now
i own a very expensive 3d app that has a similar tool, and man the tool sucks. it breaks on most simple usecases. what we have here is far far superior. so yeah, let it come. nothing is perfect
Totally agree.
The tool solves 95% of the situations, and when it doesn’t, it can be easily adjusted manually.
It’s better to have an Extrude Boolean with some limitation than not having one at all, I just try to push it to the limit.
Thanks for the heads up.
I’ve kind of identified this before.
It’s something I still plan to resolve before submitting
(But even with that, I thought it was worth sending it for review).
This bit might be planned/WIP, or something - but just in case. I see in the F9 dialog there’s options for direction (local, normal, etc) - but, seems like only Normal works at the moment?
Attached is what the result was, and what I was hoping for. (I did a boolean extrude on the sloped inset face - it moved diagonally on the normal vector, instead of across the axis).
(Obviously which vector one wants is depending on the goal)
Would be nice also, if there was some hotkey-invoking i could do, like X , XX , etc to make the constraint direction happen like it does with the move tool.
On your own example when you disable remove overlapping faces, that’s invalid mesh. It may not be invalid in a Blender sense, but for any practical use case, such as in game engine or even for rendering, it’s invalid since it will cause Z fighting. It just shouldn’t produce coplanar faces.