Manifold Extrude not working as expected... maybe

Hi @mano-wii!

I’ve been testing a bit the new manifold extrude and I cant get it to work correctly.

The old patch (the one from a different author, not the addon) was working in many situations where the new manifold extrue is failing, I would like to know if it’s because I’m doing something wrong, or if it’s a bug, but in it’s current state it’s not working as expected I’m afraif.

Check this example, the user would expect the result you see in the right model, but it gets like a normal extrude with the normal inner extrusion problems, is there something that needs to be configured?:

To be honest it should work like in this following video, otherwise it should be considered as not working I’m afraid:


Really need this

“Destroy End”- determines whether to delete open faces after the extrusion, simulating a boolean hole.

1 Like

I wonder if it wouldn’t be clever to just change the whole implementation to use the new exact booleans…

Basically make union on the outside with the extruded part, and subtract on the inside…

Just a random idea :smiley:

That does not work in every case, you also need to generate intermediate geometry and loops, I’m not sure about the problems of the original patch and why it was re-developed, but in any case, the tool as it is right now is not useful, being unable to do just the example I showed in the video make it useless I’m afraid, it I’m not sure if that’s a bug or as designed.

Maybe is not @mano-wii the person to pong about this, @dfelinto could know better :slight_smile:

1 Like

I’ve spoken with @mano-wii, it seems the current limitations are known and they will be solved, also another tool is under development that will allow for full tunnelling it seems, and it may fully replace the current manifold extrude tool:

⚓ T75913 New tool to add and subtract prismatic volumes

I hope the limitations of the current manifold extrude tool are solved rather sooner than later because IMHO as it is right now it’s usefulness is pretty low I’m afraid, it’s basically like detaching the faces and moving them, but you cannot past the first edge, it won’t be destroyed :stuck_out_tongue:


I absolutely don’t understand it. If there was already functional patch author has spent a long time to get working well, why was what we have currently in master chosen instead? I struggle to understand who could possibly make such a bad decision, and on top of that, how could the tool in this state make it to final Blender version, if it fails such a simple use case as extruding a corner face of subdivided cube?

I really can’t understand it, because the only way this could have possibly happen is if:
A: Absolutely no QA testing was performed before the feature was accepted.
B: Inferior implementation was chosen on purpose, since core developers are clearly aware of

Can someone explain this to me? I though the megagrant was supposed to be used to “improve software quality”.

Very well working patches such as @kio 's select through are rejected because they are considered to have possible issues, yet at the same time, tools in this state make it to final Blender version. I don’t get it.


I agree with the fact that this tool should have not been committed to release as it is.

AFAIK the original patch had several issues with a bit more complex meshes, so it had to be re-done, but I can’t consider this a full re-done or a complete tool.

It´s functionality is not as expected by the user, if more time is needed, so be it, if the Boolean tool is needed, ok, but the current tool is not in a good state, in fact it’s being taken as a joke by many artists, because it´s not useful Im afraid, in the demo it never go pass the first edge loop.

Also after analyzing the tool and other alternatives out there, Ím not sure that the Boolean path is the best one, the tool will require full loop reconstruction, to be quad poly aware and to deliver a clean vertex result, not sure if what is planned can deliver such result, also it needs to have a real-time feedback when you move the shape, and based on the preview of the bool based tool Ím not sure if it will deliver that real time feedback.

Lots of questions here, and I agree that some more clarification here could be welcome.

Maybe the current tool can be fixed and reach a state that it works as expected, and that’s why it was committed, because it will be fixed in a point fix release.

The current extrude manifold isn’t really good I dont understand why they didn’t keep destroy end optional, it doesn’t make sense

If the original patch had performance issues I’d take that as an explanation, but that would still not solve my other question, how come a tool in such a state has made it to official release when even the most trivial testing scenario fails. There have been many other patches which have been rejected for much, much less severe failures.

Furthermore, reading the comments under the original patch, I can’t see any indication from any of the core developers that the issue with the patch is the performance.


So even the most painfully obvious Extrude Manifold bugs are now considered a feature requests instead:

I don’t even know what to say anymore. I just don’t understand what would be the point of reporting any bugs on the bug tracker when the definition of what is a bug vs what is a feature request tends to sway wildly depending on a particular mood of a random developer stumbling across the task, often even conflicting with triaging staff.

If even people who are paid/designated to triage those bugs can’t tell the difference, how can the average user?


I added a comment to that task, and I will paste it here too:

@Campbell Barton (campbellbarton) @Germano (Germano) what we are seeing here is that users expect this tool to work in a way that is as it should work, and it’s not working as expected, so while you may consider there is no bug in the code per-se, this should be considered a bug, it may be a design flaw on the tool or the code, but the tool is not working as expected, so probably the whole tool should be considered in a buggy state, and maybe even remove or relocate it under the experimental options in the next point update of 2.90.x because it’s not working as expected at all.

Keep in mind that no matter if the code works as expected, that does not make the tool to work as expected I’m afraid :S

I think removing this tool in the next point release, or hiding it under experimental could be a good idea, because it’s in a fully non-working state, even if what the developer expects it to do is working, what the user expects it’s not working, and the expectations are not met at all.

And BTW let me stress that the proposed solution boolean based that cannot work in real time is not a good solution either and will end up in a similar situation for the users, because “previewing” a boolean volume it’s not the expected behaviour.

Technically the tool works, but it doesn’t have the code needed to automatically cut and merge any edges the vertices cross (though you can make it cross by turning on the auto-merge and using the tool twice). The problem here is that users will naturally report bugs if the tool doesn’t work in the way they expect them to work, if the devs. disagree with it based on some cryptic definition regarding design then there will naturally be some pushback. Even more so, the marketing being done by the BF clearly indicates that they want Blender to be seen as a serious alternative to the commercial solutions, and to do that requires a greater emphasis on things like performance and polish, which means these things must be treated under the assumption that they are bugs.

1 Like

A general comment, not necessarily about this particular tool, but I do think it applies.

Sometimes it is quite a lot more difficult than one might imagine to make a tool work in every case. 3d programming is filled with exceptional cases. Sometimes the programmer is perfectly aware that it won’t work in those cases, but making it work is extraordinarily hard, so they defer (maybe forever) making it work in those cases. Sometimes the programmer is surprised when someone finds an exceptional case they didn’t think of. In such cases, sometimes it is not too hard to fix, while in other cases it is more like the extraordinarily-hard-to-fix category.

It is fair for a user to say: “most people would expect the tool to act such-and-such way in this circumstance; the fact that it doesn’t is therefore a bug”. If this is an extraordinarily-hard-to-fix bug then there are three choices: (1) start working on fixing the bug immediately; (2) put it on a list of “we know this is a problem (or limitation)” and “maybe we can find time to work on this in the future”; or (3) remove the whole feature as useless or too untrustworthy to include.

Of course users all want answer (1). If there were infinite programmers, that’s what we’d do. But programmers are a limited resource and need to be used in the way that gives the most added value to the most users. Which is probably some other critical project that the programmer is currently working on. So (1) is often not the chosen answer.

Answer (3) is possible, but how often is a feature so useless/unreliable that people would rather not have it at all? Some in this thread feel that the current Manifold Extrude is in that category, but is that really true? Does it not provide a useful function that Blender didn’t have before in at least some cases?

A lot of angst goes into the terminology used around choice (2). Some of you feel that if a developer calls it a “known limitation” or “feature request”, that is dishonest, because in your view it is a bug. I frankly don’t care because the resulting action is exactly the same whether we call it a bug or a known limitation: the action is: nothing will happen in the near term to fix this problem, because of lack of programmer resources. So I don’t really care whether they are called bugs or feature requests. The current Blender developers have decided to call them feature requests mainly so that there is a clear separation between “things we have to work on ASAP” vs the rest. There would be other ways to do this that still call the feature requests “bugs” but they have chosen not to do those. As I just argued, why does it really matter if the effect on development is the same?

As a very concrete example to think about: until recently, there were a lot of “bugs” (from the user point of view) in Boolean. They were all in the extraordinarily-hard-to-fix category. I know because I just spent more than a year fixing them. (And, I might add, there are still behaviors in the new Boolean that I am sure some users call bugs.). Would you all prefer that there be no Boolean function at all in Blender until they were all fixed? Or would you prefer that every single developer work as hard as possible on fixing them all (which practically, isn’t possible), while every other bug in blender lay unattended and unfixed?


While in general I totally agree with your comment, in this case the situation is quite a bit different.

The tool was reprogrammed with the original patch as a reference, the original patch was solving the users requirements pretty well, and was fullfilling the tools description.
With that said it’s pretty clear that a rewrite of the tool was needed since some problems were found when that tool was used with complex meshes it seems, hence we have the rewritten tool.
There was also an addon that was doing a similar job, and also the experience of many users with other package that was the first one, up to my knowledge, to show this kind of functionality.

So in this case the tool expectations were pretty clear even before the rewrite work of the current tool was started.

It’s not a problem that a tool has some limitations, the problem comes when the limitations make the tool nearly useless, like a small toy besides what it was supposed to be, now the users come and try to use the tool, that BTW is being implemented in other packages too, with pretty clear examples of what the tool should be able to do, and then they found that it’s not only that it does not do what they expect, it’s that it generates weird geometry and situations that the would not expect at all.

IMH this tool, in it’s current status, should have never been deployed to any release, at least as a “release version”, maybe as an experimental version that required some work to eliminate those known limitations, that on the other side, were not clearly explained nor documented, up to my knowledge to, I may be wrong here.

So, if the tool does not even accomplish what its description says it should do, what you will get is a lot of users reporting bugs that in reality they may be limitations, but in practicality they are bugs, because the tool does not do what it’s expected to do.

Also the additional point to all this is that the solution planned seems to be a boolean based tool, which may be perfectly fine, as long as it happens in real time, as the users expect it to be, it’s not something impossible, it’s something already done, but I doubt it’s the best solution.

So if users don’t get what they expect to get, and there is no clear description of the limitations, and the tool is so much limited that it cannot even fullfill the most basic operations it’s expected to do, like the face inwards extrude, then the tools should not be in release.

Of course it’s my opinion, but there is a reason why it took you so long to commit the new boolean system, and I think it’s the very same reason why this tool should have never been released.

Finally it seems there has not been user feedback during the development process, or at least it was biased by the old patch or it was so small that no feedback was done.

User feedback is one of the most important things to release a tool, the developer is not doing the tool just for the shake of writing some cool code (and I know that’s not what is in the developer’s mind), the developer is programming a tool to make it useful for users, if no user is properly testing it and giving feedback, then the tool will be full of flaws and limitation, and the developer will be unable to see the problematic up until the tool is released, for that feedback to come a call is needed, and the experimental tools section in preferences is ideal for this situation I think.

To finish already, the " “known limitation” or “feature request”" dishonest feeling comes from lack of documentation, if the real functionality is properly documented, and the real limitations of the tool are properly documented, then expectations are under control and no “dishonest” feelings will be present, but the tool was presented as a very useful tool that was capable of what a general user would expect of such tool, and the limitations were not clearly exposed, then the user start reporting bugs, that are not bugs, are limitations, but then the bugs are defined as limitations, but the user sees them as bugs because no one told the user about such limitation and the description of the tool was completely different to what the user is experiencing.

I don’t know if I’m explaining myself right, the thing is that it’s not a matter of a good or a bad work by the developer, I think @mano-wii is doing a pretty good job, the problem is a communication problem with the user, and a testing/feedback problem with the feature.

You got tons of feedback of the booleans, there was kind of a “call” to test it, after the first patch by another developer, of this tool, I think there has not been any call to test and give feedback on this tool, so the user expect it to do at the very least, the same as the original tool from the original patch.

Ok, that’s it, too much text, may be someone better in condensing it, I’m not :slight_smile:


BTW when we talk about bugs, the bug is not always a “code” bug, it can be a UI “bug” or a UX “bug”, and it should be considered as a bug IMHO, maybe a different kind of bug, but a bug in the end :slight_smile:

You make a number of fair points about the Manifold Extrude case. I am not familiar with what was wrong with the original patch, so I’m not going to opine one way or the other on whether it would have been just as bad to release that (it seems that it also had “bugs”).

Your points about having users give feedback and documenting known limitations are perfectly fair, and I agree with those.


I want to make one thing clear.

I understand, and I know for a fact that the flaws of the original patch were there, that’s clear, and I don’t intend to question the reasons why it was rewritten, if it was needed, it was needed :slight_smile:

That’s it.

In addition, much of the time, a report that is closed as a ‘known issue’ or ‘limitation’, there is no message saying it was closed because the fix requires deep and highly involved changes that will take weeks or even months. There should be a new tag that indicates when the fix itself is a major project. I am already aware that some fixes are anything but trivial to solve, but the manifold extrude issue is pretty deceiving in that it doesn’t seem that difficult to allow a tool that already cuts, merges, and deletes geometry to cross an edge (especially with Germano’s previous work in auto-merge).

I would think that extrude manifold should have what it needs to be improved thanks to your new boolean code, is that not the case?

1 Like

Such a tag could be minorly useful, but I would bet your ‘major project’ tag would end up being added to most of the reports that are closed as known issue or limitation. An exception might be something that would take a couple of days to fix but whose impact seems really minor (a really rare case) and/or where the developer that could fix it is overloaded with much more important things to do for the foreseeable future. If a bug is easy to fix, and we are not urgently needed elsewhere, we fix it instead of closing it with ‘known issue’.

Not knowing anything about how manifold extrude is currently programmed, it does not seem a minor thing to fix. Maybe the whole thing can be done with boolean. But if that is true, it is likely to mean an almost complete rewrite of the current logic. This feels like something that might take weeks to do.


Check latest build “destructive extrude” build by Darcvizer, it works most the time :innocent:

1 Like