So it’s true. Bmesh can do this after some work… Probably hard, but at least no one has to rewrite the mesh system again…
Since this kind of thing requires fixing modifiers and tools, it’s best if this was worked on sooner than later.
The more modifiers and tools blender gets, the harder this will be to achieve in the future.
Hope a programmer gets interested in this sometime soon 
Drat! Close, but no cigar huh?
each face had, a data structure which can store any number of loops per face.
Hmmm, I wonder where I got that from. Possibly a completely different bit of software.
This can be enabled again with a compile flag, just search for USE_BMESH_HOLES, ifdef’d this out to save 28 bytes per face.
But don’t be fooled, having the data structure there is like 10min of work, so really its not giving us a head-start to have this.
Well, sure. It wasn’t a criticism. Just relaying what I remembered about the hole situation.
41 matches for USE_BMESH_HOLES in code, interesting. So the data structures are prepared, but not the rest?
@CoDEmanX, right - but as I said before this is only a tiny part of the work.
I think its worth considering that this makes work more complex for tool writers. If BMesh supports advanced features but its very hard to write tools to support it, then its not necessarily an advantage to support.
Alternatives…
- Support edges being used in a face more then once (but not holes)
- Fake hole support (like FGons pre-bmesh …) Rather not. just to say its an option.
- Support this but only in low level API’s and somehow write in such a way tool writers can mostly ignore… this is tough and not sure its really possible to do well.
I think many here would choose having a much larger and more powerful toolbox over being able to make holes in faces. The tools would then make tasks like architectural modeling easy enough that it wouldn’t be sorely needed or missed (and even now, doing those things is much easier and faster than with the old editmesh structure).
I also would argue against bringing back FGons, as they wouldn’t have any actual benefit for actual modeling work other than to make models look pretty.
The ability to handle holes in faces is a prerequisite for better tools. For example, CSG in Blender is significantly impaired by the fact that each subsequent boolean modifier in a chain has to deal with split ngons left behind by its predecessors. Planar decimation at the end is not sufficient to clean up the mess.
Isn’t CSG a solid modeling technique? I know that boolean operations are vital in autocad and other solid modelers, but polygon modeling is a bit different. If you’re trying to use solid modeling techniques on polygon models, you’re going to run into some issues.
Such as? …
But if the tools are much harder to write as suggested and has bugs that are much harder to fix, then it may not matter as the weaker tools might bring about a modeling speed penalty that ultimately makes the modeling process slower. You might be able to port the existing tools over in a fully functioning manner eventually, but that might take another six or so releases much like we’ve seen from getting a good toolset available for use with Bmesh.
Also, I don’t really know of any big budget app. where a large number of users use CSG modeling as a primary tool, usually you find this in apps. like Vue that would otherwise not have a lot of other modeling tools available to the user (as they are specialized for one or more areas).
Bad tesselation, unnecessary geometry, interior faces… the list can get quite extensive depending on what kind of boolean algorithms you’re using. Solid modeling and polygon modeling have some very core, fundamental differences that are pretty difficult to get around.
Blender is not built for solid modeling. It’s a mistake to try to use it that way unless you want to add a new parametric primitive type.
Blender uses the Carve library, and Carve is perfectly capable of producing optimal results. However, Blender is unable to carry these results from one modifier to the next.
If you have three objects A, B and C, then A.difference(B).difference(C) should equal A.difference(B.union(C)). The reason why this doesn’t work reliably in Blender is because any ngon with a hole needs to be split by adding two “helper edges” that the next modifier cannot simply ignore.
Here’s a very basic example: A is a plane, B and C are cubes.
A.difference(B.union(C)) gives the optimal result:
A.difference(B).difference(C) produces this instead:
The bevel modifier has its own problems with helper edges:
Again, CSG modeling is not at all an optimal workflow. You will run into problems unless blender switches over to solid modeling instead of poly modeling. (do not hold your breath)
I agree that the bevel code could use some polish in that respect, but there are better workflows to get the result you want every time than using a stack of boolean modifiers.
For architecture I doubt that there is a better workflow than CSG. When I do raw buildings, I often just draw a floor plan with multiple sets of n-gons (e.g. exterior, rooms, doorways, windows), then combine them like this:
Exterior.solidify().difference( Rooms.solidify().union( Doorways.solidify() ).union( Windows.solidify() ))
The whole point of n-gons is to handle any planar surface as a single logical unit, regardless of shape, and to defer triangulation to the very end of the workflow. Splitting n-gons ahead of time is a violation of that concept and is the sole cause of all the issues I described earlier. Without the disruption caused by “helper edges”, bevel and booleans would work just fine in all those situations, and manual cleanup wouldn’t be necessary.
I’m just trying to tell you that with the state of bmesh right now, that workflow isn’t going to work. I totally understand that Boolean modeling is super fast and easy, I use autocad when I’m not using blender. Right now, the best solution would be to manually manage your topology to avoid such glitches. The implementation of n-gons is somewhat limited, but, as was pointed out a number of times, adding in support for that feature would be very difficult. I can absolutely see the benefits, but I can also understand the limitations and why they exist.
What I’m trying to say is that the boolean and bevel issues are related, and while the boolean issues can be avoided by merging geometry in the way described above, there is no way to avoid the bevel issues. I don’t see the point of making those tools work better with a limited implementation of n-gons when a full implementation is already available and waiting to be unlocked. It’s like treating the symptoms instead of curing the disease.
I think the fact that inset works much better than bevel in cases like that means that it would be possible to make bevel work better.
It sounds to me like it would be non-trivial to make this working, but you seem pretty confident that it just needs to be “unlocked”.
Still think Ngon holes in Ngon faces would be cool :3
but after you’ll gain knowledge you’ll realize it was an illusion 
it’s also fun to have horoscopes
this would be just one more half working problem for noobs to trip all over.
sketchup may be able to DO this. but it screws it up almost all the time. ive seen some scary things happen.
sketchup does use phantom geometry to make it “legal”. you can see it when faces are z-fighting.
I don’t recall ever seeing Sketchup screwing this up, and I work with it quite often. Sketchup works beautifully with this.
What it does definitely screw up, is rounded edges, but what’s a whole other story…
When the model is exported, you get to see the underlying messy face triangulation, but it doesn’t matter. If you want correct topology, model in correct topology. If you are just making something to just visualise within sketchup, or blender, it doesn’t matter. If it looks good, it is good. No matter if there are underlying tricks or mess under it, that the user doesn’t see. Ignorance is bliss.
It’s just so convenient… You don’t feel restricted modelling this way, and the result looks so clean…